Bugzilla Bug 41157

Xvid packages current state:

 - xvid-0.9.2-r1 (stable) provides libxvidcore.so.2.1
 - xvid-1.0.0_beta3 (~arch) provides libxvidcore.so.4.0
 - both provides a header of the same name, xvid.h
 - 2.1 and 4.0 APIs are not compatible


Issues it creates:

 - xvid update (0.9.2-r1 -> 1.0.0_beta3) breaks applications.
 In the 1.0.0_beta3 eubild, a libxvidcore.so.2 -> libxvidcore.so.4.0
 is created to make ldd happy, but in fact this link only hides the
 issue that the right library is missing after an update. A trivial
 example is:
   - build mplayer with xvid support and the 0.9.2-r1 installed
   - update xvid to 1.0.0_beta3
   - try `mplayer -vc xvid An-Xvid-File.avi`
   => mplayer: relocation error: mplayer: undefined symbol: xvid_init

 - some applications won't compile (or will drop xvid support) when it
 is 1.0.0_beta3 that is installed. A dependency on =0.9.2* would be 
 okay, but next world update will go through an update to 1.0.0_beta3 
 (on a ~arch machine at least), thus the fix of the dependency is only
 an insurance that we will manage to compile a package that will break
 very soon. An example of such an application is media-tv/xawdecode.


Proposed solution:
 
 * xvid ebuilds: I suggest they get slotted (API version would be a 
 good candidate for the slot number). Libraries don't overwrite 
 each other, so it would solve easily the runtimes issues. The problem 
 is the header file. I can think of something like this:
   - rename xvid.h to xvid-$SLOT.h
   - on post_inst/post_rm, create a symlink named xvid.h to the real 
 header which have the greatest slot number.
 
 * ebuilds for apps that can compile only on one precise version: 
 I see two solutions:
   - either patch the sources to change <xvid.h> into <xvid-X.Y.h>
   (many files to patch, but easy to automate the patch creation)
   - or force the xvid.h symlink to the right version at pkg_setup()

 * ebuilds for apps that can compile one both versions: depending of
 what is choosen above:
   - either no change (since only xvid ebuild touch the symlink, we
   now it is always targeting best version)
   - or force the symlink to the best available header at pkg_setup()
 
 * if the second solution is choosed, it can be implemented as an 
 eclass that would provide the right pkg_setup()
 
 * both xvid and apps ebuilds changes will imply revision increment.
 The dependencies for apps ebuilds will also have to be updated.


Another approach:

 Mask the 1.0.0 serie... I've found no application depending explicitly 
 on 1.0.0*, and I think that in most cases, application that have not 
 yet made there transition to the 4.0 will do it in such a way that they 
 are still compatible with 2.1. That's what have been made for applications
 that have already made there update, and I also know that it should be the 
 case for xawdecode. After enough time, all applications will be 4.0 API
 compatible, and it will be possible to unmask a slotted 1.0.0 serie, without
 bothering with the header file (no more needed if no more app requires the
 precisly the 0.9.2 version to compile).


Now, what do you think? First, are the bugs important enough to deserve a fix
that would touch several ebuilds? I would understand a negative answer, i 
personnaly do care about keeping xvid support in xawdecode, but that's not a 
problem for me to mask the 1.0.0* in my package.mask. And also people who 
will experience breakage after xvid updates will only have to recompile the few
apps that were using 0.9.2, and that's something revdep-rebuild can do (if you
remove from the 1.0.0* the symlink that fakes a .so.2 lib - otherwise, revdep-
rebuild won't see it), and you can add a warning explaing this in the 1.0.0* ebuilds.

Second, if you do want to apply some real fixes, what is the cleanest solution 
in your opinion? I don't really have a preference, but whatever you choose, i 
would be glad to help implementing it, just let me now.

That's it, sorry for the verbosity, the implications of this issue were not 
clear to me at the beginning, and i had to write to well understand it...

Thanks.

in cvs

thx

As i tried to explain, simply setting a slot number doesn't solve anything
since the headers overwrite each other. This makes impossible to compile both
some apps for the 0.9.2 and others for the 1.0*. In that case, slotting is
useless, or maybe even worst than no slotting at all since it makes possible to
have a satified =0.9.2* dep whereas in fact you can't compile for this lib by
lack of the right header.

Or should 0.9.2-dependent ebuilds provide this header by themself? I ask
seriously because this issue is blocking me for updating the xawdecode ebuild
to 0.9.0 (I would like it to compile with working xvid support, since it is one
of the major feature of this app). If so, ok, I can do this, I would just like
a confirmation because it seems strange. 

