Re: No native packages?

[Gergely Nagy]

Jakub Wilk  writes:

> 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, though I
> doubt you'll find (m)any supporters of the idea of banning them
> completely.

There are two native packages I maintain, and I've yet to hear a good
reason for making either of them non-native. Making it harder and much
much more inconvenient for downstream distributions to modify them is a
*goal* in these cases: to make it harder to diverge from one
another.

As for no DEP-3? I do sincerely hope that by 2013, everyone's using a
VCS, and we can pick patches from there.

-- 
|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/87libemq8v.fsf@algernon.balabit

Re: No native packages?

[Arno Töll]

Hi,

On 27.01.2013 19:32, Gergely Nagy wrote:
> There are two native packages I maintain, and I've yet to hear a good
> reason for making either of them non-native. 

Not knowing your use cases in particular, it would often be good enough
if we could restrict native packages to use cases, where they actually
were designed for.

We have native packages in Debian where people deliberately use them,
because they are more convenient (i.e. less strict) and easier to use
(no need for orig tarballs). I don't think we should endorse that any
further, so I agree with Jakub in that.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: No native packages?

[Gergely Nagy]

Arno Töll  writes:

> Hi,
>
> On 27.01.2013 19:32, Gergely Nagy wrote:
>> There are two native packages I maintain, and I've yet to hear a good
>> reason for making either of them non-native. 
>
> Not knowing your use cases in particular, it would often be good enough
> if we could restrict native packages to use cases, where they actually
> were designed for.

Completely agreed.

> We have native packages in Debian where people deliberately use them,
> because they are more convenient (i.e. less strict) and easier to use
> (no need for orig tarballs). I don't think we should endorse that any
> further, so I agree with Jakub in that.

Perhaps we should figure out how to make it easier to create orig
tarballs (though, gitpkg does a pretty good job there, imo), and prod
the native (ab)users to see how their workflow can be made easier even
with non-native packaging.

-- 
|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/87ehh6mnv1.fsf@algernon.balabit

Re: No native packages?

[Wouter Verhelst]

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.

I've yet to see a convincing argument why using native packages would be
harmful in any way. The argument about "merging patches" doesn't
convince me, at all; mostly because "downloading a source package and
inspecting it" isn't what I would consider an interesting way to
communicate with downstreams. Instead, I'd hope they talk to me, or put
their stuff in a SCM repository somewhere (all my packages are), or some
such.

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.

> though I doubt you'll find (m)any supporters of the idea of banning
> them completely.
> 
> It's not only about derivatives, but also in-Debian forking, i.e.
> NMUs. NMUing native packages is quite awkward.

That's a bug then, which we should fix. Banning native packages isn't a
fix, however, it's a copout.

-- 
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.


-- 
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/20130127214939.gk31...@grep.be

Re: No native packages?

[Gergely Nagy]

Wouter Verhelst  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

Re: No native packages?

[Dmitrijs Ledkovs]

On 27 January 2013 18:32, Gergely Nagy  wrote:
> Jakub Wilk  writes:
>
>> 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, though I
>> doubt you'll find (m)any supporters of the idea of banning them
>> completely.
>
> There are two native packages I maintain, and I've yet to hear a good
> reason for making either of them non-native. Making it harder and much
> much more inconvenient for downstream distributions to modify them is a
> *goal* in these cases: to make it harder to diverge from one
> another.
>
> As for no DEP-3? I do sincerely hope that by 2013, everyone's using a
> VCS, and we can pick patches from there.
>

If only we all can agree on the VCS to use. A patch seems to be the
common denominator.
Also, there are a lot of caveats with DVSC. I have seen a lot of
repositories where maintainers forgot to push commits and/or tags.
Or obsolete Vcs-* headers, because repository got moved, yet there was
no upload yet.
And that's easy to do, since the thing you upload to ftp doesn't
check/require for you to push anything.
NMUs & security uploads are often also missing from Vcs-* repositories.

Native packages is a social issue =) my view is that they set a bad
example and introduce a lot of "do this, unless it's native package".
Also some of the convenience stated, benefits Debian, but hurts
dowstream. As any packaging change, triggers a new .orig.tar.gz with a
new checksum.

Regards,

Dmitrijs.


-- 
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/CANBHLUjqBX8k=ddrlhpufddj_6q3dsfvmiaj_vc_xepvhf-...@mail.gmail.com

Re: No native packages?

[Philip Hands]

Gergely Nagy  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.

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.

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.

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.

Another example is Joey Hess (I know that ikiwiki is native, so is
git-annex, as are (IIRC) some others of his -- feel free to look them
up).

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

Cheers, Phil.

P.S. that answer from Joey took me seconds to find -- I find it
astonishing that some people in this thread seem to be starting from
their assumption that it is a hard-and-fast about native packages being
exclusive to Debian, and proceeding straight to trying to stop the
naughty transgressors without doing a moment's fact checking first, or
even bothering to come up with a cogent argument to justify their
assumption.  Certainly there seems to have been no acknowledgement that
there are good examples available that break that rule.

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'm sure we could be spending our time more productively.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpXLUSmdykFf.pgp
Description: PGP signature

Re: No native packages?

[Paul Wise]

On the other side of the fence are folks who believe in the separation
between upstream and Debian so much that they refuse to package
software they are upstream for (I'm not among them, but I know they
exist).

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/CAKTje6FM0QaX-Y64YFzAYMj=s8z-ibvtjkrsfyhpb2c0ro7...@mail.gmail.com

Re: No native packages?

[Gergely Nagy]

Philip Hands  writes:

> Gergely Nagy  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
exceptions...

