Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
On Sat, Aug 07, 1999 at 12:57:21PM +0300, Antti-Juhani Kaijanaho wrote:
> On Fri, Aug 06, 1999 at 05:00:27PM -0700, Joel Klecker wrote:
> > Well, I *need* that to represent glibc's source depends correctly.
>
> Do you?
I know that I already responded, but this is important enough for me to pull
all strings to kill the idea of using virtual packages for source
dependencies to make sure you don't get any funny ideas about it.
I'll bite and use the glibc package as a concrete example. But remember that
there will be much "worse" packages, too.
This is the situation:
=================================================
Linux:
glibc needs kernel-headers of a specific version.
GNU:
glibc needs gnumach-dev, hurd-dev, mig.
=================================================
Now you suggested that we use a virtual package "system-headers" which glibc
depends on.
==============================================
Package: glibc
Source-Depends: system-headers
Linux:
Package: kernel-headers
Provides: system-headers
GNU:
Package: hurd-dev
Provides: ?
Package: gnumach-dev
Provides: ?
Package: mig
Provides: ?
===============================================
Things start to get ugly. How do you fill in the blanks below to make sure
that all three packages are installed? Note that all three packages
hurd-dev, gnumach-dev and mig don't have any dependencies on each other, and
you shouldn't rely on indirect dependencies anyway.
Note that if either of these Provides: system-headers, glibc's
source-dependencies would be satisfied if only this package is installed, so
we need either need a dummy package or three virtual packages:
"Solution A":
==============================================================
Package: glibc
Source-Depends: system-headers
Linux: (as above)
GNU:
Package: hurd-dev
Provides: system-headers-1
Package: gnumach-dev
Provides: system-headers-2
Package: mig
Provides: system-build-utility # (what the HACK is THAT?)
Package: system-headers (an empty package)
Depends: system-headers-1, system-headers-2, system-build-utility
===============================================================
"Solution B":
=======================================================================
Package: glibc
Source-Depends: system-headers-1, system-headers-2, system-build-utility
Linux:
Package: kernel-headers
Provides: system-headers-1, system-headers-2, system-build-utility
# ^^^ HUH???
GNU: (as Solution A, but without the empty system-headers package).
======================================================================
(You see, there are no names for the virtual packages that would make sense
on BOTH architectures. Now imagine different source dependencies on three or
four architectures!)
Neither "solution" is acceptable. Changing the dependencies would involve
action of several maintainers as well as the ftp archive maintainers (for
creation and deletion of dummy packages). Furthermore, the concept of
virtual packages is abused for a completely different matter, and does not
provide an intuitive understanding of the dependencies.
I don't object to use virtual packages where they are actually useful (for
example, source-depends on "awk" if any awk is sufficient (mawk, gawk,...).
But I think it is ridiculous to think that this will solve all problems.
It is obvious that avoiding architecture specification in the source
dependencies will simplify the proposal marginally at the very high costs for
the maintainers. But the idea of the source dependencies is to make life for
maintainers easier, not harder.
If I have still not convinced everybody of the urgent need for arhcitecture
specific build dependencies, I need to know which other solution could
address the points raisen in this and prior mail.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@
Marcus Brinkmann GNU http://www.gnu.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: