[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: No native packages?

Philip Hands <phil@hands.com> writes:

> Gergely Nagy <algernon@balabit.hu> writes:
> ...
>> 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)
> So to summarise your argument appears to be that it sets a bad example
> (which is only a valid criticism if you manage to show why it's a bad
> idea in the first place) and that you don't like people not using all
> the same tools you use.

No, not really. I don't really care what tools one uses, as long as the
result is reasonably easy *and* reliable to work with. Since VCS can be
stale, and quite often does not include neither NMUs, nor backports,
that fails the reliable requirement.

Exceptions exist, and three cheers for them! Only if they weren't the

> If the person doing the packaging is the upstream, you're asking them to
> pretend to be two people, and decide when a patch is debian specific or
> not, and then learn a load of tools that they have no use for in order
> to keep their personality neatly split.

If the change is under debian/, then it is debian specific, otherwise it
is not. That's a reasonable rule of thumb, and doing just this would
entirely satisfy me. Doesn't need a personality split, in my opinion.

There's also the case where upstream and debian maintainer are the same
*now*, but that can change anytime. Case in point: there's a package[1]
in Debian where upstream & maintainer used to be the same, but not
anymore. Nevertheless, for hysterical reasons, upstream is still
shipping a debian/ dir, an outdated and crappy one, which, from time to
time, still confuses the hell out of people who download the original
tarball. That sucks. It's an upstream problem, but it wouldn't have
happend in the first place, if packaging & upstream work weren't tied
together so tightly in the past.

 [1]: syslog-ng

Anyway, I'll expand on this later, see the end of my mail.

> I know a couple of upstreams who use native packages for their stuff,
> and I'm pretty sure one or both of them would give up if we insisted
> that they add unnecessary and confusing extra steps to their workflow.

What steps would be confusing?

> Currently they just incorporate the debian directory into their tree, add
> a couple of steps to their release Makefile target, and whenever they
> release a new version, it's ready for Debian too.

Instead of adding a few steps to my release target, I have a script that
checks out the debian branch, merges master, and dch -i. It's about 5
lines long, and pretty much the same thing as a Makefile target. I could
also wire it into a release target, if I had one.

It's neither confusing, nor any extra work, apart from about 5 minutes
spent on thinking about the workflow, once.

> You're going to have to do a lot better than saying that you don't like
> it very much if you're going to convince me that Joey's mistaken in that
> choice -- particularly since he comes up with pretty decent arguments in
> the opposite direction -- see his answer here:
>   http://ask.debian.net/questions/does-native-package-needs-to-be-debian-specific-if-upstrean-author-is-a-mantainer

I don't want to convince you that Joey is mistaken, for he is
not. There's nothing inherently wrong with native packages, and there
are plenty of cases where they make sense (I maintain two native
packages myself, there's no possible way to convince me they should be
made non-native), Joey has strong arguments for him handling his
packages native, and I agree with him on that.

But the same arguments don't hold for everyone.

> Certainly there seems to have been no acknowledgement that there are
> good examples available that break that rule.

I beg to differ:

Perhaps I should've phrased it differently, but I believe my message
there was quite clear nevertheless.

> On the other hand, it's pretty obvious that one will be able to point to
> examples where the package clearly should not be native, but that
> doesn't tell one much about the general case -- this thread seems to
> boil down to:
>    Look, here's a bad thing, therefore all things are bad.

I don't know where you got that from. Most of us posting in this thread
have expressed that native packages aren't the problem, their abuse
is. In my reading, it boils down to:

  "Look, here's a bad thing, and bad things are spreading. Lets stop the
  bad things."

Granted, we didn't really explain what that "abuse" is, so let me try to
do that!

* In my opinion, a native package is always a wrong choice when upstream
  and debian maintainer are not the same. This is still the case if the
  debian maintainer is part of upstream, but is not the sole upstream.

  I hope I don't need to explain this further.

* In my opinion, a native package is the wrong choice when your only
  arguments for it is convenience.

  That's not a strong argument, and we can most probably list a bunch of
  counter arguments:

   * Makes it harder for downstreams to patch
     (Have to figure out a version number, and hope it won't conflict,
     etc. It is also harder to separate downstream patches from
     upstream, VCS doesn't always help [esp. when they're stale])
   * Makes NMUs more awkward

There are probably other cases where I'd consider native packages a
wrong choice, but off the top of my head, I could only list this two. If
so need be, I'll spend a few more brain cycles on digging up the rest.

There are good arguments *for* a native package, as Joey listed, and
they can work well if upstream == maintainer. But as soon as that
relationship breaks, for whatever reason, care needs to be taken both
upstream and both in packaging to ensure a smooth transition. I've seen
that fail before, though, not with native packages.

When trying to avoid downstream forks, when trying to maintain strong
control over the package, a native package can also work fairly well.

But these two are the only reasons I can find that support native
packages, they're a good fit in these cases. But using them out of sheer
laziness, having no better reason that convenience? That's weak, and
that's what *I* would like to see disappear.


Reply to: