On Wed, 2009-08-26 at 20:49 +0200, George Danchev wrote: > Nice argumentation, but not bullet proof ;-)
Was never really an argument. Remember that I did use separate patching
in the previous version (if you read my response in the other thread I
made it quite clear that I'm not closing the door on separate patching.)
> Actually your repo is a very weak reference to what actually Debian currently
> releases -- source and binary packages, eventually burned on optical media
> people use here and there. Let's, imagine a secret lab, giant budgets, and
> perhaps a team of government scientists working within a non-internetworked
> area (surprise, heh;-) using Debian source and binary CD/DVD's. Now, do you
> see the disconnect? Providing more use cases like that, even in the days of
> Web 2.0, is a trivial task, just try harder ;-)
Wait, a giant budget excluding a non-internetworked environment? Then
again, with the government where I come from, its not too far off to
imagine that. :P
That aside, I note that it doesn't really matter if those guys above
have no access to the package VCS repo: they have the source packages
anyway, which already contains the diffs. They can dpkg-source -x it,
they can dpkg-buildpackage it, and they can read debian/changelog.
What really goes on here is that there's a stronger preference towards
having patches in debian/patches/ m as it is a particular convenience
for maintainers, as opposed to navigating the source tree for diffs. I
don't object to this at all, as long as it doesn't break my maintaining
the package.
> Hopefully that could be fixed by actually distributing package's VCS repo,
> that
> we can call boldly `self-contained', which would effectively be addressed by
> the new debian source formats like 3.0 (git) and friends. However they are
> not
> ready yet AFAICT, so until then topgit might be your best bet, if you want to
> re-connect all the users of your source package(s) Debian proudly distributes.
Thanks, all in all, that was a better take on why separate patching
should be done. I'll take a look at topgit (and quilt, too) and will
probably rebuild the package.
--
Zak B. Elep -- 1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D
I like the idea of 256 bits, though: 32 for the (Unicode) character
leaves room for 224 Bucky bits, which ought to be enough for anyone.
-- Roland Hutchinson, in alt.folklore.computers
signature.asc
Description: This is a digitally signed message part
