Re: RC bug for 10 packages
On Sat, Oct 25, 2008 at 06:37:23PM +0200, Francis Tyers wrote: 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. So if you were to recompile apertium after installing a different version of libpcre3, would it become incompatible with the previously built language packages? Just curious. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RC bug for 10 packages
* Francis Tyers [Sat, 25 Oct 2008 18:25:47 +0200]: Yep, this is the case, it includes pre-compiled regular expressions and these appear to be incompatible between versions of pcre. Ok. [...snip...] then set a Depend in the language packages to that particular version of apertium, then recompile and upload the packages. The option that sounds more realistic, at least for now, is having the language packages Depend: libpcre3 ( next_upstream_version), or something along the lines. We've come up with a better solution, which is to add dependencies to the apertium package, and then make the apertium package depend on a particular version of pcre3. It's safer this way, as I can't find out anything about compatibility of precompiled regular expressions in pcre between versions, so better to assume they aren't. Add what dependencies to the apertium package? Can you be specific? -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org - Why are you whispering? - Because I just think that no matter where she is, my mom can hear this conversation. -- Rory and Lane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RC bug for 10 packages
El vie, 24-10-2008 a las 00:06 +0200, Adeodato Simó escribió: * Francis Tyers [Thu, 23 Oct 2008 22:47:20 +0200]: Hi, Hello, Francis. The bug is that the language packages require a specific version of libpcre to function. Could you explain a bit the technical background for this? Do the data files in the language packages embed any data that is pcre-related, and that makes that later on apertium can't open them if it uses an incompatible version of pcre? Yep, this is the case, it includes pre-compiled regular expressions and these appear to be incompatible between versions of pcre. [...snip...] then set a Depend in the language packages to that particular version of apertium, then recompile and upload the packages. The option that sounds more realistic, at least for now, is having the language packages Depend: libpcre3 ( next_upstream_version), or something along the lines. We've come up with a better solution, which is to add dependencies to the apertium package, and then make the apertium package depend on a particular version of pcre3. It's safer this way, as I can't find out anything about compatibility of precompiled regular expressions in pcre between versions, so better to assume they aren't. Regards, Fran -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RC bug for 10 packages
El sáb, 25-10-2008 a las 18:32 +0200, Adeodato Simó escribió: * Francis Tyers [Sat, 25 Oct 2008 18:25:47 +0200]: Yep, this is the case, it includes pre-compiled regular expressions and these appear to be incompatible between versions of pcre. Ok. [...snip...] then set a Depend in the language packages to that particular version of apertium, then recompile and upload the packages. The option that sounds more realistic, at least for now, is having the language packages Depend: libpcre3 ( next_upstream_version), or something along the lines. We've come up with a better solution, which is to add dependencies to the apertium package, and then make the apertium package depend on a particular version of pcre3. It's safer this way, as I can't find out anything about compatibility of precompiled regular expressions in pcre between versions, so better to assume they aren't. Add what dependencies to the apertium package? Can you be specific? 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RC bug for 10 packages
El sáb, 25-10-2008 a las 18:32 +0200, Adeodato Simó escribió: * Francis Tyers [Sat, 25 Oct 2008 18:25:47 +0200]: Yep, this is the case, it includes pre-compiled regular expressions and these appear to be incompatible between versions of pcre. Ok. [...snip...] then set a Depend in the language packages to that particular version of apertium, then recompile and upload the packages. The option that sounds more realistic, at least for now, is having the language packages Depend: libpcre3 ( next_upstream_version), or something along the lines. We've come up with a better solution, which is to add dependencies to the apertium package, and then make the apertium package depend on a particular version of pcre3. It's safer this way, as I can't find out anything about compatibility of precompiled regular expressions in pcre between versions, so better to assume they aren't. Add what dependencies to the apertium package? Can you be specific? 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 Fran -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RC bug for 10 packages
* Adeodato Simó [Sat, 25 Oct 2008 18:57:55 +0200]:
Package: apertium
Provides: apertium-pcre-1
And then, each time you detect a new incompatible version of pcre, you
make apertium Provide: apertium-pcre-2.
This is of course fragile, so you may want to go for:
Package: apertium
Depends: ${shlib:Depends}, libpcre3 ( 7.X+1)
Provides: apertium-pcre-1
And then apertium needs an extra upload for each new 7.X version of
pcre, after checking whether or not it breaks compatibility.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Madeleine Peyroux - Reckless blues
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RC bug for 10 packages
On Sat, Oct 25, 2008 at 06:25:47PM +0200, Francis Tyers wrote: We've come up with a better solution, which is to add dependencies to the apertium package, and then make the apertium package depend on a particular version of pcre3. It's safer this way, as I can't find out anything about compatibility of precompiled regular expressions in pcre between versions, so better to assume they aren't. Your assumption is correct, from man pcreprecompile: If you save compiled patterns to a file, you can copy them to a different host and run them there. This works even if the new host has the opposite endianness to the one on which the patterns were compiled. There may be a small performance penalty, but it should be insignificant. However, compiling regular expressions with one version of PCRE for use with a different version is not guaranteed to work and may cause crashes. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RC bug for 10 packages
* Francis Tyers [Thu, 23 Oct 2008 22:47:20 +0200]: Hi, Hello, Francis. The bug is that the language packages require a specific version of libpcre to function. Could you explain a bit the technical background for this? Do the data files in the language packages embed any data that is pcre-related, and that makes that later on apertium can't open them if it uses an incompatible version of pcre? I'm asking because knowing the details is going to be better in order for people to be able It has worked up until now with various versions, but moving from 7.4 to 7.6 breaks the packages with: Error: Unknown error matching regexp (code -16) With respect the above, it would be good to find out if pcre is making any promises of keeping compatibility when opening files that contain data generated by it (or whatever apertium is doing), and then this is a bug, or it doesn't, and then the problem does indeed need addressing. The fix will be to set a Depend in the apertium package to a particular version of libpcre3, Note that binary packages get their dependencies via the shlibs mechanism, and not hard-coded... then set a Depend in the language packages to that particular version of apertium, then recompile and upload the packages. The option that sounds more realistic, at least for now, is having the language packages Depend: libpcre3 ( next_upstream_version), or something along the lines. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Andrés Calamaro - Paloma -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
