Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Jacob Godserv schrieb: > On Tue, 17 Aug 2010 19:04:03 +0200 > Enrico Weigelt wrote: > > > Meanwhile I've reworked my Briegel buildsystem [1] to support > > direct git checkouts (including a repo cache). Next step will be > > a mechanism to check tag signatures. > > You have a footnote, but no link, and I'm curious. :) ups, I probably thinking and typing got out of sync ;-O http://www.metux.de/index.php/en/component/content/article/57.html 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 --
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Tue, 17 Aug 2010 19:04:03 +0200 Enrico Weigelt wrote: > Meanwhile I've reworked my Briegel buildsystem [1] to support > direct git checkouts (including a repo cache). Next step will be > a mechanism to check tag signatures. You have a footnote, but no link, and I'm curious. :) -- Jacob "For then there will be great distress, unequaled from the beginning of the world until now — and never to be equaled again. If those days had not been cut short, no one would survive, but for the sake of the elect those days will be shortened." Are you ready? signature.asc Description: PGP signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Brian Harring schrieb: > > hmm, I'm exclusively using bzip2 and never had these problems > > yet. maybe it depends on the compressor type. > > http://www.gentoo.org/proj/en/glep/glep-0025.html#the-problem-in-detail > > Note also that bzip2 had another change in output after that > release- my memory is failing me a bit, but it was roughly a > a reduction of their hash size to fix a CVE- either way, same thing, > differing output. Okay, you've convinced me :) Meanwhile I've reworked my Briegel buildsystem [1] to support direct git checkouts (including a repo cache). Next step will be a mechanism to check tag signatures. 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 --
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Ciaran McCreesh schrieb: > PHP and mplayer both have 100 USE flags. There's not enough > CPU power in the world. We don't have to try *all* possible combinations, but only those differing in interfaces (eg. if some libfoo changes its exported interface on a userflag, the clients have to be built against that two versions). It involves some interface analysis and a bit of graph theory. Should be possible to do it incrementally. 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-dev] FYI: Rules for distro-friendly packages
On Sun, Jun 27, 2010 at 4:05 PM, Enrico Weigelt wrote: > * Nirbheek Chauhan schrieb: > >> Or if they generate the tarball on-the-fly with no caching, which >> results in differing timestamps each time. Hence, each time you fetch >> it, you get a tarball with a different hash. > > Does portage check the timestamps ? > I think you need to sit down and understand how tarballs are made, what they contain, and what a "hash" means, and how it's calculated. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On 06/27/10 20:33, Brian Harring wrote: > On Sun, Jun 27, 2010 at 01:08:58PM +0200, Enrico Weigelt wrote: >> * Ciaran McCreesh schrieb: >> Well, at least for tar, I've experienced no problem here yet. But: true, it might change between tar versions. >>> >>> The main offender is the compression program, not tar. >> >> hmm, I'm exclusively using bzip2 and never had these problems >> yet. maybe it depends on the compressor type. > > http://www.gentoo.org/proj/en/glep/glep-0025.html#the-problem-in-detail > > Note also that bzip2 had another change in output after that > release- my memory is failing me a bit, but it was roughly a > a reduction of their hash size to fix a CVE- either way, same thing, > differing output. Are you thinking about "bzip2 version 1.0.2 worked with huffman codes with a length of up to 20 bits. Unfortunately the Author of bzip2, Julian Seward, changed this in the new version 1.0.3 - it uses only a maximum length of 17 bits now. " (Quoted from http://linux01.gwdg.de/~nlissne/bugsandproblems.html ) ?
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sun, Jun 27, 2010 at 01:08:58PM +0200, Enrico Weigelt wrote: > * Ciaran McCreesh schrieb: > > > > Well, at least for tar, I've experienced no problem here yet. > > > But: true, it might change between tar versions. > > > > The main offender is the compression program, not tar. > > hmm, I'm exclusively using bzip2 and never had these problems > yet. maybe it depends on the compressor type. http://www.gentoo.org/proj/en/glep/glep-0025.html#the-problem-in-detail Note also that bzip2 had another change in output after that release- my memory is failing me a bit, but it was roughly a a reduction of their hash size to fix a CVE- either way, same thing, differing output. It happens, and further, is a well known potential for compressors. ~harring pgp3rTeFHDsRa.pgp Description: PGP signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
Le 27/06/2010 14:33, Ciaran McCreesh a écrit : > On Sun, 27 Jun 2010 14:22:53 +0200 > Enrico Weigelt wrote: >> Maybe it's time for a distributed build project: a generic container >> image, which gets distributed to dozens of machines and runs build >> tests coordinated by some server ... a bit like s...@home ;-) >> >> Enough CPU is available all around the world, just heavily >> distributed. > > PHP and mplayer both have 100 USE flags. There's not enough CPU power > in the world. > The *other* problem with -Werror is that the build will stop on the first warning, hiding all the others. Enrico, if you actually want to fix this, better capture the build.log of a *full* build, enabling all the warnings you could think of and then fix whatever makes sense. Cheers, Rémi
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sun, 27 Jun 2010 14:22:53 +0200 Enrico Weigelt wrote: > Maybe it's time for a distributed build project: a generic container > image, which gets distributed to dozens of machines and runs build > tests coordinated by some server ... a bit like s...@home ;-) > > Enough CPU is available all around the world, just heavily > distributed. PHP and mplayer both have 100 USE flags. There's not enough CPU power in the world. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Patrick Lauer schrieb: > > Well, if there're header bugs, shouldn't they get fixed before these > > libs are stabelized ? ;-O > > And there we have the thin line between actual bug and fuzzy > specification. Sometimes things fail just because two people assumed > something and thus the code disagrees in a really funny way. > Or just the GNUisms that tend to leak in through glibc+gcc ... *shudder* hmm, do you have some concrete examples ? > > Okay, adds *10 to the test matrix. Still not yet an too complex > > problem (still linear complexity). > > So just to keep up with the current package update speed in gentoo you'd > be saturating about a dozen quadcore machines. For amd64 only. Well, I'll have to investigate further. Maybe it's time for a distributed build project: a generic container image, which gets distributed to dozens of machines and runs build tests coordinated by some server ... a bit like s...@home ;-) Enough CPU is available all around the world, just heavily distributed. 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-dev] FYI: Rules for distro-friendly packages
On 06/27/10 13:02, Enrico Weigelt wrote: [snip] >> We also offer 10 versions of glibc, 8 versions of uclibc, and 7 versions >> of klibc. Each version may have header bugs, so may trigger warnings for >> perfectly good code. > > Well, if there're header bugs, shouldn't they get fixed before these > libs are stabelized ? ;-O And there we have the thin line between actual bug and fuzzy specification. Sometimes things fail just because two people assumed something and thus the code disagrees in a really funny way. Or just the GNUisms that tend to leak in through glibc+gcc ... *shudder* >> And finally we offer 5 unmasked versions of binutils (newer ones even >> have a brand new linker - gold) and 5 versions of binutils-apple. Again, >> different tools, different warnings... > > Okay, adds *10 to the test matrix. Still not yet an too complex > problem (still linear complexity). So just to keep up with the current package update speed in gentoo you'd be saturating about a dozen quadcore machines. For amd64 only. And that's not even checking all reverse dependencies of every single update (which can easily push it up by another factor of 100) Unless you have a strategic supply of gold bars it won't be possible to check all permutations (and we haven't even started toggling useflags for fun!) >> -Werror is a perfectly fine *developer* feature. For example, Gnome >> autoconf macros enable it for development snapshots, but never ever >> enable it for stable releases. > > Okay, aggreed. I've reworked my rule, now: > > "package build systems MUST NOT enable "-Wall -Werror" (unless explicitly > asked), but developers SHOULD use them for their test builds" I'd say they can enable it, but SHOULD NOT If people want to run headfirst into a wall let them do it a few times, they'll learn ...
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On 06/27/2010 06:52 AM, Enrico Weigelt wrote: remark #981: operands are evaluated in unspecified order (tons of them) return strcmp( left.c_str(), right.c_str() )> 0; I'm not sure if this really qualifies an warning, since - AFAIK - C spec never said, that there is an evaluation order for function parameters. I could see how somebody might make that assumption (incorrectly), and get burned by this. However, creating local variables just to hold intermediate results so as to not embed them in function calls seems to be a lot of overhead - certainly in terms of readability, and I can't think of a situation where the compiler would have to do it on its own. I guess religiously doing this might make the code less likely to contain very subtle bugs, but perhaps it is a bit over the top for anybody who wouldn't be otherwise developing in ADA. Rich
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sun, 27 Jun 2010 13:08:58 +0200 Enrico Weigelt wrote: > > > Well, at least for tar, I've experienced no problem here yet. > > > But: true, it might change between tar versions. > > > > The main offender is the compression program, not tar. > > hmm, I'm exclusively using bzip2 and never had these problems > yet. maybe it depends on the compressor type. Your problem is that you are thinking in terms of "well I've not seen it break", not "I can prove that it will always work". You may find the "Compressed output may vary" section of "man 1 xz" to be useful. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Ciaran McCreesh schrieb: > > Well, at least for tar, I've experienced no problem here yet. > > But: true, it might change between tar versions. > > The main offender is the compression program, not tar. hmm, I'm exclusively using bzip2 and never had these problems yet. maybe it depends on the compressor type. > > A more sophisticated approach, IMHO, would be: directly fetching > > from the VCS > > Yes, upstreams are going to love you for that... Why ? Because of traffic ? Of course, distros should work from their own clones (yes, yes, I'm assuming modern VCS'es, not toys like svn ;-p) 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-dev] FYI: Rules for distro-friendly packages
* Rémi Cardona schrieb: > We currently offer 11 different slots of GCC, 3 of gcc-apple, each with > multiple versions, 3 versions of llvm-gcc, 2 versions of clang, 7 > versions of icc, so in all 26 *major* versions. You do well know that > each compiler prints out different warnings for the *same* code... hmm, perhaps I'll hack some little scripts which create a jail/container for each compiler version and triggers emerge within them. > We also offer 10 versions of glibc, 8 versions of uclibc, and 7 versions > of klibc. Each version may have header bugs, so may trigger warnings for > perfectly good code. Well, if there're header bugs, shouldn't they get fixed before these libs are stabelized ? ;-O > And finally we offer 5 unmasked versions of binutils (newer ones even > have a brand new linker - gold) and 5 versions of binutils-apple. Again, > different tools, different warnings... Okay, adds *10 to the test matrix. Still not yet an too complex problem (still linear complexity). > -Werror is a perfectly fine *developer* feature. For example, Gnome > autoconf macros enable it for development snapshots, but never ever > enable it for stable releases. Okay, aggreed. I've reworked my rule, now: "package build systems MUST NOT enable "-Wall -Werror" (unless explicitly asked), but developers SHOULD use them for their test builds" 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-dev] FYI: Rules for distro-friendly packages
* Sergei Trofimovich schrieb: > I suggest you to try latest available dev-lang/icc (11.1.072). > This thing is really paranoid: > > remark #2259: non-pointer conversion from "int" to "unsigned char" may lose > significant bits > unsigned char BlinkerPhase = 0; > ... > BlinkerPhase = (BlinkerPhase + 1) & 3; In this case, the compiler is wrong: it should convert to int and back to char here ;-p > remark #981: operands are evaluated in unspecified order (tons of them) > return strcmp( left.c_str(), right.c_str() ) > 0; I'm not sure if this really qualifies an warning, since - AFAIK - C spec never said, that there is an evaluation order for function parameters. 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-dev] FYI: Rules for distro-friendly packages
On Sun, 27 Jun 2010 12:34:44 +0200 Enrico Weigelt wrote: > > You assume that, given the same input and program options, a > > compression program will always produce the same output. This is not > > the case. > > Well, at least for tar, I've experienced no problem here yet. > But: true, it might change between tar versions. The main offender is the compression program, not tar. > A more sophisticated approach, IMHO, would be: directly fetching > from the VCS Yes, upstreams are going to love you for that... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Nirbheek Chauhan schrieb: > Or if they generate the tarball on-the-fly with no caching, which > results in differing timestamps each time. Hence, each time you fetch > it, you get a tarball with a different hash. Does portage check the timestamps ? 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-dev] FYI: Rules for distro-friendly packages
* Ciaran McCreesh schrieb: > On Sat, 26 Jun 2010 22:09:09 +0200 > Enrico Weigelt wrote: > > Well, with git this works. (I'll yet have to run some automatic > > stress tests, but at all my manual tests worked really fine). > > You assume that, given the same input and program options, a > compression program will always produce the same output. This is not > the case. Well, at least for tar, I've experienced no problem here yet. But: true, it might change between tar versions. A more sophisticated approach, IMHO, would be: directly fetching from the VCS, but that would probably mean a major design change. (my Briegel buildsystem goes this way ... it doesnt even patch on itself anymore, thats done entirely in git) 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-dev] FYI: Rules for distro-friendly packages
Le 26/06/2010 21:39, Enrico Weigelt a écrit : > #2 One point i don't agree is the "dont add -Werror" rule. actually, > i'm thinking of making -Wall and -Werror mandatory. if some > package doenst build fine, it's simply broken. period. You're obviously new here... Just take a stroll through bugzilla to see how much we _fight_ against -Werror. Let's see why you obviously have not thought through this completely before writing this : We currently offer 11 different slots of GCC, 3 of gcc-apple, each with multiple versions, 3 versions of llvm-gcc, 2 versions of clang, 7 versions of icc, so in all 26 *major* versions. You do well know that each compiler prints out different warnings for the *same* code... We also offer 10 versions of glibc, 8 versions of uclibc, and 7 versions of klibc. Each version may have header bugs, so may trigger warnings for perfectly good code. And finally we offer 5 unmasked versions of binutils (newer ones even have a brand new linker - gold) and 5 versions of binutils-apple. Again, different tools, different warnings... If you want to make -Werror mandatory, you *MUST* test all combinations above as *THEY ARE ALL SUPPORTED*. Otherwise, packages will break for no good reason and users will hate us. -Werror is a perfectly fine *developer* feature. For example, Gnome autoconf macros enable it for development snapshots, but never ever enable it for stable releases. So please, if you want to write nonsense, don't write it in the name of Gentoo. Rémi PS, Diego (flameeyes) is already having enough issues with his tinderbox running *ONE* compiler/linker/libc combination...
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sat, 26 Jun 2010 21:57:33 +0200 Enrico Weigelt wrote: > > > #2 One point i don't agree is the "dont add -Werror" rule. actually, > > > i'm thinking of making -Wall and -Werror mandatory. if some > > > package doenst build fine, it's simply broken. period. > > > > Uhm. No. Certain compilers will give you warnings for f(g(a), g(b)) if > > you -Wall. > > Warn on what exactly ? Which compilers do that ? I suggest you to try latest available dev-lang/icc (11.1.072). This thing is really paranoid: remark #2259: non-pointer conversion from "int" to "unsigned char" may lose significant bits unsigned char BlinkerPhase = 0; ... BlinkerPhase = (BlinkerPhase + 1) & 3; remark #981: operands are evaluated in unspecified order (tons of them) return strcmp( left.c_str(), right.c_str() ) > 0; -- Sergei
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sat, 2010-06-26 at 21:46 +0200, Enrico Weigelt wrote: > BTW: if upstream has an proper VCS and an canonical tagging > scheme, they don't actually have to create release tarballs, > just hack up a little script which creates them on-the-fly > from an canonical URL scheme (eg. oss-qm does exactly that). This breaks badly when the upstream tarball generation is changed. This happened to github a few months ago and broke all our manifests. To their credit they quickly reverted what turned out to be a gratuitous change, but if they ever need to make a real change we get to redigest everything. Kind regards, Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sun, Jun 27, 2010 at 1:29 AM, Ciaran McCreesh wrote: > On Sat, 26 Jun 2010 21:46:39 +0200 > Enrico Weigelt wrote: >> BTW: if upstream has an proper VCS and an canonical tagging >> scheme, they don't actually have to create release tarballs, >> just hack up a little script which creates them on-the-fly >> from an canonical URL scheme (eg. oss-qm does exactly that). > > Down that path lies madness. There's no guarantee that you'll get the > same tarball if you request the same URL twice in a row, particularly > if you're using one of those new-fangled new compression schemes. > Or if they generate the tarball on-the-fly with no caching, which results in differing timestamps each time. Hence, each time you fetch it, you get a tarball with a different hash. No, don't ask where I saw such a thing :p -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On Sat, 26 Jun 2010 22:09:09 +0200 Enrico Weigelt wrote: > Well, with git this works. (I'll yet have to run some automatic > stress tests, but at all my manual tests worked really fine). You assume that, given the same input and program options, a compression program will always produce the same output. This is not the case. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Krzysztof Pawlik schrieb: > > Down that path lies madness. There's no guarantee that you'll get the > > same tarball if you request the same URL twice in a row, particularly > > if you're using one of those new-fangled new compression schemes. > > I agree with Ciaran here, to add one more thing: tags can be mutable. Thats a matter of proper VCS configuration (hooks, etc) 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-dev] FYI: Rules for distro-friendly packages
* Ciaran McCreesh schrieb: > On Sat, 26 Jun 2010 21:46:39 +0200 > Enrico Weigelt wrote: > > BTW: if upstream has an proper VCS and an canonical tagging > > scheme, they don't actually have to create release tarballs, > > just hack up a little script which creates them on-the-fly > > from an canonical URL scheme (eg. oss-qm does exactly that). > > Down that path lies madness. There's no guarantee that you'll get the > same tarball if you request the same URL twice in a row, particularly > if you're using one of those new-fangled new compression schemes. Well, with git this works. (I'll yet have to run some automatic stress tests, but at all my manual tests worked really fine). *If* this might not work somewhere, the little generator script could create the tarball only once (on first request) and use it all the time. Or add some commit/push hook, etc, etc. 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-dev] FYI: Rules for distro-friendly packages
On Sat, 26 Jun 2010 21:57:33 +0200 Enrico Weigelt wrote: > > Uhm. No. Certain compilers will give you warnings for f(g(a), g(b)) > > if you -Wall. > > Warn on what exactly ? That f's arguments are evaluated in an unspecified order. > Which compilers do that ? For all you know, gcc 4.7. New gcc releases regularly issue lots of new warnings for correct code, particularly with -Wall. Other compilers are even worse. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On 06/26/10 20:59, Ciaran McCreesh wrote: > On Sat, 26 Jun 2010 21:46:39 +0200 > Enrico Weigelt wrote: >> BTW: if upstream has an proper VCS and an canonical tagging >> scheme, they don't actually have to create release tarballs, >> just hack up a little script which creates them on-the-fly >> from an canonical URL scheme (eg. oss-qm does exactly that). > > Down that path lies madness. There's no guarantee that you'll get the > same tarball if you request the same URL twice in a row, particularly > if you're using one of those new-fangled new compression schemes. I agree with Ciaran here, to add one more thing: tags can be mutable. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Ciaran McCreesh schrieb: > On Sat, 26 Jun 2010 21:39:15 +0200 > Enrico Weigelt wrote: > > #2 One point i don't agree is the "dont add -Werror" rule. actually, > > i'm thinking of making -Wall and -Werror mandatory. if some > > package doenst build fine, it's simply broken. period. > > Uhm. No. Certain compilers will give you warnings for f(g(a), g(b)) if > you -Wall. Warn on what exactly ? Which compilers do that ? 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-dev] FYI: Rules for distro-friendly packages
On Sat, 26 Jun 2010 21:46:39 +0200 Enrico Weigelt wrote: > BTW: if upstream has an proper VCS and an canonical tagging > scheme, they don't actually have to create release tarballs, > just hack up a little script which creates them on-the-fly > from an canonical URL scheme (eg. oss-qm does exactly that). Down that path lies madness. There's no guarantee that you'll get the same tarball if you request the same URL twice in a row, particularly if you're using one of those new-fangled new compression schemes. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Krzysztof Pawlik schrieb: > > Hmm, this document suggests something, I just forgot to prohibit: > > > > "Release the source archives along with whatever binary archives you may > > have." > > ^ > > You intend to "prohibit" releasing binary packages for upstream? No, I'm talking about precompiled stuff within the source tree. Such things should _never ever_ happen. In Java world it seems to be quite common to bundle precompiled imported libraries within the source tree. Needless to say that this can easily get hell for any package-based distro. (actually, that mostly comes from the windows front, where concepts like package management are quite unknown ... ;-o) > What's important in quoted sentence is: "Release the source archives along > with > binary archives" - the "with" is very important - in short: don't release only > binary versions and force us to grab them from VCS. Okay, perhaps I misunderstood this sentence. BTW: if upstream has an proper VCS and an canonical tagging scheme, they don't actually have to create release tarballs, just hack up a little script which creates them on-the-fly from an canonical URL scheme (eg. oss-qm does exactly that). 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-dev] FYI: Rules for distro-friendly packages
On Sat, 26 Jun 2010 21:39:15 +0200 Enrico Weigelt wrote: > #2 One point i don't agree is the "dont add -Werror" rule. actually, > i'm thinking of making -Wall and -Werror mandatory. if some > package doenst build fine, it's simply broken. period. Uhm. No. Certain compilers will give you warnings for f(g(a), g(b)) if you -Wall. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Petteri Räty schrieb: > There should be useful stuff here: > http://video.fosdem.org/2010/devrooms/distributions/How_to_be_a_good_upstream.ogv #1 he says nothing about that - if upstream has a VCS (and properly uses it ;-o) - the distros should use it, so eg. set their branches ontop the upstream's release tags instead of manually maintaining patches against tarballs ... #2 One point i don't agree is the "dont add -Werror" rule. actually, i'm thinking of making -Wall and -Werror mandatory. if some package doenst build fine, it's simply broken. period. #3 When he's talking about "disabling dependencies", he most likely has the totally wrong concept in mind (as probably most Gentoo folks ;-p): you naturally dont want to enable/disable dependencies, but features (which then imply certain dependencies). Once you use terms like "zlib support", you're already on the wrong path. #4 The discussion about "how to be a good downstream" (started by the ffmpeg guy) is quite interesting ... that's exactly the kind of situations what the OSS-QM (see my recent posts) is for. (and all goes sooo easy w/ tools like git ;-p) 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-dev] FYI: Rules for distro-friendly packages
On 06/26/10 19:51, Enrico Weigelt wrote: > * Krzysztof Pawlik schrieb: > >> Take a look at this page: >> http://overlays.gentoo.org/proj/java/wiki/How_to_be_a_good_upstream - it is >> Java >> specific mostly, but some general points can be reused :) > > Hmm, this document suggests something, I just forgot to prohibit: > > "Release the source archives along with whatever binary archives you may > have." > ^ You intend to "prohibit" releasing binary packages for upstream? Thats... something you don't see everyday. Why would you do that? It's quite common for Java projects to release pre-built JAR files or for C/C++ (or other) based projects to release debs or rpms - it's standard practice. What's important in quoted sentence is: "Release the source archives along with binary archives" - the "with" is very important - in short: don't release only binary versions and force us to grab them from VCS. -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
* Alistair Bush schrieb: > Is this language specific? I'll try to separate it into generic and language specific rules step by step (same for various build systems, etc). > would you be interested in comments about java, ruby, python, > etc, etc, etc or are you only interested in good old C/C++, etc Just give me everything you've got :) 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-dev] FYI: Rules for distro-friendly packages
* Krzysztof Pawlik schrieb: > Take a look at this page: > http://overlays.gentoo.org/proj/java/wiki/How_to_be_a_good_upstream - it is > Java > specific mostly, but some general points can be reused :) Hmm, this document suggests something, I just forgot to prohibit: "Release the source archives along with whatever binary archives you may have." ^ 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-dev] FYI: Rules for distro-friendly packages
On 06/25/2010 11:17 PM, 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 :) > There should be useful stuff here: http://video.fosdem.org/2010/devrooms/distributions/How_to_be_a_good_upstream.ogv Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On 06/25/10 21:17, Enrico Weigelt wrote: > I'm currently collecting a set of rules which upstream developers > should follow to make distro maintainer's life easier. > > Comments welcomed :) Take a look at this page: http://overlays.gentoo.org/proj/java/wiki/How_to_be_a_good_upstream - it is Java specific mostly, but some general points can be reused :) -- Krzysztof Pawlikkey id: 0xF6A80E46 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] 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 :) > Is this language specific? would you be interested in comments about java, ruby, python, etc, etc, etc or are you only interested in good old C/C++, etc > > cu
[gentoo-dev] 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/ -
