Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#6092 - better packagin policy needed

Attached to Project: Arch Linux
Opened by Andrea Garbarini (garba) - Wednesday, 27 December 2006, 16:47 GMT
Last edited by Aaron Griffin (phrakture) - Friday, 28 September 2007, 16:42 GMT
Task Type Feature Request
Category System
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture All
Severity Medium
Priority Normal
Reported Version 0.7.2 Gimmick
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I don't mean to be rude or to offend anyone's work, but I believe that this distro needs a better packaging policy. For tesing purpose I went about installing all packages from both the current and extra repos on my box and I noticed a few packages store data in non-FHS compliant locations. I am not saying that the FHS should be lookek up to as the holy grail, but please, some more attention and common sense on behalf of the packagers should be desiderable:

bind: run time generated data stored in /var/named --> should be /var/lib/named
cyrus-sasl: /var/state ?!?!
apr: reported about SIX MONTHS ago and we still have this /usr/build-1 thing lying about

I really can't understand how something so obviously messy could get overlooked. Perhaps a general package overview before 0.8 would be a good thing ;)
This task depends upon

Closed by  Aaron Griffin (phrakture)
Friday, 28 September 2007, 16:42 GMT
Reason for closing:  Not a bug
Additional comments about closing:  See Andrew's comment. Handle individual package issues on a case by case basis.
Comment by Andrea Garbarini (garba) - Wednesday, 27 December 2006, 21:03 GMT
In particular, I think we should define common guidelines for the following:

- policy for creating new users, should a daemon need a private account ro run: the most natural place should be the install script but I noticed that, for example, the mysql startup script deals with this upon invocation, which is not very KISS-compliant imho... notifying the user a new user id has been added to the system would be a good thing imo
- on the other hand, proper handling of dirs in /var/run (should a daemon need one, common case when it's run as an unpriviliged user) should be taken care of during the startup script invocation, this should make things more robust, i would also reccomend to strip packages of any reference to /var/run stuff... i noticed there's no common agreement on how this is done

...just to name a few i came up with...
Comment by Andrew Fyfe (space-m0nkey) - Thursday, 24 May 2007, 22:37 GMT
The best way to get file/dir locations fixed is to file bug reports...
bind: http://bugs.archlinux.org/task/3691
cyrus-sasl: http://bugs.archlinux.org/task/7265
apr: fixed

Comment by Joel Kaasinen (opqdonut) - Wednesday, 06 June 2007, 09:48 GMT
I think a reconsideration of library and doc packaging is also in order, see bugs
http://bugs.archlinux.org/task/7373
and
http://bugs.archlinux.org/task/3459

Loading...