Summary: | LZO slotting? | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Francisco José Cañizares Santofimia <telefrancisco> |
Component: | [OLD] Library | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | dragonheart |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.oberhumer.com/opensource/lzo/lzonews.php | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 112367 |
Description
Francisco José Cañizares Santofimia
2005-10-30 04:14:54 UTC
Daniel: Is there a problem with proper include detection or another reason why we can't do this? I just created a slotted ebuild and it installed fine without any conflict. In your gentoo-dev email I missed the information, why the versions can't live safely side by side. probably can. Just haven't looked into it. I've still got to check all the programs that depend on lzo and see how they behave. forced slotting of lzo by incrementing the SLOT value by one in the 2.x series ebuilds seemed good enough for me. I package-built both 1 & 2 to tarbz2s then diffed them for clashes and there apears to be no file clashes. And as it is, stuff needing lzo 1 looks in /usr/include for .h's and stuff that wants lzo2 looks in /usr/include/lzo/ so for the time being slotted lzo is a handy trick. untill of course all things depending on lzo are either switched to lzo2 or the ebuild for lzo2 puts symlinks into the /usr/include folder so stuff can find them ( oh yeah, and symlink the lzo2.so 's to the lzo1.so's more likely than not so that things like transcode and mplayer will actually work ;) done. thankyou thankyou and closing. |