Re: Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr
Hi Andreas et al,
Short follow up: we discussed it internally and think it's indeed best to just
move the 'configuration' files to /usr/share, as you pointed out; simplifying the package and
resolving the conflicts.
We're currently working on new upstream releases for
ucto, uctodata, frogdata, and frog (the latter two have the same division and
make the same mistake, and depends on ucto/uctodata too) that implement this. I
hope releasing four new packages so close to the freeze is not going to be a
problem. At least it should fix this bug for good.
Regards,
--
Maarten van Gompel
Centre for Language Studies
Radboud Universiteit Nijmegen
proycon@anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon
GnuPG key: 0x1A31555C
XMPP: proycon@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
Quoting Maarten van Gompel (2017-01-23 11:10:18)
> 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@anaproy.nl
> https://proycon.anaproy.nl
> https://github.com/proycon
>
> GnuPG key: 0x1A31555C
> XMPP: proycon@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
>
Maarten van Gompel (Proycon)
E-mail: proycon@anaproy.nl
Instant Messenger: proycon@anaproy.nl (XMPP)
proycon (telegram)
proycon (IRC freenode)
@proycon:anaproy.nl (matrix)
Homepage: http://proycon.anaproy.nl
Twitter: https://twitter.com/proycon
Github: https://github.com/proycon
GnuPG Key: 0x1A31555C
Bitcoin: 1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Reply to: