On 20/02/15 14:25, Harald Dunkel wrote:
> IMHO there should be a policy for the special case, that
> there is a naming conflict between upstream's source or
> binary packages, and the packages included in Debian.
Whatever we might say on the subject in Debian policy, upstream-produced
packages are not going to follow it, unless the upstream developer wants
to do so for their own reasons. An analogy: if the French government
declares that beer must be sold in 500ml units, we can't expect Britain
to pay much attention :-)
Also, as the Policy maintainers occasionally remind us, Policy does not
document what people want, it documents existing best-practice - which I
think is partly in an effort to avoid divergence from reality, and
partly to avoid Policy being a stick to hit people with.
If you get all your packages from one integrated operating system, they
are meant to work together; if you get your packages from multiple
overlapping sources, of course there's potential for disagreement and
conflict between those sources. That's the price you pay for the benefit
you are (presumably) deriving from those other sources.
> I think its obvious that a naming conflict should be avoided.
> Having 2 source or binary packages with identical names in
> 2 independent repositories is just asking or troubles.
Ubuntu have historically shipped a fairly extensively patched dbus
(first for Upstart integration, and now for AppArmor integration,
although they have dropped the former patch set, and I finally merged
the latter upstream yesterday). It seems likely that there have been
times when it was not fully compatible with the one I maintain in
Debian. Are you saying that they should have renamed theirs to
ubuntu-dbus, or that I should have renamed our package in Debian to
debian-dbus or the-real-dbus or upstream-dbus? Neither seems likely to
be an approach that scales well.
Similarly, Wine has rather different .deb packaging styles upstream
(small number of monolithic binary packages, weak dependencies on
supporting libraries, not all features will work at runtime if you don't
have the right supporting libraries) and in Debian (larger number of
binary packages, strong dependencies on supporting libraries, everything
you have installed will have its dependencies satisfied, but you might
not have the complete Wine suite). I don't think the Wine maintainers in
Debian are going to rename their version to debian-wine just because
software outside Debian is not necessarily compatible with it; neither
do I think the upstream packagers are going to rename theirs to
upstream-wine or anything like that.
If the packages produced by the upstream developer you're talking about
are intended for use with Debian (or Ubuntu as the case may be), but do
not interoperate nicely with Debian (or Ubuntu), then that seems like a
bug: "package does not work well in its intended environment". If you
can help them to fix that bug - particularly if it's as easy as adding
an epoch compatible with the one in Debian - or alter their debian/
directory to be based on the one from Debian proper, problem solved.
If the Debian packages are not as good as the upstream ones, such that
you end up having to use the upstream ones for some reason, then that
also seems like a bug. If you can help the Debian maintainer to fix that
bug (e.g. by getting newer upstream versions into experimental, or by
fixing deficiencies of the packaging that are done better upstream, or
whatever), problem also solved.
It seems to me that fixing *either* of those bugs is sufficient to make
this problem go away (although of course the ideal would be to be able
to fix both).
S
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e77497.7030...@debian.org