> 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:
 http://lists.debian.org/debian-devel/2013/01/msg00588.html

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 sti

Re: No native packages?

[Tollef Fog Heen]

]] Gergely Nagy 

> 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.

It sounds like you are arguing that we should just ship the the
repository in the source package, then.  No chance of it ever getting
out of date, trivial to find the merge points and missing patches
between two packages and fits much better with a VCS-driven workflow.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87txq15lcx@xoog.err.no

Re: No native packages?

[Thorsten Glaser]

Gergely Nagy  balabit.hu> writes:

> 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]

That’s actually (one of) the reasons why I’m not using native packages
for the software I’m upstream of, or working closely with upstream. And
I know of lots of DDs who do the same. (And I’ve non-native-ised a number
of packages, too.)

It should probably not be a requirement but more than a suggestion.

And it *did* turn out that some software written and packaged for Debian
was, in the end, used on other systems… I was surprised.

bye,
//mirabilos


-- 
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/loom.20130128t180122-...@post.gmane.org

Re: No native packages?

[Russ Allbery]

Tollef Fog Heen  writes:
> ]] Gergely Nagy 

>> 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.

> It sounds like you are arguing that we should just ship the the
> repository in the source package, then.  No chance of it ever getting
> out of date, trivial to find the merge points and missing patches
> between two packages and fits much better with a VCS-driven workflow.

Yes, many of us would like that, which is why it's been repeatedly
discussed at Debconfs, but no one has come up with a good solution to the
fact that this requires reviewing the entire VCS archive for DFSG-freeness
and rewriting history if any non-free code is ever introduced in it.  (Or,
well, changing the requirements we have around source package freeness,
but that seems less likely.)

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87boc92or6@windlord.stanford.edu

Re: No native packages?

[Roger Leigh]

On Mon, Jan 28, 2013 at 09:36:45AM -0800, Russ Allbery wrote:
> Tollef Fog Heen  writes:
> > ]] Gergely Nagy 
> 
> >> 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.
> 
> > It sounds like you are arguing that we should just ship the the
> > repository in the source package, then.  No chance of it ever getting
> > out of date, trivial to find the merge points and missing patches
> > between two packages and fits much better with a VCS-driven workflow.
> 
> Yes, many of us would like that, which is why it's been repeatedly
> discussed at Debconfs, but no one has come up with a good solution to the
> fact that this requires reviewing the entire VCS archive for DFSG-freeness
> and rewriting history if any non-free code is ever introduced in it.  (Or,
> well, changing the requirements we have around source package freeness,
> but that seems less likely.)

Maybe I forgot the answer, but at least in terms of git and the dpkg
3.0 (git) format, why can't we simply make use of shallow cloning?  We
only distribute a single revision, the one we're building, and if the
history is polluted for whatever reason, it has no impact--we're only
providing the equivalent of a tarball.  The difference being, there's
nothing preventing anyone receiving the package from adding the
appropriate remotes and restoring the full history (at their choice),
so it retains its utility.  From the POV of review, it's then no
different to a plain tarball.  But from the POV of a developer, I can
fetch the history, add remotes, commit changes, push to somewhere and
open pull requests, etc..

At least for schroot, both the source and release are all in git, so
making the release tarball is nowadays a single "git archive".  Having the
ability to use 3.0 (git) would allow the use of a git workflow throughout
with zero intermediately formats like tar.

To get more back on topic, all the packages I maintain in Debian are
non-native.  It's more flexible, and it encourages separation of "upstream"
and "debian" releases, even when Debian /is/ the upstream.  So changes to
the actual package content go into proper "upstream" releases, and you
have the option to make as many Debian revisions as necessary.  It makes
things easier for derivatives and external users.  I don't think there's
any real difference in the amount of effort it takes to do non-native
releases, and I can't see any compelling reason for "native" releases
other than history.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20130128181720.gj29...@codelibre.net

Re: No native packages?

[Dmitrijs Ledkovs]

On 28 January 2013 18:17, Roger Leigh  wrote:
> On Mon, Jan 28, 2013 at 09:36:45AM -0800, Russ Allbery wrote:
>> Tollef Fog Heen  writes:
>> > ]] Gergely Nagy
>>
>> >> 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.
>>
>> > It sounds like you are arguing that we should just ship the the
>> > repository in the source package, then.  No chance of it ever getting
>> > out of date, trivial to find the merge points and missing patches
>> > between two packages and fits much better with a VCS-driven workflow.
>>
>> Yes, many of us would like that, which is why it's been repeatedly
>> discussed at Debconfs, but no one has come up with a good solution to the
>> fact that this requires reviewing the entire VCS archive for DFSG-freeness
>> and rewriting history if any non-free code is ever introduced in it.  (Or,
>> well, changing the requirements we have around source package freeness,
>> but that seems less likely.)
>
> Maybe I forgot the answer, but at least in terms of git and the dpkg
> 3.0 (git) format, why can't we simply make use of shallow cloning?  We

How many revisions does one need to shallow clone to have an .orig.
tree and a debian tree?
As one commonly still wants to see what changes are applied if any.
If the answer is 2 and git can diff them, than it's great.
(Or 3 to include pristine-tar delta?! do we still care about
pristine-tar at this point?!)

Regards,

Dmitrijs.


-- 
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/CANBHLUhmTL45FVNXkJe-DCwSr8E=nnmdvvem0yaadjpg1kc...@mail.gmail.com

Re: No native packages?

[Russ Allbery]

Roger Leigh  writes:

