Re: about sysvinit
O Ven, 2002-02-22 ás 15:34, Marcus Brinkmann escribiu:
> On Fri, Feb 22, 2002 at 03:30:51PM +0100, Marcus Brinkmann wrote:
> > > the hurdinit pkg would be the dummy one used now, or maybe an special
> > > init for the system, i don't kow.
>
> You made me thinking. The Hurd has an init system (it's /hurd/init, and it
> starts /libexec/rc at run time, which in turn starts the servers in the
> Debian packages).
>
> Depending on _why_ the packages depend on sysvinit, it might be enough to
> depend on sysvinit only on Debian GNU/Linux systems. In this case, the
> packages have to be changed to add sysvinit to the dependencies by the
> dpkg-substvars mechanism in debian/rules depending on the architecture they
> are built for.
>
> But the reason why they depend on sysvinit might be many, and I don't have
> an overview of what the common reasons are. That I ported sysvinit at all
> was a kludge for Debian GNU/Hurd by itself: The Hurd doesn't really need it.
well, first of all, i'm new to the hurd so probably i'll say a lot of
stupid things O:)
the first time that you want to upgrade the system, dselect complains
because it can't find sysvinit, and if you want to upgrade bsdutils (an
essential package) you can't, because of the missing sysvinit pkg. i
don't know how this problem is addresed in the ISOs, maybe with the
dummy package?
if you're new to debian (not my case) and see the strange things that
dselect/apt says, you can became very confused. anyway, i searched
through this list and i found the solution, i also went to the
bugtracking system to see the bug report.
i just feel that 2+ years is time enough for such a bug, so i may help
to solve it. but i don't know which is the right way :\
let's try.. in the linux-i386-unstabe part there're 9 pkgs which depends
on sysvinit:
________________________________________________________________________
$ grep -B 10 "Depends: .*sysvinit" /var/lib/dpkg/available | grep "Package: \|Depends: \|^--$"
Package: ppp
Depends: libc6 (>= 2.2.4-4), libpam0g (>= 0.72-1), libpcap0 (<< 0.7.0), libpcap0 (>= 0.6.1-1), libpam-modules, netbase, sysvinit (>= 2.75-4), procps, makedev (>= 2.3.1-56)
--
Package: genpower
Depends: sysvinit, libc6 (>= 2.1.2)
--
Package: linuxconf
Depends: netbase (>= 3.16-1), logrotate, sysvinit (>= 2.77-1), libc6 (>= 2.2.4-4), libdb3 (>= 3.2.9-1), libgd1 (>= 1.8.4-7), libncurses5 (>= 5.2.20010310-1), libpam0g (>= 0.72-1), libpng2 (>= 1.0.12), libstdc++2.10-glibc2.2 (>= 1:2.95.4-0.010810), libxml1 (>= 1:1.8.14-3), python2.1, xlibs (>> 4.1.0), zlib1g (>= 1:1.1.3)
--
Package: bpowerd
Depends: sysvinit (>= 2.69), libc6 (>= 2.2.1-2)
--
Package: console-tools
Depends: console-tools-libs (= 1:0.2.3-23.3), libc6 (>= 2.2.4-2), sysvinit (>> 2.74), console-common, debconf (>= 0.5)
--
Package: kbd
Depends: libc6 (>= 2.2.4-4), sysvinit (>= 2.74), console-common, debconf (>= 0.5), dpkg (>= 1.4.0.21)
--
Package: file-rc
Depends: sysvinit (>= 2.80-1)
--
Package: klisa
Depends: kdelibs3 (>= 4:2.2.2-1), libc6 (>= 2.2.4-4), libstdc++2.10-glibc2.2 (>= 1:2.95.4-0.010810), debconf, sysvinit (>= 2.80-1)
--
Package: modutils
Depends: libc6 (>= 2.2.4-4), sysvinit (>= 2.71-2)
________________________________________________________________________
you see: for example ppp and modutils will never be ported to the hurd
part. *note*: bsdutils isn't here!
hurd-unstable (is really the same unstable as for linux, or an alias for
testing, or..?):
________________________________________________________________________
$ grep -B 10 "Depends: .*sysvinit" /mnt/gnu/var/lib/dpkg/available | grep "Package: \|Depends: \|^--$"
Package: bsdutils
Depends: sysvinit (>= 2.59-2), shellutils (>= 1.15-3)
--
Package: file-rc
Depends: sysvinit (>= 2.80-1)
________________________________________________________________________
the good news, bsdutils doesn't depends on sysvinit in the linux part,
so surelly the dependece isn't very hard, maybe just with an update we
wet rid of the problem.
what about file-rc? i haven't it installed but, the description:
________________________________________________________________________
file-rc - Alternative boot mechanism using a single configuration file
This package provides an alternative mechanism to boot the system, to
shut it down and to change runlevels. The /etc/rc?.d/* links will be
converted into one single configuration file /etc/runlevel.conf instead,
which is easier to administrate than symlinks, and is also more
flexible.
The package will automatically convert your existing symlinks into the
file method on installation, and convert the file back into symlinks on
removal. Both mechanisms are compatible through /etc/init.d/rc,
/etc/init.d/rcS, /usr/sbin/update-rc.d, and /usr/sbin/invoke-rc.d
scripts.
________________________________________________________________________
i suppose that this is a "linuxism", it makes sense such a pkg in the
hurd, as it relies on the sysvinit which doesn't make sense for the
hurd? or is it a better, advanced method in the way /libexec/rc works?
i hope all this stuff/noise helps :)
> Thanks,
> Marcus
aburinho!!
________________________________________________________________________
Manuel A. Fernández Montecelo <manuel@sindominio.net>
<manuel@es.gnu.org>
<mfernandez@bec.uned.es>
Reply to: