case description: As a simple user I often try new software per simple bump copying the portage ebuild with a newer version number to my local overlay. Some times upstream changes the tar packed source directory, for example: Emerging (1 of 5) net-libs/libtorrent-rasterbar-1.2.1::pmaci >>> Failed to emerge net-libs/libtorrent-rasterbar-1.2.1, Log file: >>> '/var/log/portage/build/net-libs/libtorrent-rasterbar-1.2.1:20190506-141010.log' >>> Jobs: 0 of 5 complete, 1 failed Load avg: 1.12, 0.95, 1.14 * Package: net-libs/libtorrent-rasterbar-1.2.1 * Repository: pmaci ..... >>> Unpacking source... >>> Unpacking libtorrent-rasterbar-1.2.1.tar.gz to /tmp/portage/net-libs/libtorrent-rasterbar-1.2.1/work >>> Source unpacked in /tmp/portage/net-libs/libtorrent-rasterbar-1.2.1/work * ERROR: net-libs/libtorrent-rasterbar-1.2.1::pmaci failed (prepare phase): * The source directory '/tmp/portage/net-libs/libtorrent-rasterbar-1.2.1/work/libtorrent-libtorrent_1_2_1' doesn't exist --- Indeed there not is work/libtorrent-libtorrent_1_2_1 ,but there is instead work/libtorrent-libtorrent-1_2_1 Why can't emerge find this single source directory itself? Ok, in case upstream pack multiple directories, this is not feasable for emerge to find itself. But the most of upstream just have one directory. Thus would be possible to have a special function like: _single-source-directory() { cd ${WORKDIR} || die n=0 for i in *;do n=$(( n + 1 )) S="${WORKDIR}/$i" [ -d "$S" ] || die done [ "$n" = "1" ] && echo $S || die } thus this ebuild line: S="${WORKDIR}/${PN/-rasterbar}-${MY_P}" could instead be simple and flexible regarding upstream tars: S=$( _single-source-directory )
This looks like functionality that would be used only by a small fraction of ebuilds, because most packages unpack into ${P}. Maybe an eclass function would be more appropriate, e.g., as part of unpacker.eclass?
Such a function would also require evaluating the S= during every phase, as presently S is set BEFORE the unpacking happens
Instead of changing S, you could just have src_unpack move the source directory to ${P}, or unpack the sources there directly (see vcs-snapshot.eclass).
(In reply to Mike Gilbert from comment #3) > Instead of changing S, you could just have src_unpack move the source > directory to ${P}, or unpack the sources there directly (see > vcs-snapshot.eclass). Yeah, as the documentation writes: S Path to the temporary build ... Default: "${WORKDIR}/${P}" If a Gentoo maintainer is sure about the simple structure of the upstream source.tar.gz, he could write a statement in src_unpack , e.g. enableFutureEapi: unpack_rename_singleDir2defaultS (or whatever naming convention Gentoo prefers)
We recently removed S=${WORKDIR} fallback. This sounds like going in the other direction, and in a worse way even. We don't want ebuilds to magically guess what the author meant. We want authors to tell ebuilds what to do, and leave ebuilds in good state for others to work with. 'This ebuild will fail if you add distfile that introduces a new top-level directory' is not a nice way to make stuff maintainable.
(In reply to Robin Johnson from comment #2) > Such a function would also require evaluating the S= during every phase, as > presently S is set BEFORE the unpacking happens Assigning S in src_unpack would be enough: https://projects.gentoo.org/pms/7/pms.html#x1-11400011.2 (In reply to Ulenrich from comment #4) > If a Gentoo maintainer is sure about the simple structure of the upstream > source.tar.gz, he could write a statement in src_unpack , e.g. > enableFutureEapi: unpack_rename_singleDir2defaultS I still wonder how often your usage case happens. Upstream frequently renaming their directory may rather be a reason to talk to them about that. :) Also, from my point of view as a dev, maybe it's nice if the ebuild will fail and therefore alert me about the changed packaging, because chances are that it won't be a trivial version bump.
(In reply to Ulrich Müller from comment #6) > I still wonder how often your usage case happens. Upstream frequently > renaming their directory may rather be a reason to talk to them about that. It is the other way round: Gentoo maintainers repack upstream source if they find it unorthodoxly handled (In reply to Michał Górny from comment #5) > We recently removed S=${WORKDIR} fallback. This sounds like going in the > other direction, and in a worse way even. We don't want ebuilds to > magically guess what the author meant. We want authors to tell ebuilds what > to do, and leave ebuilds in good state for others to work with. So, there shall be no tool accomodating the simple user with his experiments :(
Ok, my intention was not EAPI but more help from portage when experimenting. Without my glasses I didn't see the difference: work/libtorrent-libtorrent_1_2_1 work/libtorrent-libtorrent-1_2_1 and I wished something like: inherit fancy-tools-for-the-dumb-user src_unpack() { correct_S_if_only_one_directory
(In reply to Ulenrich from comment #8) > Ok, my intention was not EAPI but more help from portage when experimenting. > Without my glasses I didn't see the difference: > work/libtorrent-libtorrent_1_2_1 > work/libtorrent-libtorrent-1_2_1 > > and I wished something like: > inherit fancy-tools-for-the-dumb-user > src_unpack() { correct_S_if_only_one_directory A non-standard quirk like this would actually make ebuild development *more* complex. That said, if you implement this behavior in an eclass then the standard can remain as-is.
(In reply to Zac Medico from comment #9) > A non-standard quirk like this would actually make ebuild development *more* > complex. That said, if you implement this behavior in an eclass then the > standard can remain as-is. An additional eclass called fancy-QuicknDirty-tools-dont-use with only having functions named fancy-* would enable you to grep search for ebuilds, which desperately need help.
If something urgently needs help, there's no place for it in ::gentoo. This is not a dumpster for half-broken ebuilds that you want others to fix for your.
Anyway, this isn't an EAPI feature. PMS team is out of here.
...and eclass don't happen on user requests. They happen when developers have *many* ebuilds needing some specific functionality, after gentoo-dev review.
