Wouter Verhelst <wou...@debian.org> writes: > On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote: >> Dmitrijs Ledkovs wrote on his blog[0]: >> >> >Generally if software is useful in Debian Project it can be useful >> >for other debian-like and unlike projects. In particular native >> >packages do not offer the same patching flexibility as 3.0 >> >(quilt), thus forcing downstream distributions to inline modify >> >packages without DEP-3 headers. This hurts us, when trying to >> >merge useful stuff from derivatives back into Debian, as changes >> >are not split into individual patches. >> >> I would tend to agree that we have too many native packages, > > There can only be "too many" of anything if it is (or can be) harmful in > some way to have the thing in question.
Perhaps not a convincing argument, but one of the main reasons I mightily dislike native packages for things that aren't Debian specific in any way, is because it sets a bad example. If you see native packages being abused for the sake of convenience, it becomes that much easier to give in to temptation, and use native packaging even when it does have harmful side-effects. By harmful side effects, I mean two things: - Awkward to NMU - Patches not separated While separating patches is often seen as an inconvenience, a useless one at that in the world of SCMs, it does reduce the amount of space needed to store the result, it makes it easier to review the difference between two versions. Granted, one can look at the SCM repository, but there are times when that's far more work than paging through a set of diffs: ie, comparing two versions of a Debian package. If there are diffs, that's easy. If I have to turn to an SCM, I have to figure out its setup (and hope it is documented, which it often is not), and trust that tags and whatnot does reflect what is in the package. That trust is something I do not have, as I've seen it too many times that downstream package and downstream SCM branch did not agree. In an ideal world, this wouldn't be an issue, but we're not living in that world yet. In short, too many native packages, even if they're used in situations where they do not immediately become a problem, does set a bad example, and serves as an excuse to use them even when they're inappropriate. So, for the sake of prospective maintainers, I'd love to get the number of these packages down. > While I agree that in some cases it might be a bad idea to package > something as a native package, for trivial things (like my package > "fdpowermon"), this isn't a big deal; and the overhead of having to deal > with an upstream tarball and/or upstream build system etc is just not > worth it. We have tools that make it easy to create upstream tarballs from an SCM repo. Git has git archive, gitpkg and possibly other tools make it very easy to create upstream tarballs: so much so, that it means nothing more than tagging the repo properly. I've been using this for quite a while for some of my packages (ivykis, libmongo-client), and it doesn't need neither an upstream build system, nor much thought once it is set up. (And setup is fairly trivial too) -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5fd66jh.fsf@algernon.balabit