Re: No native packages?
Wouter Verhelst <wouter@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]
Reply to: