Opinions sougth: mlocate appropriate for Priority: standard? - Debian

This is a discussion on Opinions sougth: mlocate appropriate for Priority: standard? - Debian ; Hello. I'm preparing packages for mlocate, and personally I would like to upload it with Priority: standard. But I'm open to be convinced that is not a good idea (eg. "standard is already bloated"). I think having a working /usr/bin/locate ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 43

Thread: Opinions sougth: mlocate appropriate for Priority: standard?

  1. Opinions sougth: mlocate appropriate for Priority: standard?

    Hello.

    I'm preparing packages for mlocate, and personally I would like to
    upload it with Priority: standard. But I'm open to be convinced that is
    not a good idea (eg. "standard is already bloated").

    I think having a working /usr/bin/locate is a reasonable expectation for
    a Linux system nowadays, so the priority level would fit. I am aware of
    course that findutils already provides one implementation, and it's
    Priority: required...

    However, I would very much like to have a *better* implementation
    installed by default, and I think mlocate would be very appropriate for
    the job:

    * as slocate, it runs and root instead of nobody in order to index all
    files, but keeps it's database mode 640 root:mlocate, and a setgid
    binary /usr/bin/locate in order to only return results the running
    user has access to

    *and*

    * mlocate keeps timestamps in its database, so when running updatedb
    it can determine if the contents of a directory have changed without
    having to read its contents; this makes the update faster, and less
    demanding on the harddist (that's where the name comes from, "merge
    locate")

    mlocate is written by a RedHat person, is maintained upstream (unlike,
    it seems, slocate), and if I'm not mistaken is already default in Fedora.

    Opinions?

    --
    Adeodato Simó dato at net.com.org.es
    Debian Developer adeodato at debian.org

    When it is not necessary to make a decision, it is necessary not to make
    a decision.


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. Re: Opinions sougth: mlocate appropriate for Priority: standard?

    Adeodato Simó wrote:
    > I'm preparing packages for mlocate, and personally I would like to
    > upload it with Priority: standard. But I'm open to be convinced that is
    > not a good idea (eg. "standard is already bloated").


    > I think having a working /usr/bin/locate is a reasonable expectation for
    > a Linux system nowadays, so the priority level would fit.


    Hello,
    I disagree that a expecting a *working* locate is reasonable. Most
    systems have a updatedb/locate *binaries installed, but many disable
    the db generation.

    > I am aware of
    > course that findutils already provides one implementation, and it's
    > Priority: required...


    It is only shipped as part of the findutils package since splitting of
    a 78KB package seems to be bad idea.

    > However, I would very much like to have a *better* implementation
    > installed by default, and I think mlocate would be very appropriate for
    > the job:

    [...]

    New versions (1.3.x) of findutils' locate can read slocate databases
    and there also exists a new updatedb binary (GSoC project) that is not
    a shell script anymore. The latter still has not made it into even a
    development release, though. Just as a data-point, not argueing
    against a better, existing implementation. ;-)

    cu and--reas
    --
    `What a good friend you are to him, Dr. Maturin. His other friends are
    so grateful to you.'
    `I sew his ears on from time to time, sure'


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  3. Re: Opinions sought: mlocate appropriate for Priority: standard?

    Adeodato Simó wrote:
    > I'm preparing packages for mlocate, and personally I would like to
    > upload it with Priority: standard. But I'm open to be convinced that is
    > not a good idea (eg. "standard is already bloated").
    >
    > I think having a working /usr/bin/locate is a reasonable expectation for
    > a Linux system nowadays, so the priority level would fit. I am aware of
    > course that findutils already provides one implementation, and it's
    > Priority: required...


    ... and Essential: yes since it contains find and xargs, making it
    impossible to remove on a normal system. I personally would much
    rather see locate split out of findutils and made optional. This
    would avoid the need to disable updatedb on any new system
    installation. While I do not have any numbers to back this up, I
    strongly suspect that the majority of people who have updatedb
    installed and running daily nevertheless do not use locate.

    I don't think that would need a transition, either; while scripts
    could theoretically count on the availability of locate, they could
    not count on it working or providing up-to-date results, so they
    couldn't reasonably make use of it. A scan of Debian packages would
    hopefully find no calls to locate, and any such call would almost
    certainly constitute a bug. Perhaps Lintian and Linda could check for
    this, much like the check for debconf-is-not-a-registry.

    In any case, I definitely do not think that any other locate
    implementation should have priority standard or higher as long as
    findutils (Essential: yes) contains locate. However...

    > However, I would very much like to have a *better* implementation
    > installed by default, and I think mlocate would be very appropriate for
    > the job:

    [...]
    > * mlocate keeps timestamps in its database, so when running updatedb
    > it can determine if the contents of a directory have changed without
    > having to read its contents; this makes the update faster, and less
    > demanding on the harddist (that's where the name comes from, "merge
    > locate")


    That alone makes it far far better than the standard locate, and depending
    on how well it works, I can imagine actually using it at least on non-laptop
    systems.

    Thus, I would argue that:

    * No locate should have standard priority as long as findutils
    contains locate.
    * locate should move out of findutils into a separate package.
    * Once that happens, if any locate should have priority standard,
    mlocate should.
    * However, I don't think any locate should have priority standard.

    - Josh Triplett



    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFHNaIEGJuZRtD+evsRAgwcAKC3NDd+7Eiyh+l8PGgWnu wBGKxaGQCfYge4
    vSfxy1HxstQZZnMeIh6Na1o=
    =3m2c
    -----END PGP SIGNATURE-----


  4. Re: Opinions sought: mlocate appropriate for Priority: standard?

    Josh Triplett wrote:
    Thus, I would argue that:
    >
    > * No locate should have standard priority as long as findutils
    > contains locate.
    > * locate should move out of findutils into a separate package.
    > * Once that happens, if any locate should have priority standard,
    > mlocate should.
    > * However, I don't think any locate should have priority standard.
    >


    Why not remove locate from findutils instead of putting it into a
    separate package? I can't see any reason why one would need it if
    there's mlocate. Probably add a Recommends: mlocate to findutils.


    --
    Bernd Zeimetz



    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Re: Opinions sought: mlocate appropriate for Priority: standard?

    Bernd Zeimetz wrote:
    [...]
    > Why not remove locate from findutils instead of putting it into a
    > separate package? I can't see any reason why one would need it if
    > there's mlocate. Probably add a Recommends: mlocate to findutils.


    dlocate iirc depends on the GNU locate helper binaries, iirc.
    cu andreas
    --
    `What a good friend you are to him, Dr. Maturin. His other friends are
    so grateful to you.'
    `I sew his ears on from time to time, sure'


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  6. Re: Opinions sought: mlocate appropriate for Priority: standard?

    Josh Triplett wrote:
    > Thus, I would argue that:
    >
    > * No locate should have standard priority as long as findutils
    > contains locate.
    > * locate should move out of findutils into a separate package.
    > * Once that happens, if any locate should have priority standard,
    > mlocate should.
    > * However, I don't think any locate should have priority standard.


    Agreed to all points, except I do think some locate should probably be
    standard priority. But not required or essential. It's easy enough to
    skip priority standard stuff if it's not wanted.

    Given the security history of slocate, and since mlocate has a similar
    design from a security POV, it would be good to get a thurough audit of
    mlocate, perhaps trying some of the same holes. At least it doesn't seem
    to be vulnerable to the attack described in CVE-2007-0227.

    --
    see shy jo

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHNeCsd8HHehbQuO8RArhNAJ4w2J3FeJ98Vt1MjHuMFQ gZPhZQDgCfT+eL
    gSulzk03Bb0flUmihc9jb5o=
    =IjoR
    -----END PGP SIGNATURE-----


  7. Re: Opinions sought: mlocate appropriate for Priority: standard?

    * Joey Hess [Sat, 10 Nov 2007 11:47:40 -0500]:

    > Josh Triplett wrote:
    > > Thus, I would argue that:


    > > * No locate should have standard priority as long as findutils
    > > contains locate.
    > > * locate should move out of findutils into a separate package.
    > > * Once that happens, if any locate should have priority standard,
    > > mlocate should.
    > > * However, I don't think any locate should have priority standard.


    > Agreed to all points, except I do think some locate should probably be
    > standard priority. But not required or essential. It's easy enough to
    > skip priority standard stuff if it's not wanted.


    Okay, thanks. Andreas, how does the idea of splitting locate/updatedb
    out from findutils sound to you, to follow the above plan? (dlocate can
    Depend: on locate | findutils (<= 4.3.8-X) then.)

    Cheers,

    --
    Adeodato Simó dato at net.com.org.es
    Debian Developer adeodato at debian.org

    I try to keep an open mind, but not so open that my brains fall out.


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  8. Re: Opinions sought: mlocate appropriate for Priority: standard?

    Adeodato Simó wrote:
    [...]
    > Okay, thanks. Andreas, how does the idea of splitting locate/updatedb
    > out from findutils sound to you, to follow the above plan? (dlocate can
    > Depend: on locate | findutils (<= 4.3.8-X) then.)


    If we have got (at least temporarily) three locate packages in Debian
    we probably need to switch to alternatives. (Currently slocate uses
    dpkg-divert.)
    cu andreas
    --
    `What a good friend you are to him, Dr. Maturin. His other friends are
    so grateful to you.'
    `I sew his ears on from time to time, sure'


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  9. Re: Opinions sought: mlocate appropriate for Priority: standard?

    * Andreas Metzler [Sun, 11 Nov 2007 14:08:50 +0100]:

    > If we have got (at least temporarily) three locate packages in Debian
    > we probably need to switch to alternatives. (Currently slocate uses
    > dpkg-divert.)


    Yes, though the slocate maintainer scripts scare the hell out of me, and
    ISTR that the maintainer is somewhat MIA. Shall we make coordinated
    uploads of your locate and mine, and propose a patch to slocate? (I can
    prepare it, my fears notwithstanding.) I guess dlocate would need an
    upload as well.

    How to handle the cron.daily script, though?

    --
    Adeodato Simó dato at net.com.org.es
    Debian Developer adeodato at debian.org

    Mankind are very odd creatures: one half censure what they practice, the
    other half practice what they censure; the rest always say and do as
    they ought.
    -- Michel de Montaigne


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  10. Re: Opinions sought: mlocate appropriate for Priority: standard?

    Adeodato Simó wrote:
    > * Andreas Metzler [Sun, 11 Nov 2007 14:08:50 +0100]:
    >> we probably need to switch to alternatives. (Currently slocate uses
    >> dpkg-divert.)


    > Yes, though the slocate maintainer scripts scare the hell out of me, and
    > ISTR that the maintainer is somewhat MIA. Shall we make coordinated
    > uploads of your locate and mine, and propose a patch to slocate? (I can
    > prepare it, my fears notwithstanding.)


    I guess it would need happen like this:

    1. upload findutils with splitoff locate to experimental. The locate
    package (Is this name ok?) ships /usr/bin/locate.findutils and
    /usr/bin/updatedb.findutils. It installs low-priority alterntives for
    these. The package conflicts with slocate (<< the next version, i.e.
    3.1-1.2). It conflicts/replaces findutils (<=4.3.8-1, which is the
    last vesion living in experimental.)

    > I guess dlocate would need an
    > upload as well.


    > How to handle the cron.daily script, though?


    --- find-cron.daily (Revision 220)
    +++ find-cron.daily (Arbeitskopie)
    @@ -5,6 +5,7 @@
    # Written by Ian A. Murdock and
    # Kevin Dalley

    +[ -e /usr/bin/updatedb.findutils ] || exit 0
    LOCALUSER="nobody"
    export LOCALUSER
    if [ -f /etc/updatedb.conf ]; then
    @@ -12,7 +13,7 @@
    fi

    if getent passwd $LOCALUSER > /dev/null ; then
    - cd / && nice -n ${NICE:-10} updatedb 2>/dev/null
    + cd / && nice -n ${NICE:-10} updatedb.findutils 2>/dev/null

    cu andreas

    --
    `What a good friend you are to him, Dr. Maturin. His other friends are
    so grateful to you.'
    `I sew his ears on from time to time, sure'


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  11. Re: Opinions sought: mlocate appropriate for Priority: standard?

    * Andreas Metzler [Sun, 11 Nov 2007 16:19:16 +0100]:

    > I guess it would need happen like this:


    > 1. upload findutils with splitoff locate to experimental. The locate
    > package (Is this name ok?) ships /usr/bin/locate.findutils and
    > /usr/bin/updatedb.findutils. It installs low-priority alterntives for
    > these. The package conflicts with slocate (<< the next version, i.e.
    > 3.1-1.2). It conflicts/replaces findutils (<=4.3.8-1, which is the
    > last vesion living in experimental.)


    Sounds good, and I think locate as package name is appropriate. Is there
    an ETA for uploading 4.3.8 to unstable?

    > > I guess dlocate would need an
    > > upload as well.


    > > How to handle the cron.daily script, though?


    > +[ -e /usr/bin/updatedb.findutils ] || exit 0
    > + cd / && nice -n ${NICE:-10} updatedb.findutils 2>/dev/null


    Well, I should've been more verbose: that patch will run updatedb even
    if findutil's locate is installed but not the selected alternative. Now
    that I think about it, maybe:

    [ `readlink -f /usr/bin/updatedb` = /usr/bin/updatedb.findutils ] || exit 0

    (And the same for mlocate *and* slocate). How does it sound?

    --
    Adeodato Simó dato at net.com.org.es
    Debian Developer adeodato at debian.org

    And don't get me wrong - I don't mind getting proven wrong. I change my
    opinions the way some people change underwear. And I think that's ok.
    -- Linus Torvalds


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  12. Re: Opinions sought: mlocate appropriate for Priority: standard?

    Adeodato Simó wrote:
    [...]
    > Sounds good, and I think locate as package name is appropriate. Is there
    > an ETA for uploading 4.3.8 to unstable?


    No, not yet. But once stuff works in experimental (and all components
    have gone through the necessary NEW processing) the respective change
    could go to 4.2.x.

    [...]
    >> > How to handle the cron.daily script, though?


    >> +[ -e /usr/bin/updatedb.findutils ] || exit 0
    >> + cd / && nice -n ${NICE:-10} updatedb.findutils 2>/dev/null


    > Well, I should've been more verbose: that patch will run updatedb even
    > if findutil's locate is installed but not the selected alternative. Now
    > that I think about it, maybe:


    > [ `readlink -f /usr/bin/updatedb` = /usr/bin/updatedb.findutils ] || exit 0


    > (And the same for mlocate *and* slocate). How does it sound?


    I am not sure I get what problem you are trying to solve. I think you
    want to stop findutil's cron.daily from generating a locate
    database if findutil's locate is installed but the alternative
    /usr/bin/updatedb points to a different implementation.

    Imho this problem is not one that needs to be solved, if multiple
    locates are installed, multiple databases should be generated.
    cu andreas
    --
    `What a good friend you are to him, Dr. Maturin. His other friends are
    so grateful to you.'
    `I sew his ears on from time to time, sure'


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  13. Re: Opinions sought: mlocate appropriate for Priority: standard?

    * Andreas Metzler [Sun, 11 Nov 2007 19:41:07 +0100]:

    > No, not yet. But once stuff works in experimental (and all components
    > have gone through the necessary NEW processing) the respective change
    > could go to 4.2.x.


    Ah, very well then.

    > Imho this problem is not one that needs to be solved, if multiple
    > locates are installed, multiple databases should be generated.


    I think differently. Particularly given that findutil's locate can be
    installed only as a dependency of other packages. (If this wasn't the
    case, I'd agree your point of view is valid as well.) Did you consider
    this?

    Cheers,

    --
    Adeodato Simó dato at net.com.org.es
    Debian Developer adeodato at debian.org

    Listening to: Fangoria - Me comeré tu piel, me beberé tu sangre


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  14. Re: Opinions sought: mlocate appropriate for Priority: standard?

    On Nov 11, 2007 10:38 PM, Andreas Metzler wrote:

    > If we have got (at least temporarily) three locate packages in Debian
    > we probably need to switch to alternatives. (Currently slocate uses
    > dpkg-divert.)


    Why do we need 3 packages that do the same thing slightly differently?
    Can't the 3 upstreams work together to get one locate that works
    sanely and has all the features needed (another feature I'd like to
    see in locate would be locateD, so I can avoid the nightly updatedb
    runs and just use inotify or the kfreebsd equivalent)?

    --
    bye,
    pabs

    http://wiki.debian.org/PaulWise


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  15. Re: Opinions sought: mlocate appropriate for Priority: standard?

    Adeodato Simó wrote:
    [...]
    >> Imho this problem is not one that needs to be solved, if multiple
    >> locates are installed, multiple databases should be generated.


    > I think differently. Particularly given that findutil's locate can be
    > installed only as a dependency of other packages. (If this wasn't the
    > case, I'd agree your point of view is valid as well.) Did you consider
    > this?


    Hello,
    I did consider it, but afaik the pulled-in-by-dependency-szenario is
    going to be rare.
    cu andreas
    --
    `What a good friend you are to him, Dr. Maturin. His other friends are
    so grateful to you.'
    `I sew his ears on from time to time, sure'


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  16. Re: Opinions sought: mlocate appropriate for Priority: standard?

    Andreas Metzler wrote:
    > Bernd Zeimetz wrote:
    > [...]
    >> Why not remove locate from findutils instead of putting it into a
    >> separate package? I can't see any reason why one would need it if
    >> there's mlocate. Probably add a Recommends: mlocate to findutils.

    >
    > dlocate iirc depends on the GNU locate helper binaries, iirc.


    right, it's using a 'faked' locatedb and runs locate from findutils on
    it. So it would probably worth the work to use mlocate there - faking a
    database for it should not be too complicated.

    --
    Bernd Zeimetz



    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  17. Re: Opinions sought: mlocate appropriate for Priority: standard?

    * Andreas Metzler [Mon, 12 Nov 2007 19:31:29 +0100]:

    > Adeodato Simó wrote:
    > [...]
    > >> Imho this problem is not one that needs to be solved, if multiple
    > >> locates are installed, multiple databases should be generated.


    > > I think differently. Particularly given that findutil's locate can be
    > > installed only as a dependency of other packages. (If this wasn't the
    > > case, I'd agree your point of view is valid as well.) Did you consider
    > > this?


    > I did consider it, but afaik the pulled-in-by-dependency-szenario is
    > going to be rare.


    Well, dlocate has 2500 popcon installations, vs. slocate's 1500. So, I'm
    still convinced findutil's locate's cron script should either only run if
    it's the configured locate, *or* not run unless enabled in /etc/default/locate.

    But it's your package and I know how to disable one script for cron, so
    I won't mention it further. :-)

    * * *

    Down to some specifics:

    * shall we use a single alternative group /usr/bin/locate (symlink:
    locate), with slaves for /usr/share/man/man1/locate.1.gz,
    /usr/bin/updatedb, and /usr/share/man/man1/updatedb.1.gz? (mlocate
    likes its updatedb man page in section (8), and I think it makes
    more sense; does the .1 come from upstream, or is something that
    could be changed in your package? Or maybe it's better to use .1 due
    to "histerical reasons")

    I guess mlocate can use priority 80, and plain locate 20?

    (mlocate also provides updatedb.conf.5, which could be a problem if
    locate starts shipping it at some point. Should I install an
    alternative for it just in case?)

    * how about this plan?:

    1a. I upload mlocate to experimental with

    Conflicts: findutils (<= 4.3.8-1), slocate (<= 3.1-1.1)

    1b. You upload locate from findutils 4.3.8-2 to experimental, with
    Conflicts as above (no need for Replaces, since it doesn't replace
    any files; the alternatives are not shipped in the .deb). In the
    same upload, findutils gets:

    Breaks: dlocate (<= 0.5-0.3)

    1c. I submit a bug against dlocate asking for

    Depends: locate | findutils (<= 4.2.31-1)

    2. After verifying it works, we upload to unstable
    (mlocate+conflicts, locate+conflicts, findutils+breaks), and I
    take care of providing a patch for slocate, possibly making a
    NMU, and possibly making a NMU of dlocate as well. (By the looks
    of it, looks like both of them will be needed.)

    Sounds good, and/or possible ETA?

    Thanks,

    --
    Adeodato Simó dato at net.com.org.es
    Debian Developer adeodato at debian.org

    La música es de los que la quieren escuchar y de nadie más.
    -- Andrés Calamaro


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  18. Re: Opinions sought: mlocate appropriate for Priority: standard?

    Adeodato Simó wrote:
    > * Andreas Metzler [Mon, 12 Nov 2007 19:31:29 +0100]:

    [...]
    >> I did consider it, but afaik the pulled-in-by-dependency-szenario is
    >> going to be rare.


    > Well, dlocate has 2500 popcon installations, vs. slocate's 1500. So, I'm
    > still convinced findutil's locate's cron script should either only run if
    > it's the configured locate, *or* not run unless enabled in /etc/default/locate.


    > But it's your package and I know how to disable one script for cron, so
    > I won't mention it further. :-)


    Perhaps it is possible to make dlocate work with mlocate's tools.

    > Down to some specifics:


    > * shall we use a single alternative group /usr/bin/locate (symlink:
    > locate), with slaves for /usr/share/man/man1/locate.1.gz,
    > /usr/bin/updatedb, and /usr/share/man/man1/updatedb.1.gz? (mlocate
    > likes its updatedb man page in section (8), and I think it makes
    > more sense; does the .1 come from upstream, or is something that
    > could be changed in your package? Or maybe it's better to use .1 due
    > to "histerical reasons")


    ..1 comes from upstream. It is possible for users to uses updatedb to
    index their own filetree. (With mlocate it is probably not necessary.)

    > I guess mlocate can use priority 80, and plain locate 20?


    > (mlocate also provides updatedb.conf.5, which could be a problem if
    > locate starts shipping it at some point. Should I install an
    > alternative for it just in case?)


    Nice to bring up the configuration file problem. ;-)

    How does mlocate.updatedb handle updatedb.conf? Does the binary read
    the file on every execution or does it also rely on wrapper script
    (the cron job) to source it? findutils works the latter way and the
    file is therefore misnamed, it is find-daily.defaults, not
    updatedb.conf.

    You do not plan on sharing the configuration file between packages, do
    you?

    [...]
    > same upload, findutils gets:


    > Breaks: dlocate (<= 0.5-0.3)


    I thought Breaks was not yet handled by dpkg/apt and was therefore
    pointless?

    > 1c. I submit a bug against dlocate asking for


    > Depends: locate | findutils (<= 4.2.31-1)


    plus a sourcechange to actually work with both.

    [...]
    > Sounds good, and/or possible ETA?


    Sounds basically ok. I will try to make some real progress on the
    weekend.

    cu andreas
    --
    `What a good friend you are to him, Dr. Maturin. His other friends are
    so grateful to you.'
    `I sew his ears on from time to time, sure'


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  19. Re: Opinions sought: mlocate appropriate for Priority: standard?

    * Andreas Metzler [Wed, 14 Nov 2007 19:32:47 +0100]:

    > Adeodato Simó wrote:
    > > * Andreas Metzler [Mon, 12 Nov 2007 19:31:29 +0100]:

    > [...]
    > >> I did consider it, but afaik the pulled-in-by-dependency-szenario is
    > >> going to be rare.


    > > Well, dlocate has 2500 popcon installations, vs. slocate's 1500. So, I'm
    > > still convinced findutil's locate's cron script should either only run if
    > > it's the configured locate, *or* not run unless enabled in /etc/default/locate.


    > > But it's your package and I know how to disable one script for cron, so
    > > I won't mention it further. :-)


    > Perhaps it is possible to make dlocate work with mlocate's tools.


    mlocate doesn't ship any tools like /usr/lib/locate/frcode (which
    dlocate uses), only locate and updatedb.

    > .1 comes from upstream. It is possible for users to uses updatedb to
    > index their own filetree. (With mlocate it is probably not necessary.)


    So, uhm, I'll go with renaming to .1 in mlocate.

    > How does mlocate.updatedb handle updatedb.conf? Does the binary read
    > the file on every execution or does it also rely on wrapper script
    > (the cron job) to source it? findutils works the latter way and the
    > file is therefore misnamed, it is find-daily.defaults, not
    > updatedb.conf.


    The updatedb binary directly reads updatedb.conf.

    > You do not plan on sharing the configuration file between packages, do
    > you?


    Well, what do you suggest? How does dpkg react when unpacking a conffile
    that is the conffile of another package?

    > [...]
    > > same upload, findutils gets:


    > > Breaks: dlocate (<= 0.5-0.3)


    > I thought Breaks was not yet handled by dpkg/apt and was therefore
    > pointless?


    apt supports it since 0.7.0.

    > > 1c. I submit a bug against dlocate asking for


    > > Depends: locate | findutils (<= 4.2.31-1)


    > plus a sourcechange to actually work with both.


    What change? Ah, you mean using /usr/bin/locate.findutils, and only if
    that's not present, fail back to `dpkg-divert --truename /usr/bin/locate`?

    > Sounds basically ok. I will try to make some real progress on the
    > weekend.


    Thanks,

    --
    Adeodato Simó dato at net.com.org.es
    Debian Developer adeodato at debian.org

    Man is certainly stark mad; he cannot make a flea, yet he makes gods by the
    dozens.
    -- Michel de Montaigne


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  20. Re: Opinions sought: mlocate appropriate for Priority: standard?

    * Adeodato Simó [Tue, 13 Nov 2007 22:13:20 +0100]:

    > 2. After verifying it works, we upload to unstable
    > (mlocate+conflicts, locate+conflicts, findutils+breaks),


    Forgot to say, the Conflicts: findutils (<= 4.3.8-1) need to be changed
    to use <= 4.2.31-1 when uploading to unstable. Just noticed when going
    over this mail.

    --
    Adeodato Simó dato at net.com.org.es
    Debian Developer adeodato at debian.org

    The reasonable man adapts himself to the world; the unreasonable one
    persists in trying to adapt the world to himself. Therefore all
    progress depends on the unreasonable man.
    -- George Bernard Shaw


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast