• Bug#264108: Files installed in /var/lib/lxr should be in /usr/share/lxr

    From Giacomo A. Catenazzi@1:229/2 to Pierre THIERRY on Thu Aug 12 09:00:14 2004
    From: [email protected]

    Pierre THIERRY wrote:
    Package: lxr
    Version: 0.3.1-2
    Severity: serious
    Justification: FHS 4.7, FHS 5.5

    According to the FHS, /var/lib is meant to hold variable state
    information. Files unpacked there (scripts and an image) must go to /usr/share/lxr, as architecture-independant read-only data must go in /usr/share.

    IMHO, if the directories created in /var/lib are there to hold generated
    data from source code, they would be better in /var/cache...

    Ok. I see, but...

    lxr is a web application, so it don't fit /usr/share because people
    would like to customize pages (maybe more als headers and footers),
    nor /var/lib (see you argument).

    The optimal solution for FHS is to move some files in /usr/share, some
    in /etc, some in /var/lib,...
    But this is not optimal for user, because the file feeded to web server
    are sparse in much location (security check, chroot, configuration web-server, monitoring and last: customization).

    /var/cache is not a good location for our data, because generating
    data take much time, and now there is no automatically way to generationg missing single files or missing directory (as required by FHS, for /var/cache). [ Note lxr-cvs create data in a mysql database, and the databases are in /var/lib/mysql/ ]

    Anyway, people to enable lxr should read documentaion and should do some
    step manually, so administrator know what it is created.

    I will downgrade the severity of the bug, and I will check similar programs,
    to see what are the optimum locations.

    ciao
    cate


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Pierre THIERRY@1:229/2 to All on Sat Aug 14 01:00:14 2004
    From: [email protected]

    lxr is a web application, so it don't fit /usr/share because people
    would like to customize pages (maybe more als headers and footers),
    nor /var/lib (see you argument).

    There are other customizable web applications that are FHS compliants,
    some of them packaged in Debian (I immediately see spip, but there is
    also dacode).

    I will downgrade the severity of the bug, and I will check similar
    programs, to see what are the optimum locations.

    I don't see the point. Whether you find it optimal or not (and that is
    your right), your package is *not* FHS compliant, and in a badly way, so
    there is a policy violation.

    The bug *is* a serious one, until lxr is modified.

    Quickly,
    Nowhere man
    --
    [email protected]
    OpenPGP 0xD9D50D8A

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

    iD8DBQFBHUJbxe13INnVDYoRAvOpAJ0Y9pxGeisIxk6ktvS02lWHluN00gCcDy72 KKLV2XBTXU5ge+c1I64xYXw=
    =DCy4
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Giacomo A. Catenazzi@1:229/2 to Pierre THIERRY on Mon Aug 16 09:00:24 2004
    From: [email protected]

    Pierre THIERRY wrote:
    lxr is a web application, so it don't fit /usr/share because people
    would like to customize pages (maybe more als headers and footers),
    nor /var/lib (see you argument).


    There are other customizable web applications that are FHS compliants,
    some of them packaged in Debian (I immediately see spip, but there is
    also dacode).


    I will downgrade the severity of the bug, and I will check similar >>programs, to see what are the optimum locations.


    I don't see the point. Whether you find it optimal or not (and that is
    your right), your package is *not* FHS compliant, and in a badly way, so there is a policy violation.

    The bug *is* a serious one, until lxr is modified.


    I should still think more about splitting files into /usr/share,
    and really I not convinced, nor I interpret FHS so strictly.
    Reading FHS, it seems that the best location according FHS should
    be /srv.

    Anyway you should not see FHS as a strict standard!

    IMHO I think it is more important that LXR is simple to
    maintain and to publish data in a secure way, and really I
    don't want to put in /etc/ a lot of data (a copy of
    /usr/share/lxr), so data is customizable [as I see in
    other packages].

    In sarge+1 I would eventually move first lxr-cvs (than
    lxr) in a more compliant FHS manner.

    ciao
    cate




    Quickly,
    Nowhere man



    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Giacomo A. Catenazzi@1:229/2 to Giacomo A. Catenazzi on Wed Aug 18 10:40:10 2004
    From: [email protected]

    Giacomo A. Catenazzi wrote:

    In sarge+1 I would eventually move first lxr-cvs (than
    lxr) in a more compliant FHS manner.

    I'm more convinced to move files in /usr/share, but
    anyway in etch (=sarge+1).

    ciao
    cate


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Pierre THIERRY@1:229/2 to All on Sat Aug 7 05:00:10 2004
    From: [email protected]

    Package: lxr
    Version: 0.3.1-2
    Severity: serious
    Justification: FHS 4.7, FHS 5.5

    According to the FHS, /var/lib is meant to hold variable state
    information. Files unpacked there (scripts and an image) must go to /usr/share/lxr, as architecture-independant read-only data must go in /usr/share.

    IMHO, if the directories created in /var/lib are there to hold generated
    data from source code, they would be better in /var/cache...

    Nowhere man
    --
    [email protected]
    OpenPGP 0xD9D50D8A

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

    iD8DBQFBFD/cxe13INnVDYoRArNgAKCgI1F2lcbOVQak5dwmRCv5wgd0nQCfTB4o FNVkoI4SSGcTMwn6j7SbeKc=
    =GJgH
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)