Renaming packages: maintscripts

[Michael Tokarev]

Hello.

It's been not once when I hit an issue described below.
Now I hit it in one of the packages I maintain, but so
far I can't figure out a good solution for it.

The issue is with package renaming and handling of dpkg
maintscripts.

Having in mind typical renaming scenario: package A has
been renamed to B, and transitional package A' has been
created - dummy which merely depends on B, so that upgrades
work fine.  B breaks A before the transitional version,
so dependencies ensures that A and B aren't installed
at the same time.

Everything works fine indeed till someone tries to install
B on a system where A is installed, without upgrading A
to A'.  Apt solves the Breaks by removing A, but not purging
it.  So we're left with dpkg maintscripts from A.

And quite often, on purge, maintscripts removes config files
(especially ucf-managed) and performs other cleanup.  But all
that should not be done, since it will now break B!

Basically I want to ensure that if one installs package B to
a system with A installed, A should be upgraded to A' at the
same time.  This works when upgrading A to A' (satisfying A'
dependency and installing B), but does not work when installing
B alone when A is installed.

Only this way it is possible to work around old maintscripts
in the renamed package.

But I don't see a way to satisfy this.  Something I didn't think
of ?

Thanks,

/mjt


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/50433290.5030200@...

[Salvatore Bonaccorso-4]

Hi Michael

On Sun, Sep 02, 2012 at 02:18:56PM +0400, Michael Tokarev wrote:

> It's been not once when I hit an issue described below.
> Now I hit it in one of the packages I maintain, but so
> far I can't figure out a good solution for it.
>
> The issue is with package renaming and handling of dpkg
> maintscripts.
>
> Having in mind typical renaming scenario: package A has
> been renamed to B, and transitional package A' has been
> created - dummy which merely depends on B, so that upgrades
> work fine.  B breaks A before the transitional version,
> so dependencies ensures that A and B aren't installed
> at the same time.
>
> Everything works fine indeed till someone tries to install
> B on a system where A is installed, without upgrading A
> to A'.  Apt solves the Breaks by removing A, but not purging
> it.  So we're left with dpkg maintscripts from A.
>
> And quite often, on purge, maintscripts removes config files
> (especially ucf-managed) and performs other cleanup.  But all
> that should not be done, since it will now break B!
>
> Basically I want to ensure that if one installs package B to
> a system with A installed, A should be upgraded to A' at the
> same time.  This works when upgrading A to A' (satisfying A'
> dependency and installing B), but does not work when installing
> B alone when A is installed.
>
> Only this way it is possible to work around old maintscripts
> in the renamed package.
>
> But I don't see a way to satisfy this.  Something I didn't think
> of ?

I see in the paragraph above you talk about Breaks. Do you also have
an according Replaces in place? See [1] and [2].

 [1]: http://wiki.debian.org/Renaming_a_Package
 [2]: http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6.1

Does this helps?

Regards,
Salvatore

[Michael Tokarev]

On 02.09.2012 21:21, Salvatore Bonaccorso wrote:
[]

>> Basically I want to ensure that if one installs package B to
>> a system with A installed, A should be upgraded to A' at the
>> same time.  This works when upgrading A to A' (satisfying A'
>> dependency and installing B), but does not work when installing
>> B alone when A is installed.
>>
>> Only this way it is possible to work around old maintscripts
>> in the renamed package.
>>
>> But I don't see a way to satisfy this.  Something I didn't think
>> of ?
>
> I see in the paragraph above you talk about Breaks. Do you also have
> an according Replaces in place? See [1] and [2].
>
>  [1]: http://wiki.debian.org/Renaming_a_Package
>  [2]: http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6.1
>
> Does this helps?

The current issue I have is #686146, the talk is about autofs5 => autofs
rename.  The OP of #686146 installed new autofs ("B" above), and his
system now have

   ii  autofs            5.0.6-2
   pc  autofs5           5.0.4-3.2+b1

Autofs is new package.  Its control info:

Package: autofs
Architecture: any
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}, ucf
Provides: autofs5
Breaks: autofs5 (<< 5.0.6-1~)
Replaces: autofs5 (<< 5.0.6-1~)

So it both replaces and breaks old autofs5.

But the OP system does not have old autofs5 package installed,
only the config files from it, and the maintscripts.  Which is
exactly the problem.

I want to ensure that if old autofs5 is installed, installing
new autofs should pull new autofs5 TOO.

The only way currently I see to do it is to declare autofs
as DEPENDING on autofs5.  This is obviously ugly, but it will
save from this very situation, and I don't see any other way.
Is there?

Thanks!

/mjt


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/5043B0DD.9080908@...

[Ben Hutchings-3]

On Sun, 2012-09-02 at 23:17 +0400, Michael Tokarev wrote:
[...]

> But the OP system does not have old autofs5 package installed,
> only the config files from it, and the maintscripts.  Which is
> exactly the problem.
>
> I want to ensure that if old autofs5 is installed, installing
> new autofs should pull new autofs5 TOO.
>
> The only way currently I see to do it is to declare autofs
> as DEPENDING on autofs5.  This is obviously ugly, but it will
> save from this very situation, and I don't see any other way.
> Is there?

# in autofs.postinst
rm -f /var/lib/dpkg/info/autofs5.postrm

(There may be a cleaner way to do this.)

Ben.

--
Ben Hutchings
Theory and practice are closer in theory than in practice.
                                - John Levine, moderator of comp.compilers

[Steve Langasek]

On Sun, Sep 02, 2012 at 08:54:39PM +0100, Ben Hutchings wrote:
> On Sun, 2012-09-02 at 23:17 +0400, Michael Tokarev wrote:
> [...]
> > But the OP system does not have old autofs5 package installed,
> > only the config files from it, and the maintscripts.  Which is
> > exactly the problem.

> > I want to ensure that if old autofs5 is installed, installing
> > new autofs should pull new autofs5 TOO.

> > The only way currently I see to do it is to declare autofs
> > as DEPENDING on autofs5.  This is obviously ugly, but it will
> > save from this very situation, and I don't see any other way.
> > Is there?

> # in autofs.postinst
> rm -f /var/lib/dpkg/info/autofs5.postrm

> (There may be a cleaner way to do this.)

if postrm=$(dpkg-query -c autofs5 postrm 2>/dev/null); then
        rm -f "$postrm"
fi

Not sure about cleaner, but that's the supported dpkg interface.

And yeah, short of time travel, I also don't see any cleaner alternative to
manually hacking the old maintainer scripts.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]

[Ben Hutchings-3]

On Sun, 2012-09-02 at 14:04 -0700, Steve Langasek wrote:

> On Sun, Sep 02, 2012 at 08:54:39PM +0100, Ben Hutchings wrote:
> > On Sun, 2012-09-02 at 23:17 +0400, Michael Tokarev wrote:
> > [...]
> > > But the OP system does not have old autofs5 package installed,
> > > only the config files from it, and the maintscripts.  Which is
> > > exactly the problem.
>
> > > I want to ensure that if old autofs5 is installed, installing
> > > new autofs should pull new autofs5 TOO.
>
> > > The only way currently I see to do it is to declare autofs
> > > as DEPENDING on autofs5.  This is obviously ugly, but it will
> > > save from this very situation, and I don't see any other way.
> > > Is there?
>
> > # in autofs.postinst
> > rm -f /var/lib/dpkg/info/autofs5.postrm
>
> > (There may be a cleaner way to do this.)
>
> if postrm=$(dpkg-query -c autofs5 postrm 2>/dev/null); then
> rm -f "$postrm"
> fi
>
> Not sure about cleaner, but that's the supported dpkg interface.

That certainly seems a bit cleaner than assuming we know what the dpkg
database looks like it.  However the manual page says 'Warning: this
command is deprecated, please switch to use --control-list and
--control-show instead.'  Those options don't expose any filenames at
all!

Ben.

> And yeah, short of time travel, I also don't see any cleaner alternative to
> manually hacking the old maintainer scripts.

--
Ben Hutchings
Theory and practice are closer in theory than in practice.
                                - John Levine, moderator of comp.compilers

