Re: RC bug for >10 packages
* Francis Tyers [Sat, 25 Oct 2008 18:37:23 +0200]:
Hi again,
> Heh, actually there is an ambiguity there... I should have spotted it.
> What I mean is:
> Add the specific dependence in each language package to apertium and not
> to libpcre3. The language packages already depend on apertium, but we'll
> just make this specific with substvar, the patch by Miguel probably
> explains it better.
> http://www.nopaste.com/p/at2o7jJNz
Oh, I see. Automating it with a substvar is nice, but I don't think this
solution is particular is good...
Let me explain: with this proposed solution, the data packages are going
to gain a dependency like:
Depends: apertium (= 3.0.7+1-2)
Which means that, whenever you re-upload apertium, all the 14 data
packages are going to become uninstallable! And since they are arch:all
they are going to be uploaded by hand. (Plus they'd need to migrate
together to testing on every minor revision, which is not good either.)
What is normally done in these cases is to introuce something akin to
SONAMEs, via virtual packages. I'll explain concisely:
Package: apertium
Provides: apertium-pcre-1
Package: apertium-fr-es
Depends: apertium (>= 3.0.1), apertium-pcre-1
And then, each time you detect a new incompatible version of pcre, you
make apertium Provide: apertium-pcre-2. With that, data packages won't
be upgraded on the system until they are rebuilt, and changed to Depend
on apertium-pcre-2. But while there are no incompatible bumps on pcre,
the main and data packages are decoupled, which is the point.
(The dependency on apertium-pcre-X on the data packages can be either
hard-coded by hand in debian/control, or filled in with a substvar; this
is just an implementation detail. If they were arch:any packages, I
would insist on the substvar, so that they could be just binNMUed. But
since they are not, you get to choose.)
HTH,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Madeleine Peyroux - Hey sweet man
Reply to: