Summary: | [PATCH] portage should fixup .la files to accomodate removal of same | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Peter Alfredsen (RETIRED) <loki_val> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | awickedshimmy, billie, binki, bm55b, bugs+gentoo, bugs, esigra, flameeyes, ftobin, galtgendo, gef.kornflakes, john_r_graham, mihel, pacho, rhill, ssuominen, themazepa, theosib, toffanin.mauro, wolf31o2, zioalex |
Priority: | High | Keywords: | InVCS |
Version: | 2.2 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 287318, 314787, 335925 | ||
Attachments: | Fixup .la files |
Description
Peter Alfredsen (RETIRED)
2009-05-24 20:43:31 UTC
Created attachment 192332 [details, diff]
Fixup .la files
Do I get it right that a fix to this bug will also resolve the 'fixed' but not fixed bug http://bugs.gentoo.org/show_bug.cgi?id=275597 ? Can't we do this in some kind of hook? Can we touch livefs in a post_inst_hook? See the main problem here is that the brokenness is in GENTOO stable. However even if we fix it in portage-shiny-new-version the majority of our users (hi users!) will not be using portage-shiny-new-version and thus will not get the fix. This is why we need to put more planning into efforts like this. -A Can we just have portage call lafilefixer so that we don't have to maintain this code? If it the code needs to be in portage itself, then I'd prefer python. I think deleting LA file should go through a GLEP (Gentoo Linux Enhancement Proposal) process and have a real discussion about it. Its a big change. The deletion of the LA file in media-libs/libogg done by the ebuild maintainer broke alot of stuff needlessly. Don't leave the distribution one foot in and one foot out of autoconf/libtool. (In reply to comment #6) > I think deleting LA file should go through a GLEP (Gentoo Linux Enhancement > Proposal) process and have a real discussion about it. Its a big change. The > deletion of the LA file in media-libs/libogg done by the ebuild maintainer > broke alot of stuff needlessly. Don't leave the distribution one foot in and > one foot out of autoconf/libtool. > If fixed liboog by masking it (>=media-libs/libogg-1.1.4). In the meantime libogg-1.1.3 is no longer in the portage tree and i think it should be there until this problem is fixed. Or did i miss something ? (In reply to comment #7) > (In reply to comment #6) > > I think deleting LA file should go through a GLEP (Gentoo Linux Enhancement > > Proposal) process and have a real discussion about it. Its a big change. The > > deletion of the LA file in media-libs/libogg done by the ebuild maintainer > > broke alot of stuff needlessly. Don't leave the distribution one foot in and > > one foot out of autoconf/libtool. > > > > > If fixed liboog by masking it (>=media-libs/libogg-1.1.4). In the meantime > libogg-1.1.3 is no longer in the portage tree and i think it should be there > until this problem is fixed. Or did i miss something ? > Yes i missed something, was probably not up to date? Works without *.la files now. Sorry for posting nonsens. (In reply to comment #5) > Can we just have portage call lafilefixer so that we don't have to maintain > this code? If it the code needs to be in portage itself, then I'd prefer > python. On flameeyes' blog he said to use `lafilefixer "${D}"`. Is that equivalent to what the attached patch does? I think something like that is preferable to putting the code in portage. *** Bug 325493 has been marked as a duplicate of this bug. *** Diego posted again that running lafilefixer in this way would be really useful: http://blog.flameeyes.eu/2010/06/30/let-s-call-a-spade-a-spade Then, from my point of view, we should go this this approach if nobody disagrees in the next days There's a python implementation of this in git now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=76118ef9b746ca3ba644504b6ddb13906bc2e2f0 This is fixed in portage-2.1.9. *** Bug 357291 has been marked as a duplicate of this bug. *** |