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.
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.
