Summary: | collision between binutils-2.18 and binutils-2.18-r1 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Darren Dale <dsdale24> |
Component: | Eclasses | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | esigra, jakub, toolchain |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 194041 | ||
Attachments: | read inforoot/SLOT and use it in case it differs from the expected slot |
Description
Darren Dale
2007-10-10 12:43:49 UTC
*** Bug 195367 has been marked as a duplicate of this bug. *** No, it has everything to do w/ USE=multislot. uhh, no ... PVR implies we slot down to the revision when we dont what does `cat /var/db/pkg/sys-devel/binutils-2.18/SLOT` say ? > what does `cat /var/db/pkg/sys-devel/binutils-2.18/SLOT` say ?
x86_64-pc-linux-gnu-2.18
hmm, and what about: grep SLOT= /var/tmp/portage/sys-devel/binutils-2.18-r1/temp/environment (In reply to comment #5) > hmm, and what about: > grep SLOT= /var/tmp/portage/sys-devel/binutils-2.18-r1/temp/environment SLOT=x86_64-pc-linux-gnu-2.18 declare -x SLOT="x86_64-pc-linux-gnu-2.18" portage: since SLOT is evaluating to the same value ("x86_64-pc-linux-gnu-2.18"), why is a collision being detected ? The problem is that is just assumes that the SLOT generated when running the normal depend phase is the same SLOT at merge time. It's a perfectly valid assumption given the SLOT is supposed to be static metadata. Instead of using this USE=multislot hack, is there some reason why the ebuild doesn't just define SLOT="${PV}" ? That would be valid within the context of static SLOTs, since you'd have the same SLOT that was generated during the normal depend phase. Dynamic slotting of some sort (be it via SLOT or some other means) is an extension that can by supported, but first we have to define how it works so that we can include it as part of a future EAPI revision (bug 174407). the only reason the default isnt $PV is due to historically it's been SLOT=0 and there's no way to transition from 0 to $PV well, when first implemented, there was no "slot move" in package updates, so i guess if we listed every version of binutils out there, it would be possible ... but that still wouldnt allow CTARGET ... Created attachment 133808 [details, diff]
read inforoot/SLOT and use it in case it differs from the expected slot
This has been released in 2.1.3.15. |