[Steve Langasek]

On Sun, Sep 02, 2012 at 11:26:34PM +0100, Ben Hutchings wrote:
> > if postrm=$(dpkg-query -c autofs5 postrm 2>/dev/null); then
> > rm -f "$postrm"
> > fi

> > Not sure about cleaner, but that's the supported dpkg interface.

> That certainly seems a bit cleaner than assuming we know what the dpkg
> database looks like it.  However the manual page says 'Warning: this
> command is deprecated, please switch to use --control-list and
> --control-show instead.'  Those options don't expose any filenames at
> all!

Hmm.  Perhaps the manpage needs updating, then; I'm sure this is the
interface that's being recommended for coping with multiarch-related changes
to control file paths.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]

[Bob Proulx]

Steve Langasek wrote:

> Ben Hutchings wrote:
> > # in autofs.postinst
> > rm -f /var/lib/dpkg/info/autofs5.postrm
> > (There may be a cleaner way to do this.)
>
> if postrm=$(dpkg-query -c autofs5 postrm 2>/dev/null); then
> rm -f "$postrm"
> fi
>
> Not sure about cleaner, but that's the supported dpkg interface.

If the "/var/lib/dpkg/info" path is guaranteed not to have any spaces
in it then the first way, the simple rm -f, seems better by way of
being faster.  Because it would avoid the query.  Queries such as
those can take up a lot of cpu and it all adds up.  I hate spending a
lot of time waiting for the machine to spin its wheels unnecessarily.

And in the end does it matter what the answer is if it is going to be
a removal anyway?  It seems to me that it would be enough faster to
just always run the 'rm -f' since it avoids the query.  Since I don't
think that will ever produce a bad result.  (Is there ever a bad
result case?)

Of course if there is a plan to move the /var/lib/dpkg/info path
elsewhere then the path should be obtained dynamically and properly
quoted.  But is that ever really a potential possibility?

Bob

[Michael Tokarev]

On 02.09.2012 23:54, Ben Hutchings wrote:

> On Sun, 2012-09-02 at 23:17 +0400, Michael Tokarev wrote:
> [...]
>> But the OP system does not have old autofs5 package installed,
>> only the config files from it, and the maintscripts.  Which is
>> exactly the problem.
>>
>> I want to ensure that if old autofs5 is installed, installing
>> new autofs should pull new autofs5 TOO.
>>
>> The only way currently I see to do it is to declare autofs
>> as DEPENDING on autofs5.  This is obviously ugly, but it will
>> save from this very situation, and I don't see any other way.
>> Is there?
>
> # in autofs.postinst
> rm -f /var/lib/dpkg/info/autofs5.postrm

I thought about this too (was an alternative to depends), but it
looked somehow too ugly for me to mess with "other package"
maintscripts.  But now when I think about it, this seems to be
the most correct solution now.

> (There may be a cleaner way to do this.)

Steve's version looks a bit more correct - after all it is
possible to tell dpkg to use alternative file locations.

Thank you for the suggestion!

/mjt


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/50443922.1080002@...

[Raphael Hertzog-3]

Hi,

On Sun, 02 Sep 2012, Steve Langasek wrote:
> > That certainly seems a bit cleaner than assuming we know what the dpkg
> > database looks like it.  However the manual page says 'Warning: this
> > command is deprecated, please switch to use --control-list and
> > --control-show instead.'  Those options don't expose any filenames at
> > all!
>
> Hmm.  Perhaps the manpage needs updating, then; I'm sure this is the
> interface that's being recommended for coping with multiarch-related changes
> to control file paths.

The manual page is correct. That's because we want to keep the possibility
of not using a plain file storage for the control metadata that comes with
Debian packages.

Those changes have been made in particular to prepare for the case of
bundling changelogs/copyright files where we might want to store files
more efficiently (deduplicated, compressed, etc.).

In practice, the --control-path interface will likely stay around for
a good while, in particular for the subset of metadata that uses plain
file storage. But when --control-show is enough, you should certainly
use that instead.

