Re: [gentoo-user] FYI: Rules for distro-friendly packages
* Alan McKinnon alan.mckin...@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: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
[gentoo-user] FYI: Rules for distro-friendly packages
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
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
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
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
