Re: Unmark auto without apt-mark or aptitutude?
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
Reply to: