On Thu, 2010-04-01 at 08:43 +0200, Gilles Dartiguelongue wrote: > Guys, > > although this might sound like a good idea, please remember a couple of > things: > * upstream generally doesn't know well about respective > distributions build system which means they will most likely > make mistakes and end up not maintaining it that much > * downstream already does the job of packaging for their distro > fine with people dedicated to that QA checks, ... as long as the > package is well behaved (like most autotools/cmake based > packages are), the work is even easy > * your favorite distribution provides an easy way to > rebuild/update yourself the package, apt-get source, rpmsrc, cp > for gentoo, ... > > I hope this makes it clear that downstream stuff has no place in > upstream repositories. +1. Usually Debian-based downstreams like to download the upstream source code, and use it as is -- no changes at all to the downloaded source code. Patches -- again, against the downloaded source -- are stored under ./debian/patches. Now, picture an upstream that is also sort-of debianised. All is done correct, except we need some additional patches. Disaster. We would have to change the upstream code as provided by upstream. We would have to update ./debian/changelog to cater for our patches. And so on. There are ways out of it -- use a get-orig-source rule in the makefile (./debian/rules) that will strip off the ./debian directory, and create a *new* distribution tarball. Nasty. Of course, this is not the single issue. What would rpm-based distros do with a debianised source? Etc, etc, etc. This would not be an issue if the upstream maintainer happens to be also a downstream maintainer. But, again, what would a RedHat maintainer do with a ./debian? Regards, ..C..
Attachment:
signature.asc
Description: This is a digitally signed message part