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

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. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

2011/4/15 Ludwig Nussel :

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

On Fri, 15 Apr 2011 21:59, Cristian Morales Vega wrote:

2011/4/15 Cristian Morales Vega :

...

2011/4/15 Ludwig Nussel :

...

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

On Fri, 15 Apr 2011 22:36:30 +0200 (CEST), Yamaban 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