You are not logged in.
Pages: 1
Hello,
i was wondering if there is something like QA or package policies to ensure that packages fulfill certain requirements.
This should improve the overall package quality and help devs when creating packages.
I think thats very important since the number of packages is growing everyday; some packages are pre-configured, some are not,
some ship documentation, others don't, some are tweaked and patched, others are shipped unpatched ... and with a policy or at least guidelines this hilly package landscape could be evened.
cheers
Offline
There is official packaging guidelines in the wiki. Have a look at http://wiki.archlinux.org/index.php/Arc … _Standards . As far a patching, shipping documentation etc go, patches are usually restricted to having the package build and function properly and documentation is generally limited to man pages. Of course there will be exceptions...
Offline
This should improve the overall package quality
to me, there's nothing to improve. the package quality is much higher than many distros out there, and at least on par with the better ones.
besides, as an example (but many projects suffered the same) IMHO nothing has hurt gentoo more than QA introduced for the just sake of it.
remember, 'best' is the worst enemy of 'good'
Last edited by lloeki (2007-08-11 16:42:06)
To know recursion, you must first know recursion.
Offline
with improved package quality i don't mean patching them like mad
lets take nano as an example. a few weeks ago it shipped with the default nanorc i think which is included in the sources. in the latest version it ships with a _completely_ different nanorc with code highlighting for a few "languages" and a couple of other options enabled. and i don't think thats an improvement.
Offline
Well, we take what the upstream-maintainers give us. So when nano ships with a different rc, we use it. It's simple as that.
Todays mistakes are tomorrows catastrophes.
Offline
Arch has by far the best Quality packages around. I have tried many distro's and many due to their release cycles are not even compatible with themselves where a package works in one release and not the next. With arch as upstream changes so do the packages and if something breaks it is usually fixed in a short time. The option of re-compiling with makepkg and abs to suit specific needs is also exceptionally good and convenient. Introducing restrictive QA IMHO will break the rolling release system or at least slow it down considerably.
---for there is nothing either good or bad, but only thinking makes it so....
Hamlet, W Shakespeare
Offline
Old conversation is old. This has been suggested on and off for eons now. It's always the same: the suggesting person fails to specify how exactly the guidelines should look like, usually it is only refering to a problem he or she had some time back. And gosh: just because of one little problem (which is sometimes more PEBKAC than anything else) the package-quality is bad all of sudden.
So please: make some suggestions how such guidelines should look like, post it to the ML for discussion, underpin your suggestions with arguments. Just don't fling things like "They should improve package-quality!" around. It's way uncool.
To give my own smelly opinion: the packages are working perfectly. They are streamlined, they are up-to-date and if I don't like them I can usually fix things via makepkg or an entry to the bugtracker. Arch is rolling-release and bleeding-edge. If you don't like that: use Debian.
Todays mistakes are tomorrows catastrophes.
Offline
Pages: 1