Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr
Maarten van Gompel
proycon at anaproy.nl
Mon Jan 23 10:10:18 UTC 2017
Hi Andreas,
Thanks for your elaborate response! It seems this has indeed opened quite a can
of worms.. Here we go:
Quoting Andreas Beckmann (2017-01-22 22:27:08)
> TL;DR: You have an ambitious task before you.
So I see...
> Let me see if I understand what's going on.
>
> Renaming conffiles and changing the owning package at the same time is a
> PITA.
> You add an extra point by making the old name a symlink to the new one,
> owned by the new package
>
> In jessie, everything in /etc/ucto was owned by ucto.
> In sid, a lot more stuff is in /etc/ucto, and either owned by uctodata
> or libucto2, a m-a:same library package. These come from 2 different
> source packages.
Indeed..
> Yuck. While putting conffiles in m-a:same packages is allowed, I highly
> discourage this. Even if I haven't seen this fail once, yet. I'm just
> afraid, someone has to clean up a mess caused by this at some point in
> the future. and I'm afraid, I won't keep my fingers out of then :-(
Ok, we'll come back to this in your later suggestion to move the conffiles to a
new package.
> Before we start: Are these really conffiles? Supposed to be modified by
> the local admin? Or are these rather data files that are not supposed to
> be updated locally? And would better live in /usr/share in that case?
You have a point there; the user MAY add a new configuration or modify an
existing one, but it is indeed not something that NEEDS to be modified to run. You may be right that
/usr/share might be better here. I'd have to discuss with the main upstream
developer, but I think we're not opposed to such 'radical' solutions if that
solves the packaging problems and makes more semantic sense anyway.
What do you think is best for the short term to get this fixed before the
freeze?
> And nearly everything from jessie's /etc/ucto content is now renamed and
> a symlink.
> Can't you just fork the project? I'd suggest 'hpgb' and then use
> /etc/hpgb for the conffiles. Oh, I forgot: we are in freeze, so no new
> source packages ...
>
> Oh yeah, it well be a mess. But we will do it right. Including making
> dpkg forget about the old conffiles.
>
> Right now, all upgrade attempts from jessie to stretch should always
> have failed, so there is no further messed up state inbetween that
> should be supported for clean upgrades.
Right
> can we move the conffiles from libucto2 to a new package, e.g.
> ucto-common (which would be either m-a:foreign or m-a:allowed, but I
> always mess up these two, I need to look up what's right?
Okay, that sounds good to me, if there's no objection to having yet another
package.
> * Which version introduced the new layout?
> * can you give me a list of
> + removed conffiles
> + renamed conffiles (old name, new name, new owning package, whether
> they have a compat symlink, did the content change between jessie and sid)
ucto 0.9.2 introduced the split into uctodata. The jessie version is very old: 0.5.3-3.1
The following files moved out of ucto 0.9.2 (libucto2) into the new uctodata package:
config/es.abr
config/exotic-eos.eos
config/exotic-quotes.quote
config/ligatures.filter
config/nl_afk.abr
config/pt.abr (not in jessie version)
config/tokconfig-de
config/tokconfig-en
config/tokconfig-es
config/tokconfig-fr
config/tokconfig-fy
config/tokconfig-it
config/tokconfig-nl
config/tokconfig-nl-sonarchat
config/tokconfig-nl-twitter
config/tokconfig-nl-withplaceholder (not in jessie version)
config/tokconfig-pt (not in jessie version)
config/tokconfig-ru (not in jessie version)
config/tokconfig-sv
config/tokconfig-tr (not in jessie version)
The following remained in ucto 0.9.2 (libucto2)
config/e-mail.rule
config/smiley.rule
config/url.rule
config/standard-eos.eos (not in jessie version)
config/standard-quotes.quote (not in jessie version)
config/tokconfig-generic (not in jessie version)
The very latest uctodata 0.3.1-1 introduces the new naming scheme for the language
codes:
config/tokconfig-de -> config/tokconfig-deu
config/tokconfig-en -> config/tokconfig-eng
config/tokconfig-es -> config/tokconfig-spa
config/tokconfig-fr -> config/tokconfig-fra
config/tokconfig-fy -> config/tokconfig-fry
config/tokconfig-it -> config/tokconfig-ita
config/tokconfig-nl -> config/tokconfig-nld
config/tokconfig-nl-sonarchat -> config/tokconfig-nld-sonarchat
config/tokconfig-nl-twitter -> config/tokconfig-nld-twitter
config/tokconfig-nl-withplaceholder (not in jessie version) -> config/tokconfig-nld-withplaceholder
config/tokconfig-pt (not in jessie version) -> config/tokconfig-por
config/tokconfig-ru (not in jessie version) -> config/tokconfig-rus
config/tokconfig-tr (not in jessie version) -> config/tokconfig-tur
config/tokconfig-sv -> config/tokconfig-swe
At that point we decided to symlink from the old two-letter versions to the
new three-letter versions, for backward compatibility "to make things easy"..
but apparantly this didn't play out as anticipated :)
> Do you *really* need the compat symlinks?
No, it's just a courtesy for the user that we don't mind dropping at all if it
complicates matters like this.
> OK, packaging is in git. Need to check whether I have write permissions
> there ...
>
> rough plan:
>
> ucto uses d-m-h move-conffile (but provides no new version, so the old
> conffile should "disappear" and dpkg should forget about it.
> Maybe it's better to rm_conffile it instead.
Okay, I'll read up on all that today then because I have to prior experience with those.
> uctodata will probably need a Conflicts against ucto (<< current+fixed~)
Right,
Thanks for your help!
--
Maarten van Gompel
Centre for Language Studies
Radboud Universiteit Nijmegen
proycon at anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon
GnuPG key: 0x1A31555C
XMPP: proycon at anaproy.nl Matrix: @proycon:anaproy.nl
Telegram: proycon IRC: proycon (freenode)
Twitter: https://twitter.com/proycon
ORCIRD: https://orcid.org/0000-0002-1046-0006
Bitcoin: 1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
More information about the debian-science-maintainers
mailing list