Re: debian-devel-digest Digest V100 #103
debian-devel-digest-request，您好！
在 00-10-7 15:15:00 您写道：
>Content-Type: text/plain
>
>debian-devel-digest Digest Volume 100 : Issue 103
>
>Today's Topics:
> Re: ssh and hostname (libc NSS and i [ Ben Collins <bcollins@debian.org> ]
> Re: Graphical Installer ? [ Ben Pfaff <pfaffben@msu.edu> ]
> How to move a conffile ? [ Gregor Hoffleit <gregor@hoffleit.de ]
> Re: Debian boot system [ Michael Moerz <e9625136@student.tuw ]
> Re: Debian boot system [ Junichi Uekawa <dancer@netfort.gr.j ]
> Re: Debian boot system [ Eyal Lotem <eyal@hyperroll.com> ]
> Please test new ntop packages before [ "Oliver M . Bolzer" <oliver@gol.com ]
> Re: gettextized console-apt [ Patrick Cole <z@amused.net> ]
> Re: Debian boot system [ Eyal Lotem <eyal@hyperroll.com> ]
> Re: Debian boot system [ Eyal Lotem <eyal@hyperroll.com> ]
> Re: Debian boot system [ Eyal Lotem <eyal@hyperroll.com> ]
>
>Date: Sat, 7 Oct 2000 09:18:06 -0400
>From: Ben Collins <bcollins@debian.org>
>To: brent@rcfile.org
>Cc: debian-devel@lists.debian.org
>Subject: Re: ssh and hostname (libc NSS and ipv4)
>Message-ID: <20001007091806.A749@visi.net>
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>
>On Fri, Oct 06, 2000 at 04:21:06PM -0400, brent@rcfile.org wrote:
>> On 06 Oct 2000 at 10:40 (-0500), An Thi-Nguyen Le wrote:
>> | On Fri, Oct 06, 2000 at 11:39:32AM -0400, brent@rcfile.org typed:
>> |
>> | } recompiling did not solve the problem for me, but the non-stripped
>> | } binary was good for a gdb session -- unfortunately, I have no nice
>> | } way to debug into libc6 :(
>> |
>> | I think the problem is somewhere deep in libc6-2.1.94. For some
>> | reason ipv4 addresses are okay, but ipv6 addresses cause seg faults.
>> | For instance, if (somehow) you got an ipv6 connection to a machine
>> | with libc6-2.1.94 (say, old ssh connections that were around after
>> | the upgrade) and you run netstat -at, netstat will core dump on
>> | hostname lookup of the ipv6 stuff. netstat -nat will not result in
>> | a core dump, and you can see the ipv6 stuff.
>>
>> FWIW, the only failures I'm seeing are on _local_ hostnames.
>
>This is an error in ssh, IMO. I've heard the same story from someone else
>who claims that if you disable IPv6 as the default (not disable
>completely, jut don't make it the default), then it fixes this problem.
>
>--
> -----------=======-=-======-=========-----------=====------------=-=------
>/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
>` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
> `---=========------=======-------------=-=-----=-===-======-------=--=---'
>
>Date: 07 Oct 2000 09:46:17 -0400
>From: Ben Pfaff <pfaffben@msu.edu>
>To: Ethan Benson <erbenson@alaska.net>
>Cc: Debian Developer Mailing List <debian-devel@lists.debian.org>
>Subject: Re: Graphical Installer ?
>Message-ID: <87pulc4vdi.fsf@pfaffben.user.msu.edu>
>
>Ethan Benson <erbenson@alaska.net> writes:
>
>> i have never met an X based first stage installer i didn't hate, that
>> is say an X based incarnation of dbootstrap.
>
>Let me recommend again that people take a look at the code I
>wrote a year or more ago for a graphical dbootstrap. It isn't
>X-based, it is framebuffer based, and it doesn't take any more
>floppies than the textual installer.
>
>Date: Sat, 7 Oct 2000 14:00:24 +0200
>From: Gregor Hoffleit <gregor@hoffleit.de>
>To: Debian Development list <debian-devel@lists.debian.org>
>Subject: How to move a conffile ?
>Message-ID: <20001007140024.A10153@53b.hoffleit.de>
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>
>With the next revision of masqmail, I'd like to move the conffile
>/etc/masqmail.conf to /etc/masqmail/masqmail.conf. What's the best way to do
>this ?
>
>Is it okay if I just change the position in conffiles and then include this
>in the preinst script, or do I have to make more efforts (e.g. announce this
>to the user via debconf) ?
>
> # move config file to new location
> if [ -e /etc/masqmail.conf ]; then
> if [ ! -d /etc/masqmail ]; then
> mkdir /etc/masqmail
> fi
> mv -f /etc/masqmail.conf /etc/masqmail/
> fi
>
>
>
> Gregor Hoffleit
>
>
>Date: Sat, 7 Oct 2000 15:52:26 +0200 (METDST)
>From: Michael Moerz <e9625136@student.tuwien.ac.at>
>To: Eyal Lotem <eyal@hyperroll.com>
>cc: Michael Moerz <e9625136@student.tuwien.ac.at>,
> debian devel <debian-devel@lists.debian.org>
>Subject: Re: Debian boot system
>Message-ID: <Pine.HPX.4.10.10010071542140.27953-100000@stud3.tuwien.ac.at>
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>Hi!
>
>On Sat, 7 Oct 2000, Eyal Lotem wrote:
>
>> On Sat, 07 Oct 2000, Michael Moerz wrote:
>> > you will have to create an API with the functionality to add, modify and
>> > delete services including defining dependencies.
>> Yeap, basically, I could have a Makefile that included all the Makefiles in
>> the directory, and a software package would just add Makefiles to that
>> Makepool, with the virtual services and dependencies they have.
>>
>is nice, and ok, I would say.
>> > Yeah, make will do the parallisation, but did you ever think about the
>> > output of the starting services? As stated in make's info there is NO
>> > guarantie that the output might get not mixed. How will you cope with that
>> > by simply using make? Did you ever think about that? You would have to
>> > seperate the output of the services and then to put it together again. But
>> > that would create a problem when debugging unknown dependencies. I mean
>> > when a failure happens in parallisation and two services are started
>> > concurrently and it happens that some struggling code pieces are executed
>> > together. Reproducing such events would be hardly possible due to
>> > race-conditions. Debugging for the error without knowing when and what was
>> > running is also impossible.
>> Just cancel out the parallilism for a boot, and you know right there if it is
>> the root of the problem. If it is, your dependencies are wrong. Race
>> conditions might be a nightmare when programming, but when running
>> shellscripts? The problems should be more trivial and less problematic,
>> especially as you add redundant dependencies.
>> About the log mixing: How about seperate logs for seperate daemons? Perhaps
>> putting it all together as a final step of the boot process?
>>
>Oh, yeah, why not patch every daemon in this and that direction adding
>this feature and an other, so making it impossible to run unpatched
>daemons.
> > > mmh, I don't want to think about the mixed output.
>> Yes, I have mixed output, the dots are everywhere :) All fixable.
>>
>All fixable? did you ever think of missing output? Did you ever really
>read the make - infopage ? I did, I know make, and I have used it to it's
>best. OUTPUT might get lost, mixed and whatever. That is not desireable.
>And opposing someone to boot non parallelised when having problems won't
>solve them. As I stated before a way to determine when and what was
>running is the only way to disolve this issue. There are no other nifty
>tricks that can be played around this.
>
>Actually I highly suggest you to read the make-infopage before you go on
>telling me that it is easily fixable. You would have to redirect the
>output of all services started and to put it back together for logging.
>There comes in the issue that during this building of output the computer
>might get hung and the last and important messages for solving the problem
>might get lost. I hope I have now pointed you out at the *real* problem.
>
>I really do not wanna turn you down nor I intend to offend your idea. I
>think it's really nice having such a parallelised boot, but not when I
>will loose determinisation what caused my computer to stop at boot.
>
>--
>kind regards,
>Michael Moerz
>
>Date: Sat, 7 Oct 2000 13:34:53 +0900
>From: Junichi Uekawa <dancer@netfort.gr.jp>
>To: Henrique M Holschuh <hmh+debianml@rcm.org.br>
>Cc: jpk@cape.com, Simon.Richter@phobos.fachschaften.tu-muenchen.de,
> eyal@hyperroll.com, debian-devel@lists.debian.org
>Subject: Re: Debian boot system
>Message-Id: <200010071355.WAA25920@mail.doshisha.ac.jp>
>Content-Transfer-Encoding: 7bit
>Content-Type: text/plain; charset=US-ASCII
>
>In Fri, 6 Oct 2000 20:40:00 -0200 Henrique M Holschuh <hmh+debianml@rcm.org.br> cum veritate scripsit :
>
>> This needs quite a lot of work to be done right, but it is viable... as long
>> as you have a *human made* file describing all allowed paralelizations (and
>> everything else *especially stuff not in the allowed paralellization list*
>> runs serialized as it would be done by the stock rcS script, when compared
>> to each other AND the now paralelized initscripts).
>>
>> There is not enough information in place (in Debian) to build the
>> paralelization list automatically.
>
>There is what I consider a *bug* in Debian,
>
>per default init scripts are executed in the same order in the boot
>sequence and the shutdown sequence.
>
>It's appears from time to time in the list, and it's not fixed.
>
>So, instead of:
>
>
>initialize PCMCIA cards
> initialize Network
> mount NFS
> unmount NFS
> deinitialize Network
>deinitialize PCMCIA cards
>
>
>The current situation is :
>
>initialize PCMCIA cards
> initialize Network
> mount NFS
>try to deinitialize PCMCIA cards and barf because the network modules are busy and cannot be unloaded
>uninstall network modules without any regards as to what's happening to NFS
>Try and unmount NFS drives and cry out that network connection is not available.
>
>
>
>... is this fixed?
>I think it is a bug of update-rc.d, but changing the default behavior of update-rc.d alone
>might break many packages.
>
>
>regards,
> junichi
>
>--
>University: ti0113@mail4.doshisha.ac.jp Netfort: dancer@netfort.gr.jp
>dancer, a.k.a. Junichi Uekawa http://www.netfort.gr.jp/~dancer
> Dept. of Knowledge Engineering and Computer Science, Doshisha University.
>... Long Live Free Software, LIBERTAS OMNI VINCIT.
>
>Date: Sat, 7 Oct 2000 16:22:10 +0200
>From: Eyal Lotem <eyal@hyperroll.com>
>To: Michael Moerz <e9625136@student.tuwien.ac.at>,
> debian devel <debian-devel@lists.debian.org>
>Subject: Re: Debian boot system
>Message-Id: <00100716221007.02668@beelzebub>
>Content-Type: text/plain
>Content-Transfer-Encoding: 8bit
>
>On Sat, 07 Oct 2000, Michael Moerz wrote:
>
>> > Just cancel out the parallilism for a boot, and you know right there if
>> > it is the root of the problem. If it is, your dependencies are wrong.
>> > Race conditions might be a nightmare when programming, but when running
>> > shellscripts? The problems should be more trivial and less problematic,
>> > especially as you add redundant dependencies.
>> > About the log mixing: How about seperate logs for seperate daemons?
>> > Perhaps putting it all together as a final step of the boot process?
>>
>> Oh, yeah, why not patch every daemon in this and that direction adding
>> this feature and an other, so making it impossible to run unpatched
>> daemons.
>Patch every daemon? You misunderstood me, just redirect the output of the
>script from the Makefile itself.
>Any extra fucntionality such as maintainance of the Makefiles is possible to
>add to packages.
>
>> > Yes, I have mixed output, the dots are everywhere :) All fixable.
>>
>> All fixable? did you ever think of missing output? Did you ever really
>> read the make - infopage ? I did, I know make, and I have used it to it's
>> best. OUTPUT might get lost, mixed and whatever. That is not desireable.
>> And opposing someone to boot non parallelised when having problems won't
>> solve them. As I stated before a way to determine when and what was
>> running is the only way to disolve this issue. There are no other nifty
>> tricks that can be played around this.
>Output can get lost? I went through the INFO page briefly, and read about
>the mixed output concerns further, but there's no mention of losing output.
>Can you direct me to the exact place where that is written? The simple
>collection of individual output logs of the init scripts, with timestamps on
>everything, should be quite enough info. to know what happened when, very
>specifically.
>
>> Actually I highly suggest you to read the make-infopage before you go on
>> telling me that it is easily fixable. You would have to redirect the
>> output of all services started and to put it back together for logging.
>> There comes in the issue that during this building of output the computer
>> might get hung and the last and important messages for solving the problem
>> might get lost. I hope I have now pointed you out at the *real* problem.
>If the computer hanging makes the daemon lose its last messages, when
>parallilsm is turned off, how is it ANY different from the traditional SysV
>last lines of the logs getting lost?
>When having problems, I think its safe to say you want and will disable
>parallilsm. Without parallilsm, there is not much of a difference between
>SystemV and the Makefile, from the aspect of logs, the way the order of the
>commands is deduced is the only difference in that case.
>
>> I really do not wanna turn you down nor I intend to offend your idea. I
>> think it's really nice having such a parallelised boot, but not when I
>> will loose determinisation what caused my computer to stop at boot.
>Cancelling out parallilsm temporarily should be a resolution of most of these
>problems.
>Other problems in parllilsm itself are resolvable by checking which daemons
>were still unloaded (those loaded _DO_ appear in the logs), and checking
>their dependencies.
>
>Eyal Lotem
>
>Date: Sat, 7 Oct 2000 16:26:07 +0200
>From: "Oliver M . Bolzer" <oliver@gol.com>
>To: debian-devel@lists.debian.org
>Subject: Please test new ntop packages before dupload
>Message-ID: <20001007162607.A28891@magi.sukisuki.org>
>Content-Type: multipart/signed; micalg=pgp-sha1;
> protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi"
>Content-Disposition: inline
>Content-Transfer-Encoding: 7bit
>
>--6c2NcOVqGQ03X4Wi
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>Following my ITA on ntop, I have prepared a package based on upstream
>CVS. They are available for testing at http://master.debian.org/~oliver/
>If nobody cries out loud, I'm going to dupload them mid-week.
>
>The above package is compiled without SSL but with tcpd support, to be able
>to restrict connections. Also funky color charts in web mode are disabled
>as the charting library (gdchart)'s licence is not clearly formatted and
>could be interpreted non-free. The author of gdchart has promised to
> rephrase his licence to be DFSG-free for the next release. When that is
>released I'l package it and make ntop depend on it.
>
>Also I have a small questions. Where should I put plugins (*.so) for
>ntop. Currently I have put them into /usr/lib/ntop but lintian now
>complains with errors like
>E: ntop: ldconfig-symlink-missing-for-shlib usr/lib/ntop/icmpPlugin.so libi=
>cmpPlugin.so.2
>E: ntop: no-shlibs-control-file usr/lib/ntop/icmpPlugin.so
>
>Is it OK for me to ignore these as the plugins will only be used by ntop?
>
>Thanks!
>
>--=20
>
> Oliver M. Bolzer
> oliver@gol.com
>
>GPG (PGP) Fingerprint =3D 621B 52F6 2AC1 36DB 8761 018F 8786 87AD EF50 D1FF
>
>
>--6c2NcOVqGQ03X4Wi
>Content-Type: application/pgp-signature
>Content-Disposition: inline
>Content-Transfer-Encoding: 7bit
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.3 (GNU/Linux)
>Comment: For info see http://www.gnupg.org
>
>iD8DBQE53zJ/h4aHre9Q0f8RAgiWAJ0UBgwTnRLT7AMS4t9tai7JBb1+HwCfYHw0
>KaLlJIyyFytldhmscitO2k4=
>=LbP3
>-----END PGP SIGNATURE-----
>
>--6c2NcOVqGQ03X4Wi--
>
>Date: Sun, 08 Oct 2000 01:43:02 +1100 (EST)
>From: Patrick Cole <z@amused.net>
>To: kiwamu <kiwamu@debian.or.jp>
>Cc: debian-devel@lists.debian.org
>Subject: Re: gettextized console-apt
>Message-ID: <XFMail.20001008014302.z@amused.net>
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 8bit
>
>> Hi!
>>
>> The console-apt CVS repository <cvs.linearg.com> don't have
>> "interface/gtk/pixmaps/" directory.
>> We can't make the console-apt without it.
>> May I add it to the CVS repository?
>
>It actually is in there. Perhaps you don't have update -d in ~/.cvsrc ?
>
>Date: Sat, 7 Oct 2000 16:56:33 +0200
>From: Eyal Lotem <eyal@hyperroll.com>
>To: debian devel <debian-devel@lists.debian.org>
>Subject: Re: Debian boot system
>Message-Id: <00100716563309.02668@beelzebub>
>Content-Type: text/plain
>Content-Transfer-Encoding: 8bit
>
>It seems my messages don't get through to debian-devel by random occurance,
>so again, if I send the same message multiple times, I appologize.
>
>On Sat, 07 Oct 2000, Michael Moerz wrote:
>> To write a new make? Do you really think that would be so easily done?
>> what kind of language will you be using? perl?????
>
>No, to write a new minimake, that can even use remarks telling it what rules
>to seek and run, without supporting any variables or other make features.
>This should be good enough for the first steps, getting /usr/bin accessible.
>
>> As I stated before the right ordering and the guarantied not mixed OUTPUT
>> is the biggest concern when it comes to parallelisation. Also knowing when
>> and what was executed might help when having problems with this parallel
>> stuff.
>
>Line-output does not seem to get mixed (output is flushed on a per-line
>basis), and using seperate log files does resolve this, as timestamps are
>attached to each message, you know at ANY given point what was running, what
>was loading, and what anything said.
>
>> might be that for a 5-minute one it's a very good draft, for giving things
>> a first try even too, but for a distro some more points have to met.
>> I'd say getting back to making a more detailed draft, that meets the
>> OUTPUT problem is good idea to start with.
>
>Alright, I could simply redirect the output of every script I run to $@.log,
>and have it add a timestamp of when the log was started at least, if the
>daemon doesn't add timestamps to its output.
>
>Eyal Lotem
>
>Date: Sat, 7 Oct 2000 16:59:10 +0200
>From: Eyal Lotem <eyal@hyperroll.com>
>To: debian-devel@lists.debian.org
>Subject: Re: Debian boot system
>Message-Id: <0010071659100A.02668@beelzebub>
>Content-Type: text/plain
>Content-Transfer-Encoding: 8bit
>
>It seemed to me that somewhere along the road, this mail was lost :(
>So if this is the second (/third) appearance of it, I appologize.
>
>On Sat, 07 Oct 2000, Henrique M Holschuh wrote:
>> > No. You need to create a Makefile, that can be SEPERATELY and
>> > INDEPENDENTLY
>>
>> No, "separately and independently" management will cause you problems. What
>> I mean to say is: You only have available the update-rc.d interface (and,
>> if I have my way with Debian's initsystem, you'll have a start-rc.d and
>> optional policy-rc.d interfaces as well, but that's a matter for another
>> post when I finish testing the code), and you must be able to migrate from
>> one init system to the other. Please look at the file-rc package to see how
>> its done.
>
>Ok, I have a simple solution to it then :)
>The Makefile itself contains all the information and dependencies, and really
>shouldn't be larger than a few K's normally, or dozens of K's, at worst.
>This Makefile can be kept on all systems, and be the actual source of
>information about the bootup system. This Makefile could be maintained by a
>simple script that parses it and updates its dependencies/rules. This
>makefile will have rules for each runlevel, specifying which subset of
>services/etc should be started for that runlevel. To run the actual init.d
>scripts from the Makefile, you would use an overrid'able variable in the
>Makefile, that under normal circumstances (normal make-booting), would run
>the scripts, whereas under sysVinit system generation, would output the
>command to run, with an increasing preceding number, to identify its location
>in the order of the boot. (such as S20isdnutils S21proftpd S22... etc)
>
>To create the traditional System V system out of that Makefile should be
>fairly simple. All you do is run make on the Makefile, with the
>running-command variable overridden to just print out the names of what to
>run, and you use this output to generate the symlinks pool. (Or something
>like this)
>
>> 1. change /etc/init.d/rc (and maybe /etc/init.d/rcS) to the new initsystem
>> machinery, using dpkg-divert.
>> 2. provide script that migrates from old rc?.d to new scheme automatically.
>> 3. provide script that migrates from new scheme to old rc?.d automatically,
>> in such a way that doing 2, installing and removing packages, and then
>> doing 3 will not lose initscript information.
>> 4. use dpkg-divert to take over update-rc.d (and maybe, if I can prove it
>> to be worth the hassle to deploy, take over start-rc.d as well) -- for a
>> basic makefile approach you'll only need to take over update-rc.d, I
>> suppose.
>
>All these things would just be removing/re-generating the system V init
>scripts, from the Makefile, that will always sit there.
>
>> > True, the Debian packages of daemons and other boot-related software need
>> > a change to support maintaining the boot Makefile.
>>
>> Yes. And I will bet with you that getting this into policy will require a
>> careful design and some effort. Your dependency information *needs* to be
>> usable for automated tools generating serialized initscripts as well, or it
>> isn't likely to be accepted, IMHO.
>
>Well, they supply the information to maintain the Makefile, and the Makefile
>is useful enough to create a System V init system.
>
>> > I do not know much about the problems the LSB guys are encountering, but
>> > if they are, their problem is probably not very similar to this one,
>> > because in this one, its quite trivial to specify the obvious
>> > dependencies (at least all that are handled by the sequential boot
>> > system).
>>
>> Basically, where and how are you going to store the dependencies? (the LSB
>> wants it inside comments in the /etc/init.d right now, I think). You also
>> need standard, well-defined, "virtual service names" (think of Debian's
>> virtual packages) to allow a initscript to request that "I can only be run
>> after /usr is mounted, and all networking is up" and stuff like that. I
>> think the LSB wants to do away with the sequence numbers, as they're not
>> stable across distributions.
>
>Well, I do have 'virtual service names', and I specify the dependencies just
>like you specify dependencies of rules in any Makefile..
>
>> You'll notice that a initscript which can tell you (without rc?.d sequence
>> numbers) exactly what it needs to be started/stopped is just what you need
>> for your makefile approach to calculate dependencies automatically.
>
>I think that's quite backwards, instead of that, I can have the Makefile tell
>me just what I need, and the system V order should be calculated
>automatically.
>
>> > Well, I've gained 6 out of 30 seconds here (20% or 25% difference,
>> > depending
>>
>> What machine you used for your measurements?
>
>Athlon 750/128MB ram
>
>> > I think its worth the trouble, especially when you consider a complete
>> > Makefile, containing ALL the dependencies from the rc*.d scripts took
>> > minutes to make and should be quite easy to be software-maintainable.
>>
>> I give. It is worth the trouble, but please consider the points I made
>> above about getting it done *right*. And I suggest you approach this as an
>> optional drop-in package which enables your paralell scheme when installed,
>> and reverts the system to sysvinit behaviour when removed. Don't worry
>> about making it the Debian default.
>
>This could be an optional package, as long as the Makefile is THE true
>specification of dependencies and the core of the boot system, it should be
>fairly simple.
>
>> > I think the more graceful error recovery (remmember the
>> > hostname-not-resolvable sendmail problem?), and the extra flexibility
>> > (the ability to easily specify the SPECIFIC dependencies (Current
>> > systems, for example, will sometimes not shutdown correctly, and try to
>> > unmount NFS after shutting down the network, because the order is
>> > specified manually, instead of being deduced from simpler[to humans]
>> > dependency specifications)
>>
>> That's what the LSB wants too, I guess. And it is more valuable (to me)
>> than the -j2 effect :-)
>
>Same here :)
>
>Eyal Lotem
>
>-------------------------------------------------------
>
>------------------------------
>
>Date: Sat, 7 Oct 2000 15:17:35 +0200
>From: Eyal Lotem <eyal@hyperroll.com>
>To: Henrique M Holschuh <hmh+debianml@rcm.org.br>
>Cc: debian-devel@lists.debian.org
>Subject: Re: Debian boot system
>Message-Id: <00100715173503.02668@beelzebub>
>Content-Type: text/plain
>Content-Transfer-Encoding: 8bit
>
>On Sat, 07 Oct 2000, Henrique M Holschuh wrote:
>
>> > No. You need to create a Makefile, that can be SEPERATELY and
>> > INDEPENDENTLY
>>
>> No, "separately and independently" management will cause you problems. What
>> I mean to say is: You only have available the update-rc.d interface (and,
>> if I have my way with Debian's initsystem, you'll have a start-rc.d and
>> optional policy-rc.d interfaces as well, but that's a matter for another
>> post when I finish testing the code), and you must be able to migrate from
>> one init system to the other. Please look at the file-rc package to see how
>> its done.
>Ok, I have a simple solution to it then :)
>The Makefile itself contains all the information and dependencies, and really
>shouldn't be larger than some dozens of K's, at worst. This Makefile can be
>kept on all systems, and be the actual source of information about the bootup
>system. This Makefile could be maintained by a simple script that parses it
>and updates its dependencies/rules.
>This makefile will have rules for each runlevel, specifying which subset of
>services/etc should be started for that runlevel.
>To run the actual init.d scripts from the Makefile, you would use an
>overrid'able variable in the Makefile, that under normal circumstances
>(normal make-booting), would run the scripts, whereas under sysVinit system
>generation, would output the command to run, with an increasing preceding
>number, to identify its location in the order of the boot. (such as
>S20isdnutils S21proftpd S22... etc)
>
>To create the traditional System V system out of that Makefile should be
>fairly simple. All you do is run make on the Makefile, with the
>running-command variable overridden to just print out the names of what to
>run, and you use this output to generate the symlinks pool.
>
>> 1. change /etc/init.d/rc (and maybe /etc/init.d/rcS) to the new initsystem
>> machinery, using dpkg-divert.
>> 2. provide script that migrates from old rc?.d to new scheme automatically.
>> 3. provide script that migrates from new scheme to old rc?.d automatically,
>> in such a way that doing 2, installing and removing packages, and then
>> doing 3 will not lose initscript information.
>> 4. use dpkg-divert to take over update-rc.d (and maybe, if I can prove it
>> to be worth the hassle to deploy, take over start-rc.d as well) -- for a
>> basic makefile approach you'll only need to take over update-rc.d, I
>> suppose.
>All these things would just be removing/re-generating the system V init
>scripts, from the Makefile, that will always sit there.
>
>> > True, the Debian packages of daemons and other boot-related software need
>> > a change to support maintaining the boot Makefile.
>>
>> Yes. And I will bet with you that getting this into policy will require a
>> careful design and some effort. Your dependency information *needs* to be
>> usable for automated tools generating serialized initscripts as well, or it
>> isn't likely to be accepted, IMHO.
>Well, they supply the information to maintain the Makefile, and the Makefile
>is useful enough to create a System V init system.
>
>> > I do not know much about the problems the LSB guys are encountering, but
>> > if they are, their problem is probably not very similar to this one,
>> > because in this one, its quite trivial to specify the obvious
>> > dependencies (at least all that are handled by the sequential boot
>> > system).
>>
>> Basically, where and how are you going to store the dependencies? (the LSB
>> wants it inside comments in the /etc/init.d right now, I think). You also
>> need standard, well-defined, "virtual service names" (think of Debian's
>> virtual packages) to allow a initscript to request that "I can only be run
>> after /usr is mounted, and all networking is up" and stuff like that. I
>> think the LSB wants to do away with the sequence numbers, as they're not
>> stable across distributions.
>Well, I do have 'virtual service names', and I specify the dependencies just
>like you specify dependencies of rules in any Makefile..
>
>> You'll notice that a initscript which can tell you (without rc?.d sequence
>> numbers) exactly what it needs to be started/stopped is just what you need
>> for your makefile approach to calculate dependencies automatically.
>I think that's quite backwards, instead of that, I can have the Makefile tell
>me just what I need, and the system V order should be calculated
>automatically.
>> > Well, I've gained 6 out of 30 seconds here (20% or 25% difference,
>> > depending
>>
>> What machine you used for your measurements?
>Athlon 750/128MB ram
>>
>> > I think its worth the trouble, especially when you consider a complete
>> > Makefile, containing ALL the dependencies from the rc*.d scripts took
>> > minutes to make and should be quite easy to be software-maintainable.
>>
>> I give. It is worth the trouble, but please consider the points I made
>> above about getting it done *right*. And I suggest you approach this as an
>> optional drop-in package which enables your paralell scheme when installed,
>> and reverts the system to sysvinit behaviour when removed. Don't worry
>> about making it the Debian default.
>This could be an optional package, as long as the Makefile is THE true
>specification of dependencies and the core of the boot system, it should be
>fairly simple.
>> > I think the more graceful error recovery (remmember the
>> > hostname-not-resolvable sendmail problem?), and the extra flexibility
>> > (the ability to easily specify the SPECIFIC dependencies (Current
>> > systems, for example, will sometimes not shutdown correctly, and try to
>> > unmount NFS after shutting down the network, because the order is
>> > specified manually, instead of being deduced from simpler[to humans]
>> > dependency specifications)
>>
>> That's what the LSB wants too, I guess. And it is more valuable (to me)
>> than the -j2 effect :-)
>Same here :)
>
>Eyal Lotem
致
礼！
jim
nmx007@etang.com
Reply to: