Ticket #729 (closed defect: fixed)

Opened 11 years ago

Last modified 9 years ago

from uses alternatives now

Reported by: geofft Owned by: jdreed
Priority: normal Milestone: Natty Alpha
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

As of Maverick or something, from uses /etc/alternatives instead of just being a program in /usr/bin. So we should be participating with the alternatives system instead of diverting /usr/bin/from.

I don't really know how to tell if a certain program is participating in the alternatives system, though.... Install something else that provides it and see what it does?

Change History

comment:1 in reply to: ↑ description Changed 11 years ago by jdreed

Replying to geofft:

I don't really know how to tell if a certain program is participating in the alternatives system

Is this harder than if update-alteratives --list foo; then ?

comment:2 Changed 11 years ago by jdreed

  • Status changed from new to committed

According to the Debian changelog, this happened in version 8.0.6 of bsdmainutils. I have a fix in r25025 and r25026 that will decide whether to divert based on the version of bsdmainutils installed. I'd really like someone to double-check the code.

comment:3 Changed 11 years ago by andersk

Several issues:

In order to support upgrades from versions that divert the file to versions that register alternatives, you need to undivert the file, and you need to make sure to register the alternative _after_ the undiversion.

The test you added in the postinst is a run-time test, and so it may give the wrong answer for multiple reasons. If bsdmainutils isn’t installed yet, the package won’t register an alternative even if it should. If a backported bsdmainutils is installed, the package will register an alternative even if it already diverted /usr/bin/from. You need to use the build-time test, and either generate the postinst file during the build or generate a postinst.debhelper snippet at the right time; also Conflict the inappropriate versions of bsdmainutils.

grep -q /usr/bin/from\.debathena is underquoted and underanchored (so it matches WHATEVER/usr/bin/fromQdebathenaWHATEVER). Write grep -Fqx '/usr/bin/from.debathena'.

comment:4 Changed 11 years ago by jdreed

  • Owner set to jdreed
  • Status changed from committed to accepted

So, in rules, I moved DEB_DIVERT_EXTENSION outside the conditional, and added this in an else clause

    DEB_UNDIVERT_VERSION_/usr/sbin/from.debathena = 1.5~
    DEB_UNDIVERT_VERSION_/usr/share/man/man1/from.debathena.1.gz = 1.5~
    DEB_UNDIVERT_FILES_debathena-from-config += \
        /usr/bin/from.debathena \
        /usr/share/man/man1/from.debathena.1.gz

That should handle the undiversions, right? For the postinst snippet, if I generate it in debian-divert/debathena-from-config::, will that happen after the undiversions?

And for generating conflicts, is the right way to do it using Conflicts: ${debathena-from-config-conflicts} in control.in, and then in the conditional in rules, do

debathena-from-config-substvars: 
     echo "debathena-from-config-conflicts=bsdmainutils (< 8.0.6~)" >> debian/debathena-from-config.substvars

comment:5 Changed 11 years ago by jdreed

  • Status changed from accepted to committed

OK, re-committed in r25027. I'd appreciate another review. I add a Conflicts with substvars (in binary-predeb).

The one thing I was unclear on was generating the postinst at the right time so it happens after the undiversions. I looked at how pam-config did it, but that didn't quite make sense to me, so I write out the postinst in common-build-indep with the #DEBHELPER# tag at the beginning of the file. I also fixed the conditional in rules, which was inverted.

comment:6 Changed 11 years ago by jdreed

re-re-committed in r25028 after Evan brought #549 to my attention.

comment:7 Changed 11 years ago by jdreed

  • Status changed from committed to development

In -development and tested.

comment:8 Changed 10 years ago by geofft

  • Status changed from development to proposed

This whole thing is a mess, but I think it's handled as well as it can be given what we have to deal with, so the code looks fine to me. I've moved it into proposed and will test a bit...

comment:9 Changed 10 years ago by jdreed

  • Status changed from proposed to closed
  • Resolution set to fixed

comment:10 Changed 9 years ago by geofft

I got an OMINOUS WARNING on zulu, so I'm not convinced we did the transition right

Note: See TracTickets for help on using tickets.