Summary: | Moving dev-libs/boost from unslotted to slotted may leave library files (@preserved-libs) making it impossible to eselect a boost version | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Antek Grzymała (antoszka) <antoni> |
Component: | Current packages | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED DUPLICATE | ||
Severity: | major | CC: | cpp+disabled, dev-zero, djc, luke-jr+gentoobugs, SebastianLuther, zmedico |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 240323, 286714 | ||
Attachments: | Build log |
Description
Antek Grzymała (antoszka)
2009-10-25 18:06:37 UTC
Created attachment 208229 [details]
Build log
Build log attached.
See 'eselect boost'. It's already set without touch anything: $ sudo eselect boost list Available boost versions: [1] boost-1.35/default * So I tried resetting it: $ sudo eselect boost set 1 Removing symlinks from old version Creating symlinks for boost-1.35/default ln: creating symbolic link `libboost_filesystem-mt.so': File exists !!! Error: Couldn't create symlink "/usr/lib64/libboost_filesystem-mt.so" exiting That error tells that something went wrong: all non-versioned libs should be just symlinks to the versioned ones. What's i.e. output of 'ln -l /usr/lib64/libboost_filesystem-mt.so' ? On x86, with boost 1.39 selected, 'ls -l /usr/lib/libboost_filesystem-mt.so' gives me: lrwxrwxrwx 1 root root 30 10-10 15:31 /usr/lib/libboost_filesystem-mt.so -> libboost_filesystem-mt-1_39.so Oh, damned - I think I know what went wrong - preserved-libs didn't work well with the change from unslotted boost libs to slotted. That's just a guess, but probably those unversioned files are the preserved boost libs. See, if you you can confirm that. (In reply to comment #5) > Oh, damned - I think I know what went wrong > - preserved-libs didn't work well with the change > from unslotted boost libs to slotted. > That's just a guess, but probably those unversioned files > are the preserved boost libs. > See, if you you can confirm that. Yep, that was the problem. I guess we need to change the bug title and have it assigned properly. assigning it properly *** Bug 290776 has been marked as a duplicate of this bug. *** removing the preserved lib, eselecting a version, and rebuilding affected packages succeeds, but leaves the "preserved libs" flag on the file. This wouldn't have happened if =dev-libs/boost-1.35.0-r5 would properly block <=dev-libs/boost-1.35.0-r2. *** This bug has been marked as a duplicate of bug 290691 *** I'm making this block bug 286714 since we might see issues similar to this when that's fixed. Re Comment #10: It wouldn't? Portage would do the same thing if there was an explicit block AFAIK... (In reply to comment #12) > Re Comment #10: It wouldn't? Portage would do the same thing if there was an > explicit block AFAIK... You'd need a EAPI 2 hard !!atom blocker, and you also need >=portage-2.1.7 due to bug #270953. Even a hard-block will generally be resolved by a manual -C of the blocking package, which will leave the library once bug 286714 is fixed. I think having the eselect module clean up the mess may be the only realistic solution... (In reply to comment #14) > Even a hard-block will generally be resolved by a manual -C of the blocking > package, which will leave the library once bug 286714 is fixed. As long as portage's behavior is as it is, a strong block is the best solution. And since Zac knows about the situation, he can report back when the time comes. > I think having > the eselect module clean up the mess may be the only realistic solution... > That would mean, that eselect would have to delete things, that might or might not belong to some package or even worse that were put there by the user. All newer version of boost have this strong block, there is no point for .35-r5 to not have it. |