[Michael Schutte] > The problem you describe only occurs when a user replaces one > console utility package by the other, and the old package isn't > purged in this process. Both scripts do pretty much the same thing, > and they are mutually exclusive, so only one of them will ever be > executed during init.
Yes, and it will block migration from the old to the new package for everyone using dependency based boot sequencing. > Do you think such a mechanism is a good idea (and its implementation > feasible) at all? Maybe there are some dangers or serious problems > I miss completely. I'm not sure. I suggest creating a wishlist bug for insserv with this proposal, and let me pass it by the insserv upstream to get his opinion. > And then I don't like the idea of adding more and more 'reverse > dependencies' to the X-Start-Before: line as I grep the whole > archive from time to time, or users report bugs. In my experience, there are very few scripts a given script need to declare a relationship to. Of course one could ask for the other packages to add dependencies instead of using reverse dependencies, and in most cases it make sense. :) > Yup, I thought about that and may in fact take this path eventually. > There are only few packages that would have to be changed from > console-screen to (say) $console requirements. I nonetheless think > it isn't really nice to create a new virtual facility for two init > scripts of which one won't even run if the other one does. Sure, a new virtual facility should only be created because it make sense to let several scripts provide the service, not to work around LSB issues with only two scripts. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