> Maybe I forgot the answer, but at least in terms of git and the dpkg 3.0
> (git) format, why can't we simply make use of shallow cloning?  We only
> distribute a single revision, the one we're building, and if the history
> is polluted for whatever reason, it has no impact--we're only providing
> the equivalent of a tarball.  The difference being, there's nothing
> preventing anyone receiving the package from adding the appropriate
> remotes and restoring the full history (at their choice), so it retains
> its utility.  From the POV of review, it's then no different to a plain
> tarball.  But from the POV of a developer, I can fetch the history, add
> remotes, commit changes, push to somewhere and open pull requests, etc..

My impression of the previous discussion is that the perceived benefits of
shallow clones weren't enough to do the work if all we were going to use
was just the minimal shallow clone, since at that point there seemed to be
little to gain for the user over using debcheckout, but the ftp team still
has to enforce the restrictions on shallow clones, deal with source
packages with more revisions than expected, etc.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87libd17wz@windlord.stanford.edu

Re: No native packages?

[Julien Cristau]

On Mon, Jan 28, 2013 at 18:17:20 +, Roger Leigh wrote:

> On Mon, Jan 28, 2013 at 09:36:45AM -0800, Russ Allbery wrote:
> > Tollef Fog Heen  writes:
> > > ]] Gergely Nagy 
> > 
> > >> 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.
> > 
> > > It sounds like you are arguing that we should just ship the the
> > > repository in the source package, then.  No chance of it ever getting
> > > out of date, trivial to find the merge points and missing patches
> > > between two packages and fits much better with a VCS-driven workflow.
> > 
> > Yes, many of us would like that, which is why it's been repeatedly
> > discussed at Debconfs, but no one has come up with a good solution to the
> > fact that this requires reviewing the entire VCS archive for DFSG-freeness
> > and rewriting history if any non-free code is ever introduced in it.  (Or,
> > well, changing the requirements we have around source package freeness,
> > but that seems less likely.)
> 
> Maybe I forgot the answer, but at least in terms of git and the dpkg
> 3.0 (git) format, why can't we simply make use of shallow cloning?

At which point you have lost all the advantages of shipping the
repository that Tollef mentioned, as far as I can tell.  You're back to
needing an external repository that's kept up to date if you ever need
to get at the history.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: No native packages?

[Craig Small]

On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote:
> I am guilty myself of maintaining a native package (and another one
> is waiting in NEW). However, I will be happy to switch to a
> non-native format once I figure out a releasing work-flow that is
> convenient for me.
Changing from native packages to non-native sounds like increasing my
work-load for absolutely no gain to Debian (or myself). 
Harder to merge downstream changes? How? We know how to merge
patches don't we?

I do double-releases for other stuff; its a pain but for those cases
essential. I don't recommend it if you don't need to.

 - Craig

-- 
Craig Small VK2XLZ   http://enc.com.au/  csmall at : enc.com.au
Debian GNU/Linux http://www.debian.org/  csmall at : debian.org
GPG fingerprint: 5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5


-- 
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/20130128214934.ga14...@enc.com.au

Re: No native packages?

[Benjamin Drung]

Am Dienstag, den 29.01.2013, 08:49 +1100 schrieb Craig Small:
> On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote:
> > I am guilty myself of maintaining a native package (and another one
> > is waiting in NEW). However, I will be happy to switch to a
> > non-native format once I figure out a releasing work-flow that is
> > convenient for me.
> Changing from native packages to non-native sounds like increasing my
> work-load for absolutely no gain to Debian (or myself). 

Other distributions gain from your extra work. Image the opposite. You
want to package a software that is only available in a downstream
distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a
non-native format or a native format?

-- 
Benjamin Drung
Debian & Ubuntu Developer


-- 
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/1359413996.4795.2.camel@deep-thought

Re: No native packages?

[Cyril Brulebois]

Benjamin Drung  (28/01/2013):
> Other distributions gain from your extra work. Image the
> opposite. You want to package a software that is only available in a
> downstream distribution (e.g. Ubuntu or Linux Mint). Do you prefer
> to have a non-native format or a native format?

“upstream first” anyone?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: No native packages?

[Craig Small]

On Mon, Jan 28, 2013 at 11:59:56PM +0100, Benjamin Drung wrote:
> Other distributions gain from your extra work. Image the opposite. You
> want to package a software that is only available in a downstream
> distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a
> non-native format or a native format?
If I want it enough I'm not going to care.

 - Craig
-- 
Craig Small VK2XLZ   http://enc.com.au/  csmall at : enc.com.au
Debian GNU/Linux http://www.debian.org/  csmall at : debian.org
GPG fingerprint: 5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5


-- 
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/20130129002044.ga25...@enc.com.au

Re: No native packages?

[Russ Allbery]

Benjamin Drung  writes:

> Other distributions gain from your extra work. Image the opposite. You
> want to package a software that is only available in a downstream
> distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a
> non-native format or a native format?

I'm not sure I see how it makes any difference.  Either way, I would start
with their package and add Debian packaging files for Debian.  The only
difference is some minor variation in what commands I run at the very
start of that process (namely, git-import-dsc for a non-native package
vs. git-import-orig for a native package).  I have a hard time seeing how
this choice would make more than thirty seconds of difference to my
workflow.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87obg8x24j@windlord.stanford.edu

Re: No native packages?

[Wouter Verhelst]

On Mon, Jan 28, 2013 at 09:44:18AM +0100, Gergely Nagy wrote:
> Wouter Verhelst  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-fun

Re: No native packages?

[Peter Samuelson]

[Benjamin Drung]
> Image the opposite. You want to package a software that is only
> available in a downstream distribution (e.g. Ubuntu or Linux
> Mint). Do you prefer to have a non-native format or a native format?

