Re: divergence from upstream as a bug
"Bernhard R. Link" <brlink@debian.org> writes:
> * Joey Hess <joeyh@debian.org> [080517 23:01]:
>> What if we just decide that changes made to upstream sources[1] qualify
>> as a bug? A change might be a bug in upstream, or in the debianisation,
>> or in Debian for requiring the change. But just call it a bug.
>> Everything else follows from that quite naturally..
> Except that it has an important scope problem. Divergences with the
> Debian package are not open bugs in Debian, they are open bugs in
> upstream that are localy fixed within Debian.
I don't think this is as universally true as it looks on first glance.
Often the reason why the divergence remains a divergence is because it's a
quick hack that only works on (for example) Linux systems or glibc systems
and upstream would accept it if it were better-implemented. In that case,
it really is still an open bug against the Debian package (and Policy
concurs).
There are certainly patches in the category that you describe, however.
Many of them are even cherry-picked from upstream's VCS.
> We have already such a place. It's called the .diff.gz. It's linked
> everywhere, on every mirror in the same directory as the software. This
> file is there to contain and show what is changed. Admitted, the
> original one file diff is not perfect for multiple patches, but for this
> adding additional patch files in there works smootly.
>
> This is were people look at and what I from looking for changes of other
> distributions of packages I maintain often miss elsewhere: A complete,
> current list of what is actually changed.
Except from upstream's perspective, it's a mess, and not necessarily worth
their time to bother to read. All the debian directory stuff is mixed in
with Autoconf noise, config.* updates, and actual changes they might care
about. Even if the patches are broken out into separate files in
debian/patches, they now have to download the diff and apply it to
something to get readable patches. And after they go to all that work,
they may discover there's no meaningful divergence at all; there's no
warning in advance of whether that's the case.
> Everything else is just overhead, as with comments in source code: they
> are nice to have as long there little, but if there are too many they
> are most of the time outdated, wrong or distracting.
Hm, you and I may have very, *very* different ideas of what
well-maintained code looks like. :)
> Instead of adding new stuff, why not actually enforce and improve what
> we have:
> I'd suggest to start with making pristine upstream tarballs (or pure
> subsets of those) obligatory. No modifications allowed in there and no
> exceptions.
Isn't this already the case in practice? Do you really see many Debian
packages that have modified *.orig.tar.gz tarballs? And if so, have you
filed bugs?
> And when extending the source packaging format, do not throw away the
> good properties lightly. Git for example is no format to present
> modifications. It is one to present history (which is almost but not
> quite something completely different).
Git is quite good at presenting modifications if you know how to use it.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: