Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 310363 - [Future EAPI] Automatically find out S
Summary: [Future EAPI] Automatically find out S
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: PMS/EAPI
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: future-eapi
  Show dependency tree
 
Reported: 2010-03-20 12:57 UTC by Petteri Räty (RETIRED)
Modified: 2019-08-25 19:13 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petteri Räty (RETIRED) gentoo-dev 2010-03-20 12:57:43 UTC
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.
Comment 1 Brian Harring gentoo-dev 2010-03-20 15:24:26 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...
Comment 2 David Leverton 2010-03-20 18:09:12 UTC
(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.
Comment 3 Petteri Räty (RETIRED) gentoo-dev 2010-03-20 18:10:23 UTC
(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
Comment 4 Petteri Räty (RETIRED) gentoo-dev 2010-03-20 18:11:19 UTC
(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.
Comment 5 Brian Harring gentoo-dev 2010-03-20 18:38:40 UTC
(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?

Comment 6 Petteri Räty (RETIRED) gentoo-dev 2010-03-20 18:41:56 UTC
(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.
Comment 7 Brian Harring gentoo-dev 2010-03-20 18:54:38 UTC
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.
Comment 8 Ulrich Müller gentoo-dev 2017-06-07 15:01:05 UTC
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.