Also, could you remove the .so.2 symlink created from 1.0* ebuilds? This one
really doesn't make sense. Pseudo patch:
----------------------------
         dodoc AUTHORS ChangeLog LICENSE README TODO doc/*
         dosym /usr/lib/libxvidcore.so.4.0 /usr/lib/libxvidcore.so
-        dosym /usr/lib/libxvidcore.so /usr/lib/libxvidcore.so.2

         if [ "`use doc`" ]
----------------------------

And a last note, less important: shouldn't the reslotting be declared in the
1Q-2004 updates? (I ask more for information, in fact i've never seen the slot
update command being used, whereas i think it is as important as the
renamings).

Thanks a lot for taking a bit of time to come back on this issue.

This should _not_ be slotted. You can only use SLOTs if the versions in the
different SLOTs do not overlap, they do here. Please fix ASAP.

The solution is to fix upstream deps as needed and/or to suggest the use of
'revdep-rebuild'.

symlinking should be fixed in my rc4 ebuild:
 http://bugs.gentoo.org/show_bug.cgi?id=47838

Are people still experiencing problems with the rc4 build?  If not I'll update
to 1.0.  I don't see any problems with xvid at this point.  Correct me if I'm
wrong.

that symlinking is a hack, it should simply not use SLOTs at all.

I don't understand why the video maintainers did this, it's quite obvious that it is wrong.

> that symlinking is a hack, it should simply not use SLOTs at all.

Yes it would be a hack, and that's why I only asked for comments here, and did not submitted the needed patches.  We agree the problem is upstream, it would have been far better if xvid folks had named their headers "xvid-0.9/xvid.h" and "xvid-1.0/xvid.h", like it is done for instance for gtk-1.2 and gtk-2.0. That's  two different libs, that need two different headers. But it was to late for such an upstream change. That's why i've suggested this symlink hack, at least it would have make things work as expected until all apps are ported to the new API version and we can get ride of the old one. 

Now, this bug is rather old, and maybe there is no more app depending on the old API. For instance, Xawdecode (the one I knew about and was bothering me) can now compile against the new API since its latest version. If that's the case for allmost all apps, then there is no need to bother with this anymore. Maybe that once 1.0 will be marked stable, 0.9.2 should be dropped and the few remaining apps still needing it, if any, should be masked until they are ported to the new API. 

Side note: I've suggested to xvid devs that next time they change the API, they also change the header name or location accordingly.

well, I don't really care what way it gets solved (pushing the new api/version,
fixing slots the proper way), but the current 'solution' should not ever have
been added. The problem here that there is no progress whatsoever, hell ...
noone of the video herd has replied so far. This should've been sorted out ages
ago, because it is a serious issue. Can someone take some responsibility here ?

the saner way will be hard and time consuming:

let's force xvid to behave, the includedir will be marked as xvid-0.9 and xvid-1.0

obviously before that we have to patch every program that could use xvid to get the right header.

Who is for that?

if the 1.0 api is adopted everywhere I'd say we should just push 1.0 stable and
 ditch 0.9 altogether.

Couldn't find any place where < 1.0 is definitely needed, but I would like to
rely on a second pair of eyes before killing 0.9.x -
could someone please confirm that we don't get a problem if we get some xvid-1
stable and drop 0.9x?

I hope that avifile 0.7.41 can get stable soon - it works with xvid 1.x

Why not just using the same way used for sys-libs/db? an /usr/include/xvid21
and an /usr/include/xvid40, and then append-flags -I /usr/include/xvid${needed}
for every package which depends on one of them?

Bah, i can't find packages depending on =xvid-0.9* or things like that anymore,
so maybe it would simply be time to remove 0.9.x from the tree?

Ok let's see the state of this:  
  
- xvid-1* is marked stable everywhere, so it's a non-issue.  
- vlc-0.8 is the minimum version in portage (previous versions had problems)  
- xawdecode still depends on it, in all its variants. xdtv replaces xawdecode,  
but it was added just one week ago, we must wait before marking it stable and  
asking users to move from xawdecode to xdtv.  
- copy-pasting jstubbs: "[17:37] <jstubbs> Flameeyes: mpeg4ip, avifile,  
mplayer, transcode... all >=": avifile 0.7.38 is still the latest stable for 
alpha and ia64; the rest still needs work; transcode-1.0.0 is out but i 
haven't had the time to update it in portage after testing, and it still will 
be p.masked until tested that it works with 0.6-based software. 

mpeg4ip seems to recognize without problems 1.0 style xvid. 
 

transcode 0.6 is the only blocker.  
I'd really like get rid of transcode by itself, but it's difficult especially 
because dvdrip is based on that. 
avifile is anyway going to fade away. 
 

Actually, transcode 0.6 uses xvid 1.0.... so just avifile. 

Actually, also avifile is safe now, so I got rid of old xvid and now this can
be closed.