If their native format is an archive in gzipped tar file format, like
ours is, I'm not sure I would care, if I even _notice_, that there is
packaging metadata for some other operating system in there.  In fact
it's not at all uncommon for upstream projects to ship .spec files,
.vcproj files, and other platform-specific build infrastructure.

Maybe you're thinking of the inconvenience of the top-level 'debian'
directory, which is rather inflexible in that all Debian distributions
and derivatives use the same path for their own use, but that ceased to
be a problem several dpkg releases ago.


-- 
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/20130129045301.gr4...@p12n.org

Re: No native packages?

[Tollef Fog Heen]

]] Russ Allbery 

> Tollef Fog Heen  writes:
> > ]] Gergely Nagy 
> 
> >> 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.
> 
> > It sounds like you are arguing that we should just ship the the
> > repository in the source package, then.  No chance of it ever getting
> > out of date, trivial to find the merge points and missing patches
> > between two packages and fits much better with a VCS-driven workflow.
> 
> Yes, many of us would like that, which is why it's been repeatedly
> discussed at Debconfs, but no one has come up with a good solution to the
> fact that this requires reviewing the entire VCS archive for DFSG-freeness
> and rewriting history if any non-free code is ever introduced in it.

I wasn't trying to imply that my idea was new. :-) Yes, this is a lot of
work, and I'm not sure what the best way to go about it would be.  On
the other hand, I think we're not actually shipping the real source if
we're not shipping that metadata.  The most useful definition of source
I've seen is the «preferred format for modification» one, and if we need
or prefer something outside the source package to do useful things with
it (such as looking at what patches are applied, who wrote them and
when), the source package is not the real source.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
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/874ni04jw4@xoog.err.no

Re: No native packages?

[Stefano Zacchiroli]

On Tue, Jan 29, 2013 at 12:59:28AM +0100, Cyril Brulebois wrote:
> Benjamin Drung  (28/01/2013):
> > Other distributions gain from your extra work. Image the
> > opposite. You want to package a software that is only available in a
> > downstream distribution (e.g. Ubuntu or Linux Mint). Do you prefer
> > to have a non-native format or a native format?
> 
> “upstream first” anyone?

Well, no. At least for me it has always been "always upstream,
eventually", i.e. every tier in software distribution shall strive to
have their changes integrated upstream, eventually. Which is not quite
the same as "upstream *first*".

The difference for me is relevant, because downstreams often have to
*first* patch and distribute their own versions, due to schedule
unalignment with their own upstreams. And then consolidate afterwards.
And note that the matter of schedule is not only a matter of "we have a
really fast release cycle" as, say, Ubuntu wrt Debian. Even in Debian we
often face non reactive (to our standards) upstreams, and then have to
patch our packages right away to make an upload, being able to have the
patches integrated upstreams only much later.  It's all relative,
really, and depends on the time availability of the two peers at any
upstream/downstream border.

This is why I'm personally very much in favor of discouraging native
packages wherever possible. With non-native packages, at least with
current packaging technologies, patches are first class citizens.
Downstreams can add a patch simply dropping a file in debian/. That then
remains essentially the same throughout its lifetime. From inception (by
downstream) to the moment it's forwarded either to us (Debian) or
directly to the rightful last tier upstream. Whereas all this gets a
little more complex with native packages.

This is surely not an excuse that relieves downstreams of the moral duty
of upstreaming their changes (moral duty that apply to Debian as well as
anyone else, mind you). But I think it is in the interest of each
upstreams (including ourselves) to make it as easy as possible for
downstreams to first apply patches, according to their own schedule and
needs, and then forward them upstream.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: No native packages?

[Roland Mas]

Gergely Nagy, 2013-01-28 09:44:18 +0100 :

[...]

