Summary: | [Future EAPI] Automatically find out S | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Petteri Räty (RETIRED) <betelgeuse> |
Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | esigra |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 174380 |
Description
Petteri Räty (RETIRED)
2010-03-20 12:57:43 UTC
So basically S is reset for prepare and on... question is, how much mucking around in S do ebuilds under >eapi2 do? Shouldn't be a huge amount, but worth checking into I'd think... (In reply to comment #0) > Currently S default to WORKDIR/P. I propose to extend this so that if WORKDIR/P > does not exist and there is only one subdirectory of WORKDIR then we should use > the subdirectory. I'd make that "only one subdirectory and no files", to cover for archives that extract directly into . and happen to have one subdirectory too. Should also consider how this will interact with bug 273648. (In reply to comment #1) > So basically S is reset for prepare and on... question is, how much mucking > around in S do ebuilds under >eapi2 do? Shouldn't be a huge amount, but worth > checking into I'd think... > I don't really understand this, can you please explain. The problem I am solving is that now you need to manually find out what the single directory under WORKDIR is called and then put in ebuild like: ./commons-el/commons-el-1.0-r2.ebuild:S=${WORKDIR}/${P}-src (In reply to comment #2) > > Should also consider how this will interact with bug 273648. > Will still be useful if the user has explicitly set S but it doesn't exist. (In reply to comment #4) > Will still be useful if the user has explicitly set S but it doesn't exist. Actually, that raises a question- imo, if the ebuild actually *has* set S then we shouldn't screw with it- if it's wrong it should go boom. Guessing you may've intended it, but just confirming- will these semantics only apply if S is unset entering into unpack phase? (In reply to comment #5) > > Guessing you may've intended it, but just confirming- will these semantics only > apply if S is unset entering into unpack phase? > Yes. It's confusing if the value set is not actually used. Personally, presuming after a quick community verification (dev ml or something similar), I've got no issues w/ it... Only reason I'm thinking of verification is if someone has some goofy eclass templating trick they want that can be sanely implemented. In EAPI 4 we took the opposite direction, namely restricting automatic fallback and requiring the ebuild to specify S explicitly (bug 273648). Closing. Feel free to reopen if you still want this. |