Re: No native packages?
On Mon, Jan 28, 2013 at 09:44:18AM +0100, Gergely Nagy wrote:
> 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,
Doing something for the sake of convenience is not a bad thing. On the
contrary; inconvenience is (terribly) bad for motivation and
productivity.
> it becomes that much easier to give in to temptation, and use native
> packaging even when it does have harmful side-effects.
That's a recursive argument: You're trying to convince me that doing
something is bad simply because doing it may cause us to do it more. But
if I don't think that "doing it more" is a problem any more than doing
that something in the first place is, you've not actually convinced me.
> By harmful side effects, I mean two things:
>
> - Awkward to NMU
As I said in my previous mail, that's indeed a bug that should be fixed.
> - Patches not separated
That's not a bug; it can be a feature, and even when it's not it can be
argued that it's not a terrible issue. Packages should be in SCM, and
you should have some form of communication with people who package work
with your code. If you don't, you have a bigger problem than whether or
not you're using native packages.
> 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 there aren't diffs, running debdiff isn't hard.
It's true that if the code has diverged a lot, figuring out the
individual, separate changes that are applied to the original code can
be a hard job. However, before that becomes a problem, the code itself
needs to be sufficiently large (it's pretty hard to lose track of the
changes made to a package containing a single script of, say, a few
hundred lines of code).
As I said before, I'm not advocating that you would maintain a
sufficiently large codebase as a native package. So in the situations
that I think native packages make sense, this isn't actually an issue.
(and to give you an idea of what I consider to be "sufficiently large",
I've never been tempted to repackage nbd as a native package, even though I
could, which is...
wouter@carillon:~/code/c/nbd$ wc -l *.h *.c
168 cliserv.h
201 config.h
19 lfs.h
82 nbd.h
24 netdb-compat.h
94 make-integrityhuge.c
682 nbd-client.c
2781 nbd-server.c
1320 nbd-tester-client.c
115 nbd-trdump.c
5486 total
... well, not very large either)
[...]
> > 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.
It's not just about creating it, but also about it not being worth it.
> 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,
Well, if you're not doing an upstream build system, then you're not
providing anything beyond your Debian package. The net result is that
you're not doing anything that couldn't be done by way of a native
package too, while lying to potential non-Debian downstreams that you're
considering their use case too.
That's just silly.
If you don't have an upstream build system, you only have a package. If
you only have a package, it should be a native package, and not have a
non-functional upstream tarball, because that is evil.
--
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.
Reply to: