[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal v2: enable stateless persistant network interface names



Le 03/06/2015 12:59, Marco d'Itri a écrit :
> On Jun 03, Vincent Danjean <vdanjean.ml@free.fr> wrote:
> 
>>>  stretch+1 (or maybe +2):
>>>   - Check existance/non-emptiness of
>>>     /etc/udev/rules.d/70-persistent-net.rules in udev.preinst,
>>>     Show critical debconf note, and refuse to upgrade
>> No. It is always a real pain when a preinst script fails.
> This part is not negotiable, because:

All is negotiable. It is a matter of what is less problematics.

>> So, you can show a debconf note, try (or not) to migrate the file
>> automatically, remove (or comment-out) the 70-persistent-net.rules,
>> or ... but, please, do not write a preinst script that fails
>> because the admin did not update its config before upgrading.
> None of these solutions is applicable: either the upgrade can continue 
> or the network interfaces names will change with unpredictable 
> consequences.

I would *largely* prefer a debconf notice + question asked to
retry (admin can fix in-between) or continue (admin will have to
leave with consequence of interface rename) than having a
dist-upgrade aborted in the middle of its way.
  I remember upgrades aborted due to dependencies between udev
and the running kernel. It was really a mess when I forgot to
upgrade the kernel at first (until, if I remember correctly,
the abort was modified to big debconf warnings).

>> One "good" solution would probably a new kind of scripts run
>> by dpkg and apt *prior to any other things* (for all involved
>> packages) to decide if the upgrade can run or not. But that
> This is more or less what apt does when apt-extracttemplates from 
> apt-utils is available.

You would have to ensure that the apt hook is available *before*
dist-upgrade is run. To my knowledge, no dependency can ensure this.
So, this hook would have to be imposed in strech so that strech+1
can use it. Anyway, I will be very pleased if you find a way to
abort the upgrade before its begining (and not just before udev
upgrade)

  Regards,
    Vincent

-- 
Vincent Danjean       GPG key ID 0xD17897FA         vdanjean@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


Reply to: