Am 14.12.2011 01:33, schrieb Bob Proulx: > Malte Forkel wrote: >> Can I safely modify /var/lib/apt/extended_states in a postinst skript, >> that is while aptitude | apt-get | ... is running? > > Ew... That could be scary! The short answer is that I don't know. > Certainly an official package would no be allowed to do it. But would > it work? I don't know. Maybe. I think that postinst time is at a > completely different time from when apt edits that package so it would > probably interlace acceptably. That would change this suggestion hack > into a serious hack. > > Can I ask why you want to do it in a package postinst? I assumed you > had just wanted to diddle the status of a package or two without > actually removing and reinstalling the package. But now it sounds > like you want to do something more extensive. Perhaps it would be > better to do using cfengine, puppet, chef, shell script or other tool. > (I use one of the other tools.) This just doesn't seem like something > that would work out well in a package. Sounds like something that > most people might recommend puppet and similar for instead. >
I'm writing a transitional package to handle a software name change. The transitional package 'depends' on the new package. So during an upgrade, the new package is installed automatically and marked accordingly. But once the user decides to purge the transitional package, the new packaged would be removed as well. That I want to circumvent by unmarking the new package as auto. I thought about doing that in the postinst script of the transitional package. Its run after both packaged have been installed, but obviously while they are being configured by the package management tool. May be my approach to writing the transitional package is flawed, though. I tried to follow the approach in "Renaming a Package" in the Debian Wiki (http://wiki.debian.org/Renaming_a_Package). But I noticed a second, smaller problem that doesn't seem to be mentioned anywhere: , The new packages 'replaces' the old package. After the upgrade, the transitional package "owns" the configuration files not taken over by the new package. Over on Debian Devel, I'm asking how the transitional package could be made to forget about some of them (http://lists.debian.org/debian-devel/2011/12/msg00337.html). Malte -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jc9lrr$nrj$1...@dough.gmane.org
