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?
Yes, he does.
> > It'd be rediculous for a Debian GNU/HURD system to need
> > "kernel-headers-2.2.10" to be installed for glibc's build depends to
> > be satisfied, and equally rediculous for a Debian GNU/Linux system to
> > need "hurd-dev" and "gnumach-dev" and "mig"(?).
>
> These packages share the common function of containing headers (?) for
> the kernel, be it Linux or the Hurd. Why is it then so appalling to
> have both package sets provide a suitable virtual package?
>
> (I will be easily converted to your ways if you just convince me of this
> point ;-)
1. Those packages do NOT provide the same functionality. The gnumach-dev
and hurd-dev headers are quite different from the linux kernel headers.
Thus, they don't fit under the same virtual package. Although you will
notice that both connect the C library to the underlying kernel and
multi servers, they are not interchangeable.
It could well be that the Hurd header files will be made available under
Linux some day, when people are interested porting some of its interfaces to
Linux for applications. Then the virtual package provided will give
completely the wrong idea about the package.
2. The mig package provides an *executable* that does not have any meaning
under current Linux systems (except MkLinux probably). I can't see how
you would fit mig into this virtual package scheme at all.
To conclude, although I see a slight possibility why one could think of a
virtual package kernel-header that is provided by both gnumach-dev and
linux-kernel-headers, I don't see how this would solve the hurd-dev and mig
dependency of libc on the Hurd, and I don't really see why libc would
benefit from such a virtual package, as it would be necessarily meaningless
(as no two kernels provide exactly the same interface).
Furthermore, I wish you would not pin point this on the glibc package. I
already told you that further packages will require this feature. Are you
actually involved in any of our porting efforts? If not, it would be a
healthy experience ;), or at least check one of the mailing lists
frequently, to learn what is involved.
Don't forget that Debian is not Linux anymore, just as it is not i386
anymore for a long time now. Here is another example: To build the Linux
kernel on a i386, you need the bin86 package, on other platforms you don't.
This may actually be solved by virtual packages, but it is a lot easier just
to specify the correct architecture dependent source dependency.
A further point: Of course, you can solve ALL architecture related dependencies
problems by creating virtual dummy package. So, "dummy-0", "dummy-1" etc.
Do you think this is an adequate solution to this problem?
A very last point: Virtual packages require changes to multiple packages,
while source dependencies are local to a single package. So, everything that
helps keeping all relevant data inside the single package is very helpful in
the development process.
Are you converted now? :)
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: