[opensuse-packaging] Re: commit jpeg8 for openSUSE:Factory
Hello community, Just saw this commit on the ml and thought I wanted to raise an issue/question with this one (there are others doing the same) It's also not this commit introducing it, just that I happen to see it here... again... and I have time now :)
-%package -n libjpeg8-devel +%package -n libjpeg%{major}-devel
Wasn't there once the agreement that the -devel package does not follow the sonum bumps? so sonum in the packagename for libs is only interesting because it allows us to install the libs in parallel, something which the -devel package here intentionally 'denies' us from doing using Conflicts: anyhow. Why not just go and call it libjpeg-devel, which would also be more straight forward for packagers, relying on it. I think it's useless to update all spec files just becuase jpeg (or any other lib for that matter) bumps it soname and becomes ABI incompatible.. as long as they are API compat, a rebuild is all it takes. Habing '8' in this case in the packagename for the devel will force us to go and replace all BuildRequires: libjpeg8-devel with libjpeg9-devel. This is actually also noted down like this in our packaging guidelines, see: http://en.opensuse.org/openSUSE:Shared_library_packaging_policy#Package_Name Best regards, Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2011/4/14 Dimstar / Dominique Leuenberger <dimstar@opensuse.org>:
Hello community,
Just saw this commit on the ml and thought I wanted to raise an issue/question with this one (there are others doing the same)
It's also not this commit introducing it, just that I happen to see it here... again... and I have time now :)
-%package -n libjpeg8-devel +%package -n libjpeg%{major}-devel
Wasn't there once the agreement that the -devel package does not follow the sonum bumps? so sonum in the packagename for libs is only interesting because it allows us to install the libs in parallel, something which the -devel package here intentionally 'denies' us from doing using Conflicts: anyhow.
Why not just go and call it libjpeg-devel, which would also be more straight forward for packagers, relying on it.
I think it's useless to update all spec files just becuase jpeg (or any other lib for that matter) bumps it soname and becomes ABI incompatible.. as long as they are API compat, a rebuild is all it takes. Habing '8' in this case in the packagename for the devel will force us to go and replace all BuildRequires: libjpeg8-devel with libjpeg9-devel.
This is actually also noted down like this in our packaging guidelines, see: http://en.opensuse.org/openSUSE:Shared_library_packaging_policy#Package_Name
If there is a need to have both devel packages at the same time the soname in the -devel package makes sense. See http://lists.opensuse.org/opensuse-factory/2010-11/msg00013.html and http://lists.opensuse.org/opensuse-packaging/2010-12/msg00024.html -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 14/04/11 14:52, Dimstar / Dominique Leuenberger wrote:
Wasn't there once the agreement that the -devel package does not follow the sonum bumps? so sonum in the packagename for libs is only interesting because it allows us to install the libs in parallel, something which the -devel package here intentionally 'denies' us from doing using Conflicts: anyhow.
Yep, we should remove libjpeg8 from the distro completely and turn libjpeg62-devel into libjpeg-devel. -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
* Pavol Rusnak (prusnak@opensuse.org) [20110414 15:35]:
Yep, we should remove libjpeg8 from the distro completely and turn libjpeg62-devel into libjpeg-devel.
Why should we do that? ncurses also supports differing devel packages. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, 2011-04-14 at 16:39 +0200, Philipp Thomas wrote:
* Pavol Rusnak (prusnak@opensuse.org) [20110414 15:35]:
Yep, we should remove libjpeg8 from the distro completely and turn libjpeg62-devel into libjpeg-devel.
Why should we do that? ncurses also supports differing devel packages.
Does not seem so in Factory: 3120-3560:~ # zypper se -s *ncurses*devel Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository --+---------------------+---------+------------+--------+----------------- | ncurses-devel | package | 5.8-2.1 | x86_64 |Factory | ncurses-devel | package | 5.8-2.1 | i586 |Factory | yast2-ncurses-devel | package | 2.21.0-2.1 | x86_64 |Factory | yast2-ncurses-devel | package | 2.21.0-2.1 | i586 |Factory But that might not be what you meant? If it was about finding the different -devel packages to install, then yes: for a user not a huge issue. but for packagers can certainly become a burden (especially also when making a package build cross-distroversions). Have a look at this scheme: (fictive.. just to show the problem we can run into): 11.2 ships libfoo2 and thus libfoo2-devel (version 1.2.0) 11.3 ships libfoo3 and thus libfoo3-devel (version 1.3.0) 11.4 ships libfoo4 and thus libfoo4-devel (version 1.4.0) Let's just assume the library is nicely written and all the devs are doing is properly extending their API, guaranteeing backwards compatibility. So for my app, written it does not matter which one I use (assuming I require libfoo v 1.2.0... which my configure script checks for). (i'm sure you can bridge from libfoo4 to libjpeg8) now for the package, he has to go and if the various versions, to find the right BuildRequires. As per our guideline, the package should be called libfoo-devel which makes absolutely sense... (yes, new pkgconfig() - style buildRequires are a blast here! Just love them, especially when we thing cross - distro!) THIS example is what we're trying to address.. the end user might just be in a pain to find it.. the packagers are in a pain in maintaining there apps. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
* Dimstar / Dominique Leuenberger (dimstar@opensuse.org) [20110414 16:53]:
Does not seem so in Factory:
You're right. I meant libpng where we have libpng12-devel and libpng14-devel. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 04/14/2011 04:39 PM, Philipp Thomas wrote:
* Pavol Rusnak (prusnak@opensuse.org) [20110414 15:35]:
Yep, we should remove libjpeg8 from the distro completely and turn libjpeg62-devel into libjpeg-devel.
Why should we do that? ncurses also supports differing devel packages.
We switched to libjpeg8, fixing most of the packages to the new API while the rest of the world stayed at libjpeg6 and later switched to turbo implementation of it (libjpegturbo provides libjpeg6 API). Then we realized we don't want to be different so we introduced libjpegturbo as well. However, most of our packages were patched to build against libjpeg8, so we needed to indicate which API we want the package to use. That's why we had libjpeg8-devel and libjpeg62-devel. Now that no package uses libjpeg8 (at least on my 11.4 system), I think we can get rid of libjpeg8 completely and rename libjpeg62-devel to libjpeg-devel.
Philipp
-- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 04/14/2011 05:50 PM, Pavol Rusnak wrote:
On 04/14/2011 04:39 PM, Philipp Thomas wrote:
* Pavol Rusnak (prusnak@opensuse.org) [20110414 15:35]:
Yep, we should remove libjpeg8 from the distro completely and turn libjpeg62-devel into libjpeg-devel.
Why should we do that? ncurses also supports differing devel packages.
We switched to libjpeg8, fixing most of the packages to the new API while the rest of the world stayed at libjpeg6 and later switched to turbo implementation of it (libjpegturbo provides libjpeg6 API). Then we realized we don't want to be different so we introduced libjpegturbo as well. However, most of our packages were patched to build against libjpeg8, so we needed to indicate which API we want the package to use. That's why we had libjpeg8-devel and libjpeg62-devel. Now that no package uses libjpeg8 (at least on my 11.4 system), I think we can get rid of libjpeg8 completely and rename libjpeg62-devel to libjpeg-devel.
Philipp
libjpeg62-devel in >= 11.4 already provides libjpeg-devel so that would be perfect and need no changes in packages that BuildRequires: libjpeg-devel. I was using libjpeg62 on my 11.3 system since it was introduced. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 04/14/2011 05:50 PM, Pavol Rusnak wrote:
On 04/14/2011 04:39 PM, Philipp Thomas wrote:
* Pavol Rusnak (prusnak@opensuse.org) [20110414 15:35]:
Yep, we should remove libjpeg8 from the distro completely and turn libjpeg62-devel into libjpeg-devel.
Why should we do that? ncurses also supports differing devel packages.
We switched to libjpeg8, fixing most of the packages to the new API while the rest of the world stayed at libjpeg6 and later switched to turbo implementation of it (libjpegturbo provides libjpeg6 API). Then we realized we don't want to be different so we introduced libjpegturbo as well. However, most of our packages were patched to build against libjpeg8, so we needed to indicate which API we want the package to use. That's why we had libjpeg8-devel and libjpeg62-devel. Now that no package uses libjpeg8 (at least on my 11.4 system), I think we can get rid of libjpeg8 completely and rename libjpeg62-devel to libjpeg-devel.
Philipp
libjpeg62-devel in >= 11.4 already provides libjpeg-devel so that would be perfect and need no changes in packages that BuildRequires: libjpeg-devel. I was using libjpeg62 on my 11.3 system since it was introduced. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Pavol Rusnak wrote:
Now that no package uses libjpeg8 (at least on my 11.4 system), I think we can get rid of libjpeg8 completely and rename libjpeg62-devel to libjpeg-devel.
I know of at least one program (ioquake3) that does make use of the new libjpeg8 interfaces and will not work with libjpeg62. Was there any progress in using symbol versioning for libjpeg8 so a program like ioquake3 could use libjpeg8 without clashing with other system libs? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2011/4/15 Ludwig Nussel <ludwig.nussel@suse.de>:
Pavol Rusnak wrote:
Now that no package uses libjpeg8 (at least on my 11.4 system), I think we can get rid of libjpeg8 completely and rename libjpeg62-devel to libjpeg-devel.
I know of at least one program (ioquake3) that does make use of the new libjpeg8 interfaces and will not work with libjpeg62. Was there any progress in using symbol versioning for libjpeg8 so a program like ioquake3 could use libjpeg8 without clashing with other system libs?
I can't check right now. But IIRC libjpeg8 had symbol versioning from the start (and an update for libjpeg62 was released to also add it) thanks to Debian people. And I asked jpeg-turbo devs to also add the symbol versioning in the ".62" soname and they agreed, so it should be already available (I *suppose* there has been a new release). Still, what's wrong with keeping libjpeg8-devel in case someone wants to use it (even if we are not going to)? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2011/4/15 Cristian Morales Vega <cmorve69@yahoo.es>:
2011/4/15 Ludwig Nussel <ludwig.nussel@suse.de>:
Pavol Rusnak wrote:
Now that no package uses libjpeg8 (at least on my 11.4 system), I think we can get rid of libjpeg8 completely and rename libjpeg62-devel to libjpeg-devel.
I know of at least one program (ioquake3) that does make use of the new libjpeg8 interfaces and will not work with libjpeg62. Was there any progress in using symbol versioning for libjpeg8 so a program like ioquake3 could use libjpeg8 without clashing with other system libs?
I can't check right now. But IIRC libjpeg8 had symbol versioning from the start (and an update for libjpeg62 was released to also add it) thanks to Debian people. And I asked jpeg-turbo devs to also add the symbol versioning in the ".62" soname and they agreed, so it should be already available (I *suppose* there has been a new release).
Still, what's wrong with keeping libjpeg8-devel in case someone wants to use it (even if we are not going to)?
Verified: In openSUSE 11.4 only libjpeg8 has versioned symbols (so expect problems with ioquake3) but in Factory both versions use symbol versioning. It's a shame that openSUSE 11.4 didn't got the fix for jpeg62, but there is little we can do now to fix it. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Fri, 15 Apr 2011 21:59, Cristian Morales Vega <cmorve69@...> wrote:
2011/4/15 Cristian Morales Vega <cmorve69@yahoo.es>:
2011/4/15 Ludwig Nussel <ludwig.nussel@suse.de>:
Pavol Rusnak wrote:
Now that no package uses libjpeg8 (at least on my 11.4 system), I think we can get rid of libjpeg8 completely and rename libjpeg62-devel to libjpeg-devel.
I know of at least one program (ioquake3) that does make use of the new libjpeg8 interfaces and will not work with libjpeg62. Was there any progress in using symbol versioning for libjpeg8 so a program like ioquake3 could use libjpeg8 without clashing with other system libs?
I can't check right now. But IIRC libjpeg8 had symbol versioning from the start (and an update for libjpeg62 was released to also add it) thanks to Debian people. And I asked jpeg-turbo devs to also add the symbol versioning in the ".62" soname and they agreed, so it should be already available (I *suppose* there has been a new release).
Still, what's wrong with keeping libjpeg8-devel in case someone wants to use it (even if we are not going to)?
Verified: In openSUSE 11.4 only libjpeg8 has versioned symbols (so expect problems with ioquake3) but in Factory both versions use symbol versioning. It's a shame that openSUSE 11.4 didn't got the fix for jpeg62, but there is little we can do now to fix it.
Really? Would it be impossible to create a patch for jpeg62 that includes versioned symbols without the need to recompile any apps linked to it? I'm honestly asking, because I simply don't have the knowlege to say anything definitive on this. If it is possible, I'd like to propose to patch jpeg62 for OSS11.4, to advert problems during the maintainance period of 11.4. No sense in keeping a potential trouble source around. In honest interest, Yamaban out. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2011/4/15 Yamaban <foerster@lisas.de>:
On Fri, 15 Apr 2011 21:59, Cristian Morales Vega <cmorve69@...> wrote:
2011/4/15 Cristian Morales Vega <cmorve69@yahoo.es>:
2011/4/15 Ludwig Nussel <ludwig.nussel@suse.de>:
Pavol Rusnak wrote:
Now that no package uses libjpeg8 (at least on my 11.4 system), I think we can get rid of libjpeg8 completely and rename libjpeg62-devel to libjpeg-devel.
I know of at least one program (ioquake3) that does make use of the new libjpeg8 interfaces and will not work with libjpeg62. Was there any progress in using symbol versioning for libjpeg8 so a program like ioquake3 could use libjpeg8 without clashing with other system libs?
I can't check right now. But IIRC libjpeg8 had symbol versioning from the start (and an update for libjpeg62 was released to also add it) thanks to Debian people. And I asked jpeg-turbo devs to also add the symbol versioning in the ".62" soname and they agreed, so it should be already available (I *suppose* there has been a new release).
Still, what's wrong with keeping libjpeg8-devel in case someone wants to use it (even if we are not going to)?
Verified: In openSUSE 11.4 only libjpeg8 has versioned symbols (so expect problems with ioquake3) but in Factory both versions use symbol versioning. It's a shame that openSUSE 11.4 didn't got the fix for jpeg62, but there is little we can do now to fix it.
Really? Would it be impossible to create a patch for jpeg62 that includes versioned symbols without the need to recompile any apps linked to it? I'm honestly asking, because I simply don't have the knowlege to say anything definitive on this.
If it is possible, I'd like to propose to patch jpeg62 for OSS11.4, to advert problems during the maintainance period of 11.4. No sense in keeping a potential trouble source around.
In honest interest, Yamaban out.
It would not avoid apps linked against the unversioned jpeg62 to use symbols from jpeg8 :-( -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Fri, 15 Apr 2011 22:36:30 +0200 (CEST), Yamaban <foerster@lisas.de> wrote:
Would it be impossible to create a patch for jpeg62 that includes versioned symbols without the need to recompile any apps linked to it?
No, that wouldn't work. The automatic build system would have to recompile all dependent packages in order to get the dependencies right. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (8)
-
Cristian Morales Vega -
Dave Plater -
Dimstar / Dominique Leuenberger -
Ludwig Nussel -
Pavol Rusnak -
Philipp Thomas -
Philipp Thomas -
Yamaban