Bug#400112: [PROPOSAL] forbid source/binary package name conflicts
On Wed, Oct 03, 2007 at 04:49:28PM +0100, Ian Jackson wrote:
> Manoj Srivastava writes ("Bug#400112: [PROPOSAL] forbid source/binary package name conflicts"):
> > On Thu, 23 Nov 2006 22:45:18 +0100, Lucas Nussbaum
> > <lucas@lucas-nussbaum.net> said:
> > > Some source packages generate binary packages using the same name as
> > > another source package. For example, see the 'qd' source package,
> > > and the 'qd' binary package generated by the kfolding source package
> > > (in contrib).
> > >
> > > Some tools don't like it at all (e.g sbuild), [...]
>
> Another example is the bug system. When you submit a bug you (used
> to) write:
> Package: <source or binary package name>
> Version: <version of that source or binary package>
>
> The BTS now provides `Source:' instead of `Package:' but it has not
> been widely publicised AFAIR, no-one uses it (not even automated
> rebuild testers and the like),
... and dak when closing bugs. That was one of the main points of adding
it, actually; it was done during the upheaval for version tracking.
(Conceptually, ordinary users file bugs on binary packages, while buildd
maintainers, developers spotting a problem while reading source code,
etc. file bugs on source packages. Neither obsoletes the other.)
> To make the existing interface to bugs.debian.org unambiguous the
> following rule is needed:
>
> If there are a source package and a binary package with the same
> name then
> (a) that binary package must be generated from the
> identically-named source
> and
> (b) the generated binary package version number must be the
> same as the generating source package version number
I agree that the semantics of bugs.debian.org get tremendously difficult
when these rules are violated. This caused me huge headaches when
implementing version tracking, and I'm quite convinced that there are
still internal bugs in this area, not to mention practically intractable
UI bugs. As a (not very active these days) debbugs developer I support
Ian's proposal.
I am a little concerned that there may still be binary packages from
different source packages on particular architectures at the moment
(e.g. it used to be the case at least in Ubuntu that openoffice.org
wasn't 64-bit-safe, so there was a separate openoffice.org-amd64 source
package which generated the same binary packages built against 32-bit
libraries). In most cases this is a ghastly hack and there are probably
better ways to do it. However, it would be nice to know the extent of
the problem before forbidding it.
gcc-3.3 and gcc-3.4 still appear to have different source and binary
package versions. More recent versions of gcc don't do this. Again, it
would be nice to know the extent of the problem here.
> > Why is this not considered a bug in the tools that needs to be
> > fixed, rather than creating policy to work around bugs in the toolchain?
>
> I think that trying to fix everyone's brains not to get confused in
> this area is impractical.
I concur. As Ian says, the BTS has had a disambiguating mechanism here
(Source and Source-Version) for years, but nearly nobody uses it and
frankly I don't blame them. The situation is rife with ambiguity and it
would be much less confusing for everyone to forbid it.
--
Colin Watson [cjwatson@debian.org]
Reply to: