Quoting "Zak B. Elep" <zak...@zakame.net>:
Hi,
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.)
Sorry, I was/am not familiar with your previous package versions.
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
It simply boils down to the (strange) security policies they are
using, tightly controlled environments and physically separated
networks they are in. You don't connect sensitive systems and networks
to the public networks like internet is ;-)
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.
But those diffs are applied in a combined fashion to the upstream
source (not very helpful for people actually interested to understand
the code), while they might be extremely interested to understand how
many *logical* changes have been applied, what are the reasons behind
such a deviation from the upstream, hence they would need to find out
and dig into your own VCS repo which is not so tightly associated with
the bits Debian actually and officially releases. What if your own
server goes down, repo changed or disappeared. Compare that to a
Debian release which never disappears.
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.
for maintainers and *any sort of users* of your source/binary package.
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.
Good.
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
