Re: No native packages?
Wouter Verhelst <wouter@debian.org> writes:
> 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.
Doing something for the sake of convenience is not, in itself, a bad
thing indeed. Even with native packages, if you know what you're doing,
and you're careful, you're not doing any harm, either. However, that's
you, with a ton of experience behind your back, and deep knowledge of
Debian.
Then someone comes along, looking for examples, and sees a growing
number of native packages: "Oh hey, this is easy, I'll do this too!"
And things go downhill from there. There *are* cases where native
packages are inappropriate, and it is already a pain in the backside at
times to convince people new to Debian that native packages do have
unwelcome properties in certain cases.
My belief is that Debian packages should not only be technically sound
(which a lot of them already are), but should also set a good example
for those who are looking for inspiration, for ideas.
It is a bit more work for the packager, yes, but I've yet to see a case
where the extra work would not be trivially scriptable to the point that
one only needs to remember a command or two - which is, as far as I'm
concerned, far below the annoying threshold. (I know counter examples
must exist, but for the general case, I doubt that the debian-upstream
split would be all that hard, not even in the long run.)
>> 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.
Imagine gcc or the linux kernel being native packages then.
>> 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.
Easily fixable by making the package non-native.
>> - 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.
That's a terribly sweet idea, but in practice, it doesn't work. If it
would, I'd be the happiest person on earth.
First of all, not all downstreams use an SCM (shocking, I know), and not
all of them keep them up to date, especially if their SCM is located
elsewhere than upstream's. I've seen both NMUs and downstream packages
which were supposed to be in SCM, but the SCM was out of date. I'd love
to trust downstream SCMs, but experience shows that rarely works, and my
most stable point is whatever they have in their archive - and that's
the Debian source package.
I'd love if downstream talked to me directly, and sometimes they do,
sometimes their SCM is even up-to-date, but most of the time, we talk in
patches (which is also good, but what patches they send me, and what is
in their archive often differs, as some patches are deemed 'unimportant'
or 'irrelevant' for Debian - which they may be, but let me decide that,
thankyouvermuch).
In summary, yes, I have bigger problems than native packages, and that
sucks, but native packages add insult to injury, because even if
communication fails, I have a hard time inspecting what they do, because
I lack the nicely separated patches.
>> 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.
...except it is useless if the diff contains multiple independent
changes, and I have to separate them manually. Been there, done that,
wasn't fun.
> 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).
Yep, that is true. But small packages are the least of my worries. See
below, though, some of the things I explain there applies even to things
that are only 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.
...except that it sets a bad example (see above), and makes it harder to
convince people who do want to maintain a larger code base, to not do it
as a native package. "But XYZ is doing it, with a much larger codebase!
IT WORKS!"
Perhaps it is just me, but I'd like to think that my packages are of
good quality, and that they can serve as good examples (or in rare cases
[hi, shoop! I miss you <3], as terrifying ones). I'm ready to sacrifice
the minor convenience native packaging would buy me, so that those who
have to work with my packages downstream, or those who look at them for
inspiration, will find it easier to work with them.
I like to think this is worth the effort. So far, the sacrifices made
have been minor, usually only as much as debian/source/git-patches file
(for gitpkg) and a git checkout debian && git merge master from time to
time.
>> > 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.
See above. It may not seem worthy to you, but for downstream, or for
other people working with your package, it very well may be. It's not
only about you, in my opinion.
I for one, when I'm acting as downstream (which sadly I sometimes I have
to, either when I'm backporting something, or when I do stuff for
$work), hate having to work with native packages. It's inconvenient at
best, and downright painful when it's not even using an SCM. But even
when an SCM is used, merging is more painful when it needs be: I usually
get both upstream and debian packaging patches, even when I'm interested
only in the former. Having to manually separate the two is more work for
me.
> 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.
There are cases where an upstream build system is completely
unnecessary: when there's nothing to build, and all you need to install
can easily be done with debian/install.
That does not mean I'm not considering downstream's use cases, it just
means that an upstream build system is not necessary. (Take for example
git-flow, which does have an upstream build system, but it's almost
completely pointless)
If I'd do all building things that one normally does with auto* in
debian/rules, now THAT would be 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.
If your software does not need a build system, there's little point in
trying to add one. There are software you do not need to build, and the
only thing you need is put various parts of it onto $PATH somewhere. I
wouldn't write a full blown build system for that.
--
|8]
Reply to: