[gentoo-user] FYI: Rules for distro-friendly packages

[gentoo-user] FYI: Rules for distro-friendly packages

[Enrico Weigelt]

Hi folks,


I'm currently collecting a set of rules which upstream developers
should follow to make distro maintainer's life easier.

Comments welcomed :)


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

Re: [gentoo-user] FYI: Rules for distro-friendly packages

[Alan McKinnon]

On Friday 25 June 2010 22:17:39 Enrico Weigelt wrote:
> Hi folks,
> 
> 
> I'm currently collecting a set of rules which upstream developers
> should follow to make distro maintainer's life easier.
> 
> Comments welcomed :)


My biggest beef by far when packaging apps is automagic dependencies.

e17 is full of them - if package A is present, the app will configure itself 
to use it. Usually you cannot switch this kind of thing off even if you have 
valid reasons to do so.

I want explicit --enable-<package> features in the ./configure step for 
everything that might be optional. Because I often do have that lib on my 
system and the app's usage of it is buggy, so I should be able to disable that 
support.



-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] FYI: Rules for distro-friendly packages

[Volker Armin Hemmann]

On Freitag 25 Juni 2010, Enrico Weigelt wrote:
> Hi folks,
> 
> 
> I'm currently collecting a set of rules which upstream developers
> should follow to make distro maintainer's life easier.
> 
> Comments welcomed :)
> 
> 
> cu

no bundled libs.

when you change the tarball fucking change the version number.

and what Alan said.

Re: [gentoo-user] FYI: Rules for distro-friendly packages

[Alan McKinnon]

On Friday 25 June 2010 23:57:54 Volker Armin Hemmann wrote:
> On Freitag 25 Juni 2010, Enrico Weigelt wrote:
> > Hi folks,
> > 
> > 
> > I'm currently collecting a set of rules which upstream developers
> > should follow to make distro maintainer's life easier.
> > 
> > Comments welcomed :)
> > 
> > 
> > cu
> 
> no bundled libs.
> 
> when you change the tarball fucking change the version number.

I forgot that one. Sun are INFAMOUS for that with the jdk..

> and what Alan said.

Some more:

Don't depend on some arb version number of libs. Nothing worse than being 
forced to use some lib 4 versions behind current when current actually works 
just fine

Test your code under realistic conditions. Unit tests exist for a reason, read 
'em

Read flameeyes's blog. You might not agree with everything he says, but 
consider it all carefully as a technical position. He makes good points.

Don't try and re-invent the wheel with sucky roll-your-own build systems. 
auto* sucks, but by and large they suck less than anything you can come up 
with considering your more limited resources.

No hardcoded locations. If I want to install to /opt/csw/package/, then I 
should be able to do it, it makes zero difference to upstream if I do

The entire package under the same license if possible. This doesn't always 
work out - a GPL package may include someone else's BSD code who is not 
willing to re-license it. So be it. But please do make an effort to get 
everything under the same license, it makes decisions so much easier for your 
users to make.

Maintain the README, NEWS, INSTALL, ChangeLog, etc. We users actually do read 
them, and up to date metadata gives us a warm fuzzy where we feel good about 
your code

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] FYI: Rules for distro-friendly packages

[Enrico Weigelt]

* Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> Some more:
> 
> Don't depend on some arb version number of libs. Nothing worse than being 
> forced to use some lib 4 versions behind current when current actually works 
> just fine

ACK. But most times, that IMHO comes from incompatible API (or ABI)
changes. Perhaps I should add some rules about that - libs have to
maintain backwards API (or even ABI ?) compatibility, at least within
the same major version.

> No hardcoded locations. If I want to install to /opt/csw/package/, then I 
> should be able to do it, it makes zero difference to upstream if I do

ACK. Packages should be (build-time) relocatable, following FHS-style
classifications.

> Maintain the README, NEWS, INSTALL, ChangeLog, etc. We users actually do read 
> them, and up to date metadata gives us a warm fuzzy where we feel good about 
> your code

Well, separate changelog (beside the vcs' log) should only be 
required for large packages. Better a releas-notes file, stating
everthing that's important for upgrades.


BTW: meanwhile I've set up an sf.net project w/ maillist:
https://sourceforge.net/p/oss-qm/home/

 
cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------