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 [EMAIL PROTECTED] for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