On Sun, 02 Sep 2012, Bob Proulx wrote:
> Of course if there is a plan to move the /var/lib/dpkg/info path
> elsewhere then the path should be obtained dynamically and properly
> quoted.  But is that ever really a potential possibility?

Yes, that's the whole purpose of this interface. Give some flexibility
to dpkg so that it can handle metadata more efficiently.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120903064534.GA32666@...

[Guillem Jover]

On Sun, 2012-09-02 at 15:41:48 -0700, Steve Langasek wrote:

> On Sun, Sep 02, 2012 at 11:26:34PM +0100, Ben Hutchings wrote:
> > > Not sure about cleaner, but that's the supported dpkg interface.
>
> > That certainly seems a bit cleaner than assuming we know what the dpkg
> > database looks like it.  However the manual page says 'Warning: this
> > command is deprecated, please switch to use --control-list and
> > --control-show instead.'  Those options don't expose any filenames at
> > all!
>
> Hmm.  Perhaps the manpage needs updating, then; I'm sure this is the
> interface that's being recommended for coping with multiarch-related
> changes to control file paths.

Only because there's been no better interface at that point (as was even
mentioned on older dpkg-query man pages, exposing the db paths was never
really a good interface, because among others it was susceptible to race
conditions between concurrent dpkg and dpkg-query runs while changing db
layout, or it could give people funny ideas about programatically
modifying or removing such paths contents, etc).

But then --control-path was intended only for read accesses for things
like dpkg-repack or dpkg-reconfigure, never for *removing* files from
the dpkg database. Removing such files from maintainer scripts is just
*wrong*, the correct solution is to force an upgrade to a transitional
package that does not contain conffiles/maintscripts.

This option is going to go away relatively soon (in deprecation time
terms); for 1.17.x I'm planning to make it issue warnings, something I
didn't do for 1.16.x because the new interfaces were introduced pretty
late in the release cycle and as such only available pretty recently,
would have involved an annoying “transition”, and I didn't consider it
fair at that point. I was planning on removing it on 1.18.x, but it
might probably have to wait until 1.19.x.

regards,
guillem


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20120903081500.GA31680@...

[Michael Tokarev]

On 03.09.2012 12:15, Guillem Jover wrote:
[]
> But then --control-path was intended only for read accesses for things
> like dpkg-repack or dpkg-reconfigure, never for *removing* files from
> the dpkg database. Removing such files from maintainer scripts is just
> *wrong*, the correct solution is to force an upgrade to a transitional
> package that does not contain conffiles/maintscripts.

The only question remains is how to force this upgrade.  Yes that's the
nice thing to do, but I don't have other ideas but to _depend_ on this
transitional package.

> This option is going to go away relatively soon (in deprecation time
> terms); for 1.17.x I'm planning to make it issue warnings, something I
> didn't do for 1.16.x because the new interfaces were introduced pretty

A warning sent to /dev/null.  Oh well.

> late in the release cycle and as such only available pretty recently,
> would have involved an annoying “transition”, and I didn't consider it
> fair at that point. I was planning on removing it on 1.18.x, but it
> might probably have to wait until 1.19.x.

Since I implemented this dpkg-query usage for autofs for now, since
for _now_ it is the only workable solution, and we only support upgrades
to next release, I'll remove this whole thing for jessie.  Does it make
sense?

Thanks,

/mjt


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/504469D8.10905@...

[Russ Allbery-2]

Michael Tokarev <[hidden email]> writes:
> On 03.09.2012 12:15, Guillem Jover wrote:

>> But then --control-path was intended only for read accesses for things
>> like dpkg-repack or dpkg-reconfigure, never for *removing* files from
>> the dpkg database. Removing such files from maintainer scripts is just
>> *wrong*, the correct solution is to force an upgrade to a transitional
>> package that does not contain conffiles/maintscripts.

> The only question remains is how to force this upgrade.  Yes that's the
> nice thing to do, but I don't have other ideas but to _depend_ on this
> transitional package.

I think that's pretty much what you'd need to do.  Hm, and doing that
without creating a circular dependency is rather annoying.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/871uijc6os.fsf@...