> By harmful side effects, I mean two things:
[...]
>  - Patches not separated

  Not quite true.  You can still have debian/patches/* and apply them at
build-time (dpatch or quilt), even if they're not shipped in a separate
.diff.gz file.

Roland.
-- 
Roland Mas

The best definition of an immortal is someone who hasn't died yet.
  -- in Ye Gods! (Tom Holt)


-- 
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/87obg8wg4c@polymir.internal.placard.fr.eu.org

Re: No native packages?

[Gergely Nagy]

Tollef Fog Heen  writes:

> ]] Gergely Nagy 
>
>> 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.
>
> It sounds like you are arguing that we should just ship the the
> repository in the source package, then.  No chance of it ever getting
> out of date, trivial to find the merge points and missing patches
> between two packages and fits much better with a VCS-driven workflow.

That would be useful, yes, but that's unrelated to a package being
native or not.

What I'm saying is, Debian source packages *must* be useful on their own
aswell, for those corner cases where the VCS is not an appropriate place
to turn to. (Provided there's a VCS at all, but that's another
discussion again)

-- 
|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/871ud45obi.fsf@algernon.balabit

Re: No native packages?

[Gergely Nagy]

Wouter Verhelst  writes:

> On Mon, Jan 28, 2013 at 09:44:18AM +0100, Gergely Nagy wrote:
>> Wouter Verhelst  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 amou

Re: No native packages?

[Gergely Nagy]

Roland Mas  writes:

> Gergely Nagy, 2013-01-28 09:44:18 +0100 :
>
> [...]
>
>> By harmful side effects, I mean two things:
> [...]
>>  - Patches not separated
>
>   Not quite true.  You can still have debian/patches/* and apply them at
> build-time (dpatch or quilt), even if they're not shipped in a separate
> .diff.gz file.

How many native packages do that? And how is that less inconvenient than
simply having a non-native package?

-- 
|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/87mwvs47oj.fsf@algernon.balabit

Re: No native packages?

[Benjamin Drung]

Am Montag, den 28.01.2013, 22:53 -0600 schrieb Peter Samuelson:
> [Benjamin Drung]
> > Image the opposite. You want to package a software that is only
> > available in a downstream distribution (e.g. Ubuntu or Linux
> > Mint). Do you prefer to have a non-native format or a native format?
> 
> If their native format is an archive in gzipped tar file format, like
> ours is, I'm not sure I would care, if I even _notice_, that there is
> packaging metadata for some other operating system in there.  In fact
> it's not at all uncommon for upstream projects to ship .spec files,
> .vcproj files, and other platform-specific build infrastructure.
> 
> Maybe you're thinking of the inconvenience of the top-level 'debian'
> directory, which is rather inflexible in that all Debian distributions
> and derivatives use the same path for their own use, but that ceased to
> be a problem several dpkg releases ago.

Versioning is a problem for native packages. Which version will you give
your upload to Debian? Using the same version number (with no Debian
revision) will lead to the same version for your Debian package and the
downstream distribution package, but despite the same version, the
content of the tarball will be different (at least regarding the debian/
directory).

-- 
Benjamin Drung
Debian & Ubuntu Developer


-- 
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/1359484276.5427.6.camel@deep-thought

Re: No native packages?

[Russ Allbery]

Tollef Fog Heen  writes:

> I wasn't trying to imply that my idea was new. :-)

Sorry.  :)  I wasn't clear enough that I figured you probably knew the
history.

> Yes, this is a lot of work, and I'm not sure what the best way to go
> about it would be.  On the other hand, I think we're not actually
> shipping the real source if we're not shipping that metadata.  The most
> useful definition of source I've seen is the «preferred format for
> modification» one, and if we need or prefer something outside the source
> package to do useful things with it (such as looking at what patches are
> applied, who wrote them and when), the source package is not the real
> source.

Yes, definitely agreed.  I would really like the model in which we just
ship around Git repositories as our source.

-- 
Russ Allbery (r...@debian.org)   


--
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/87ehh3u8k6@windlord.stanford.edu

Re: No native packages?

[Guillem Jover]

On Sun, 2013-01-27 at 19:16:44 +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 don't really see the problem here, if you are going to patch the
package you might as well do the one line change from "3.0 (native)"
to "3.0 (quilt)", and rename the source tarball to add «.orig».

One of the issues with native packages before format 3.0, was that it
required the downstream to choose a patching system, add the patching
machinery to debian/rules and debian/control, etc, but this is now a
trivial change. It could also be pretty inconvinient if the packaging
had to diverge substantially as the debian/ directory would get in the
way, this is also not an issue anymore with format 3.0.

I was a very strong proponent of avoiding native packages for
non-Debian-and-derivatives specific software, because it used to be a
real burden for downstreams, but not so any longer. Now I just think
that while it might be convenient, it's just bad style (and I'm guilty
of this myself, as I've not yet converted libpmount to non-native, for
example).


For Debian-specific software, the point of native packages is that
at least the Debian (or any other derivative) archive and BTS are
the upstream releases and bugs site for that software, so turning
those into non-native, to me would mean having to look for external
project hosting sites for them.

> It's not only about derivatives, but also in-Debian forking, i.e.
> NMUs. NMUing native packages is quite awkward.

TBH, I've always found that to be a feature of the Debian procedures.

Thanks,
Guillem


-- 
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/20130129193152.ga11...@gaara.hadrons.org

Re: No native packages?

[Russ Allbery]

Guillem Jover  writes:

> I don't really see the problem here, if you are going to patch the
> package you might as well do the one line change from "3.0 (native)" to
> "3.0 (quilt)", and rename the source tarball to add «.orig».

> One of the issues with native packages before format 3.0, was that it
> required the downstream to choose a patching system, add the patching
> machinery to debian/rules and debian/control, etc, but this is now a
> trivial change. It could also be pretty inconvinient if the packaging
> had to diverge substantially as the debian/ directory would get in the
> way, this is also not an issue anymore with format 3.0.

> I was a very strong proponent of avoiding native packages for
> non-Debian-and-derivatives specific software, because it used to be a
> real burden for downstreams, but not so any longer. Now I just think
> that while it might be convenient, it's just bad style (and I'm guilty
> of this myself, as I've not yet converted libpmount to non-native, for
> example).

+1.

If you're using a Git-based workflow, or anything equivalent, you can
easily merge in changes to the upstream's debian packaging files and do
all the other things you might want to do in pretty much exactly the same
way whether the package is native or non-native, including dropping
patches into debian/patches.  It just doesn't matter very much any more.

It's mildly harder if you're working outside of any VCS, but not really
that much.  Mostly it's a touch harder to merge subsequent upstream
changes to the debian packaging files if you're not using a VCS.

I'm still religious about using non-native packaging for my own packages
that have any conceivable use outside of Debian or derivatives, since I
find it aesthetically ugly, and therefore psychically painful, to make new
releases for the rest of the world that contain only Debian packaging
changes and therefore want the versioning space to make Debian-only
changes without making a new non-Debian release.  But I don't see any
point for packages that exist solely within the Debian world
(kerberos-configs, for instance).

-- 
Russ Allbery (r...@debian.org)   


--
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/8738xju6br@windlord.stanford.edu

Re: No native packages?

[Joey Hess]

Julien Cristau wrote:
> > Maybe I forgot the answer, but at least in terms of git and the dpkg
> > 3.0 (git) format, why can't we simply make use of shallow cloning?
> 
> At which point you have lost all the advantages of shipping the
> repository that Tollef mentioned, as far as I can tell.  You're back to
> needing an external repository that's kept up to date if you ever need
> to get at the history.

You can shallow clone at depth one each ref in the repository, which gets you
all tags (filter to released versions to avoid needing any further license
review).

joey@gnu:~/src>git clone --depth 1 --bare --no-single-branch 
file://`pwd`/debhelper debhelper.shallow
Cloning into bare repository 'debhelper.shallow'...
remote: Counting objects: 7372, done.
remote: Compressing objects: 100% (4336/4336), done.
remote: Total 7372 (delta 3760), reused 5854 (delta 2629)
Receiving objects: 100% (7372/7372), 2.70 MiB | 1007 KiB/s, done.
Resolving deltas: 100% (3760/3760), done.
joey@gnu:~/src/debhelper.shallow>git log --oneline 9.20120909
d27f027 releasing version 9.20120909
893119b Update French translation

git-clone needs to be fixed to allow specifiying --depth 0, which currently
includes the full history, rather than only the head of each branch.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: No native packages?

[Thomas Goirand]

On 01/28/2013 07:30 PM, Philip Hands wrote:
> 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
Hi Phil,

Thanks for sharing your view (and the one of Joe).

I also maintain at least one native package: debpear, which is a helper
to build some PHP PEAR packages. So I do think it makes sense in some
cases. I would really like to hear others thoughts about this choice.
Is there counter arguments for this kind of package? Oh, and I allmost
forgot as well: openstack-pkg-tools is native too (but it's not in
testing, just in experimental until Wheezy is out).

I don't think it would need any change in derivatives, IMO, especially
because they don't need an upstart job to replace an init script which
doesn't exist in these packages. However, I don't really feel 100%
confident about these choices, and would happily read external opinions.

Thomas


-- 
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/5108c524.9030...@debian.org

Re: No native packages?

[Ian Campbell]

On Wed, 2013-01-30 at 17:58 +1100, Joey Hess wrote:
> Julien Cristau wrote:
> > > Maybe I forgot the answer, but at least in terms of git and the dpkg
> > > 3.0 (git) format, why can't we simply make use of shallow cloning?
> > 
> > At which point you have lost all the advantages of shipping the
> > repository that Tollef mentioned, as far as I can tell.  You're back to
> > needing an external repository that's kept up to date if you ever need
> > to get at the history.
> 
> You can shallow clone at depth one each ref in the repository, which gets you
> all tags (filter to released versions to avoid needing any further license
> review).

Is it also possible to say "everything in branch A which isn't in branch
B", so that you could include everything from the "debian" branch but
not the "upstream" branch? That might be useful when you aren't 100%
certain of the DFSG freeness of the upstream history, whereas you might
well be happy that the versions incorporated into the debian branch were
ok.

Also, I wonder if it is possible to arrange that having unpacked a git
format source package that the remotes for debian and upstream are
already prepopulated in the repo such that "git remotes update" would
fetch all of the missing history without having to "git remotes add
etc".

Ian.

-- 
Ian Campbell


In Newark the laundromats are open 24 hours a day!


-- 
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/1359535095.10403.14.ca...@dagon.hellion.org.uk

Re: No native packages?

[Thomas Goirand]

On 01/29/2013 08:29 AM, Russ Allbery wrote:
> Benjamin Drung  writes:
>
>> Other distributions gain from your extra work. Image the opposite. You
>> want to package a software that is only available in a downstream
>> distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a
>> non-native format or a native format?
> I'm not sure I see how it makes any difference.  Either way, I would start
> with their package and add Debian packaging files for Debian.  The only
> difference is some minor variation in what commands I run at the very
> start of that process (namely, git-import-dsc for a non-native package
> vs. git-import-orig for a native package).  I have a hard time seeing how
> this choice would make more than thirty seconds of difference to my
> workflow.
>
Well, this happened to me once (a package in Ubuntu), and I asked
upstream to switch to non-native, which he did.

The problem wasn't the work flow, but mainly tracking upstream
version numbers. With a non-native, I can make the difference
between packaging and non-packaging changes just by looking
at the version number in Ubuntu, and I can even make a watch
file to track it for me.

Thomas


-- 
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/5108e928.10...@debian.org

Re: No native packages?

[Thomas Goirand]

On 01/28/2013 08:59 PM, Gergely Nagy wrote:
> In my opinion, a native package is the wrong choice when your only
>   arguments for it is convenience.
>
>   That's not a strong argument
To the contrary, I think that convenience of one or another
format is the *only* argument.

What you've listed as counter-argument are cases were it isn't
convenient, IMO. And that's why we design packaging tools and
format: so that they are convenient to use. I don't think you
should feel bad because of that kind of laziness. I see it as
an optimization of your work flaw rather than laziness (that's
just different wording for the exact same idea in a more
positive way).

Also, I'm sorry but I don't buy your argument that newbies
would see bad native-package examples and reproduce it. Anyone
who looked a bit into -mentors@l.d.o (and I know you do) will
be able to tell that they do use native packages anyway by
simple mistake and lack of knowledge. Repeatedly, we have to
explain anyway.

Also, I don't understand why you think an NMU becomes awkward
if it deals with a native package. Could you explain?

On 01/28/2013 08:59 PM, Gergely Nagy wrote:
> 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.

I fail to understand why this would be a problem for the 2 native
package I maintain (eg: debpear and openstack-pkg-tools). The
new maintainer would just take over the work (as usual?)...

Thomas


-- 
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/5108e999.8030...@debian.org

Re: No native packages?

[Thomas Goirand]

On 01/30/2013 04:38 PM, Ian Campbell wrote:
> Also, I wonder if it is possible to arrange that having unpacked a git
> format source package that the remotes for debian and upstream are
> already prepopulated in the repo such that "git remotes update" would
> fetch all of the missing history without having to "git remotes add
> etc".
Yeah, I would love to have this as well. Currently, I do:
./debian/rules get-vcs-source

which adds upstream repository, does a "git fetch upstream" and create
the orig.tar.xz for me.

It's not as nice as what you describe (which I would like to have too),
but it is a nice workaround.

Thomas


-- 
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/51090cc6.5010...@debian.org

Re: No native packages?

[Jakub Wilk]

* Guillem Jover , 2013-01-29, 20:31:
if you are going to patch the package you might as well do the one line 
change from "3.0 (native)" to "3.0 (quilt)", and rename the source 
tarball to add «.orig».


That's a good solution for derivatives, not so much for NMUs or 
backports.


--
Jakub Wilk


--
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/20130201212518.ga8...@jwilk.net

Re: No native packages?

[Guillem Jover]

On Fri, 2013-02-01 at 22:25:18 +0100, Jakub Wilk wrote:
> * Guillem Jover , 2013-01-29, 20:31:
> > if you are going to patch the package you might as well do the one
> > line change from "3.0 (native)" to "3.0 (quilt)", and rename the
> > source tarball to add «.orig».
> 
> That's a good solution for derivatives, not so much for NMUs or
> backports.

As I mentioned on my previous mail, I consider that a nice feature.
To me NMUing or backporting a native package is the equivalent of an
external and uninvolved person to send a mail to, say, the postgresql
developers, telling them that you've released a new version of the
upstream project for them... on the upstream server.

Taking into account that the distribution archive and BTS are the
hosting site for the native package, an NMU is a versionspace and
file release takeover, and stomps over previously released versions
and supercedes them, which might be confusing for downstreams (like
non-derivatives), as the NMU might end up being rejected, or
reimplemented in a different and incompatible way, etc.

Thanks,
Guillem


-- 
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/20130202125646.ga4...@gaara.hadrons.org

Re: No native packages?

[Jakub Wilk]

* Guillem Jover , 2013-02-02, 13:56:
if you are going to patch the package you might as well do the one 
line change from "3.0 (native)" to "3.0 (quilt)", and rename the 
source tarball to add «.orig».
That's a good solution for derivatives, not so much for NMUs or 
backports.


As I mentioned on my previous mail, I consider that a nice feature. To 
me NMUing or backporting a native package is the equivalent of an 
external and uninvolved person to send a mail to, say, the postgresql 
developers, telling them that you've released a new version of the 
upstream project for them... on the upstream server.


Taking into account that the distribution archive and BTS are the 
hosting site for the native package, an NMU is a versionspace and file 
release takeover, and stomps over previously released versions and 
supercedes them, which might be confusing for downstreams (like 
non-derivatives), as the NMU might end up being rejected, or 
reimplemented in a different and incompatible way, etc.


So what do you propose instead? It's not like native packages get NMUed 
because of great entertainment value of the NMU process, but because 
there's no better choice.


(Random data point: I have 14 packages with versions indicating they are 
NMUed native packages installed on my system. Some of them have priority 
standard or higher.)


--
Jakub Wilk


--
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/20130204174322.ga8...@jwilk.net

Re: No native packages?

[Guillem Jover]

On Mon, 2013-02-04 at 18:43:22 +0100, Jakub Wilk wrote:
> So what do you propose instead? It's not like native packages get
> NMUed because of great entertainment value of the NMU process, but
> because there's no better choice.

The same thing we usually do when confronted with a dead upstream
project.

And in case the maintainer is active elsewhere in the project, has
not replied to RC bugs nor possible intentions to NMU, and it's
something that really needs fixing, then I think the current native
NMU procedure (the upstream+nmuN stuff) is bogus and needs to be fixed,
instead the package should be converted to a non-native one and a
traditional NMU version used (something like upstream-0.N), as used
to be the case before, so that the original tarball is preserved, and
the changes distinguished from the upstream releases to make it clear
what's what.

> (Random data point: I have 14 packages with versions indicating they
> are NMUed native packages installed on my system. Some of them have
> priority standard or higher.)

I've a similar number on my system, but most of these appear to be
from people that have not been active in the project for a while?

Thanks,
Guillem


--
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/20130213024153.gb22...@gaara.hadrons.org

Re: No native packages?

[Stefano Zacchiroli]

On Wed, Feb 13, 2013 at 03:41:53AM +0100, Guillem Jover wrote:
> > (Random data point: I have 14 packages with versions indicating they
> > are NMUed native packages installed on my system. Some of them have
> > priority standard or higher.)
> 
> I've a similar number on my system, but most of these appear to be
> from people that have not been active in the project for a while?

Precisely, hence the usefulness of NMUs.  In the interim when you don't
know if those people have "disappeared" from the project (for all sort
of valid reasons) or not, other developers can help using NMUs. That way
they help both the maintainers in question, relieving some of their
duties if they are gone only temporarily, and the project as a whole
that avoids being technically stalled for a while.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: No native packages?

[Guillem Jover]

On Sat, 2013-02-16 at 12:11:29 +0100, Stefano Zacchiroli wrote:
> On Wed, Feb 13, 2013 at 03:41:53AM +0100, Guillem Jover wrote:
> > > (Random data point: I have 14 packages with versions indicating they
> > > are NMUed native packages installed on my system. Some of them have
> > > priority standard or higher.)
> > 
> > I've a similar number on my system, but most of these appear to be
> > from people that have not been active in the project for a while?
> 
> Precisely, hence the usefulness of NMUs.  In the interim when you don't
> know if those people have "disappeared" from the project (for all sort
> of valid reasons) or not, other developers can help using NMUs. That way
> they help both the maintainers in question, relieving some of their
> duties if they are gone only temporarily, and the project as a whole
> that avoids being technically stalled for a while.

I was not attacking the NMU faith or its usefulness, otherwise we'd
obviously not have NMUs; what I was getting at in this thread, that
got trimmed in the quoted mail, is the thought that the current NMU
procedure for native packages is bogus, as argumented previously.

Even then, we do not consider long term maintenance of orphaned
packages through QA uploads a good thing, so even more reason for this
not to be done for dead native packages, which lots of maintainers
might rely on. But, let me repeat, if this needs to be done anyway,
then those changes should be clearly distinguished as not coming from
the native package developer(s), by not taking over the upstream file
releases and versionspace.

When you don't know if the native package developer(s) have disappeared,
well, you ask, and might want to consider doing the same we do with
dead non-native upstream projects, also mentioned previously, which
might include being offered to be added as co-upstream, an agreed
handover, a fork if the developer(s) do not want to step aside, a
transition of reverse dependencies to another package, or a possible
upstream adoption (after some safe timespan) if the developer(s) have
completely disappeared from the face of the earth. This did not appear
to have been done with those currently NMUed native packages, hence my
rethorical question.

Guillem


-- 
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/20130218190507.gb3...@gaara.hadrons.org

Re: No native packages?

[Stefano Zacchiroli]

On Mon, Feb 18, 2013 at 08:05:07PM +0100, Guillem Jover wrote:
> I was not attacking the NMU faith or its usefulness, otherwise we'd
> obviously not have NMUs; what I was getting at in this thread, that
> got trimmed in the quoted mail, is the thought that the current NMU
> procedure for native packages is bogus, as argumented previously.

Oh, but I didn't mean to object to the fact that a specific procedure
(the one used to NMU native packages) could be improved. I didn't quote
that part simply because I didn't have anything to add/comment on that.

Sorry for the misunderstanding,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: No native packages?

[Ian Jackson]

Gergely Nagy writes ("Re: No native packages?"):
> There are two native packages I maintain, and I've yet to hear a good
> reason for making either of them non-native. Making it harder and much
> much more inconvenient for downstream distributions to modify them is a
> *goal* in these cases: to make it harder to diverge from one
> another.

I haven't looked up to see what these packages are, but I worry that
what you are doing here is undermining the freedom of our downstreams.

The ability of our users and downstreams to choose to modify the
software we distribute is the core of their software freedom.  As a
project we should be making it easier, not harder, to produce modified
derivatives.

Thanks,
Ian.


-- 
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/20771.42201.4516.770...@chiark.greenend.org.uk

Re: No native packages?

[Ian Jackson]

In article <8738xju6br@windlord.stanford.edu>,
Russ Allbery   wrote:
>I'm still religious about using non-native packaging for my own packages
>that have any conceivable use outside of Debian or derivatives, since I
>find it aesthetically ugly, and therefore psychically painful, to make new
>releases for the rest of the world that contain only Debian packaging
>changes and therefore want the versioning space to make Debian-only
>changes without making a new non-Debian release.

It's perfectly possible to release version 4.2.3 followed by 4.2.3-1
when you want to make the Debian-specific packaging change and then go
back to the native 4.2.4 when you make the next not-just-Debian change.

Ian.


-- 
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/20771.42672.416170.625...@chiark.greenend.org.uk

Re: No native packages?

[Gergely Nagy]

Ian Jackson  writes:

> Gergely Nagy writes ("Re: No native packages?"):
>> There are two native packages I maintain, and I've yet to hear a good
>> reason for making either of them non-native. Making it harder and much
>> much more inconvenient for downstream distributions to modify them is a
>> *goal* in these cases: to make it harder to diverge from one
>> another.
>
> I haven't looked up to see what these packages are, but I worry that
> what you are doing here is undermining the freedom of our downstreams.

The two packages in question are dpatch and dh-exec, and yes, what I do
with them could be considered as undermining the freedom of
downstreams. However, in this two cases, I believe that is a good thing,
as in the long run, neither we nor downstream should want to deviate
from one an other.

Why? Because if downstream introduces something there, and start to rely
on it, while upstream the same thing does not get introduced, or does in
a different way, everything that builds on either, will fall apart, and
make it that much harder to work together.

> The ability of our users and downstreams to choose to modify the
> software we distribute is the core of their software freedom.  As a
> project we should be making it easier, not harder, to produce modified
> derivatives.

I agree, but to a limit. But there are tools that should be patched as
little as possible, to preserve interoperability between distributions,
and both dpatch and dh-exec are such tools that when they diverge in
either down- or upstream, interoperability suffers. Want something
included? Get it in upstream first, so things won't break.

That is one of the reasons I kept both as native, and why I believe
there is no compelling reason to change that.

-- 
|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/87y5ek1brv.fsf@algernon.balabit

Re: No native packages?

[Tollef Fog Heen]

]] Ian Jackson 

> I haven't looked up to see what these packages are, but I worry that
> what you are doing here is undermining the freedom of our downstreams.

They're free to do whatever they want.

> The ability of our users and downstreams to choose to modify the
> software we distribute is the core of their software freedom.  As a
> project we should be making it easier, not harder, to produce modified
> derivatives.

I'm part of an effort to make an OS, and while I'm happy the bits I
create are useful in creating other OS-es, that's not the primary goal
and not what I'm optimising for, so I disagree with what you're saying
above.

(Everything else being equal, I'll choose a solution that makes my
downstream's lives easier, of course.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87liakarkk@xoog.err.no