Dmitry Bogatov wrote: > [2016-08-24 07:16] Jamie Heilman <ja...@audible.transient.net> > > > > Package: runit > > Version: 2.1.2-6 > > > > Preparing to unpack .../runit_2.1.2-6_amd64.deb ... > > unsupported: /etc/service exists, but does not point to > > /etc/runit/runsvdir/current > > dpkg: error processing archive > > /var/cache/apt/archives/runit_2.1.2-6_amd64.deb (--unpack): > > subprocess new pre-installation script returned error exit status 1 > > > > Something in the whole upgrade path here just isn't working right, > > this is coming from 2.1.2-5 which had some stuff in /etc/runit/runsvdir/ > > I know about this problem, but have no idea how to solve it > correctly.
The simplest answer is "don't create the problem to begin with." The runit package never depended on the runlevels support infrastructure being used in the past because runit as pid 1 and runit-init isn't something everybody uses, and there's no reason that this has to change. You added the checks in preinst, but I can't think of a single good reason for them. Since you already closed 833361 as won't fix, it's really not clear to me why now you're trying to force everybody to use a service directory layout that is incompatible with how the package has historically functioned, and really only useful in the event that you do want runit as pid 1 --- that functionality would truely be much more apropriate if enabled by a separate package. > Here we have transition from /service as directory to /service as > symbolic link. > > Simple way would be just remove /service and replace it with > symlink. But sysadmin, who put his stuff into /etc/service would > hate me. > > I could move /etc/service content into /etc/runit/runsvdir/current, > but it also could break things, in more subtle ways. > > Maybe I should move /etc/service into /etc/service.dpkg-old and > print huge box about it? WDYT? No that would be even worse. runsvdir would fill the proctitle with angry messages potentially obscuring errors that matter to the user. While it is possible to migrate to the runlevels layout, I'm not going to explain how because its a bad idea to change this package in that manner. It would be more acceptable to provide a script that can automate the migration in the event the user wants that functionality. To make matters worse, now there's a version of this packge in the wild that defaults to the runlevels layout, and it doesn't even have a NEWS file entry to notify anybody of why this was done, or what they need to be aware of. -- Jamie Heilman http://audible.transient.net/~jamie/
