Re: sysvinit and hurd
On 2004.06.09 12:02, Santiago Vila wrote:
> On Wed, 9 Jun 2004, Alfred M. Szmidt wrote:
>
> > Currently libc0.1 is the official glibc version for the hurd in the
> > main archive.
> >
> > I suggest that you do your research a bit better; or maybe the Debian
> > GNU/*BSD people should make it clearer, the naming of the package
> > isn't exactly wonderful. libc0.1 is a Debian GNU/*BSD package, it
> > isn't even available on Debian GNU/Hurd. Debian GNU/Hurd uses libc0.3
> > since ~2000, before it used libc0.2, and before _that_ Debian GNU/Hurd
> > didn't exist.
>
> Well, he may be a little but confused, but not completely confused.
> (In his message, he mentions libc0.3 and libc0.1, not just libc0.1).
>
>
> IMHO, I think it is highly desirable that all packages in ftp.debian.org
> depend on packages in ftp.debian.org. There is at least one important
> package in ftp.debian.org which depends on the libc0.3 in ftp.gnuab.org,
> which is newer. I think that should *not* happen. It would be like a
> package in unstable depending on a development library in experimental.
>
> Miquel, could you please briefly explain what kind of features in the
> new libc do you need, and what kind of breakage would happen when
> using the old libc?
Older versions of glibc included the /etc/init.d/mountkernfs and
/etc/init.d/devpts.sh scripts. The latest initscripts package includes
a /etc/init.d/mountvirtfs script that takes over that functionality.
glibc >= 2.3.2-12 doesn't include those scripts anymore.
This was a coordinated move by me and the glibc maintainers. Newer
sysvinits need to depend on a glibc >= 2.3.2-12.
So it's not about features of glibc, but about packaging.
> Isn't it a little bit strange that the usual shlibdeps mechanism is
> not used here and you have to hardcode the dependencies?
Not in this case.
> Can you check for the required features using some sort of configure
> script and refuse to build if the libc is not good enough?
Yes, using build-depends. But that is very hard because the glibc package
is named differently on several architectures :(
> It is not elegant to hardcode dependencies on libc at all. To do it
> right, the source package should not need to be changed if the Hurd
> moves from libc0.3 to libc0.4, for example.
This case is different - it's about packaging.
Can somebody enlighten me and tell me what the current ftp.debian.org
as well as "experimental" package names are for glibc on both Hurd and
kFreeBSD, what version they are and what direction development is taken ?
I'm trying to work with you here, but as both Hurd and kFreeBSD aren't
a release gool for sarge, if I can't figure it out I'll just have to
ignore those arches. Which I'd rather not to if possible.
Mike.
Reply to: