Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 744880 - [Future EAPI] provide an exherbo edo-like helper
Summary: [Future EAPI] provide an exherbo edo-like helper
Status: CONFIRMED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: future-eapi
  Show dependency tree
 
Reported: 2020-09-26 22:22 UTC by David Seifert
Modified: 2021-05-16 05:22 UTC (History)
2 users (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 David Seifert gentoo-dev 2020-09-26 22:22:17 UTC
In many ebuilds, we want to echo commands for debuggability. For instance, when running homebrew configure script that do not come from Autoconf, when specifying manual compile lines because Makefiles are irreparably broken or for other reasons of loggability, echoing the command before running it is important. Exherbo provides "edo": https://git.exherbo.org/paludis/paludis.git/tree/paludis/repositories/e/ebuild/exheres-0/build_functions.bash#n212

Instead of reinventing these snippets all over the place, let's define them in PMS instead.

Reproducible: Always
Comment 1 Ulrich Müller gentoo-dev 2020-09-27 12:24:38 UTC
What would be failure behaviour? Die if the command fails, unless run under nonfatal?

My main concern is that this would (under a different name) reintroduce the "try" syntax ...

https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-editors/emacs/emacs-20.7.ebuild?hideattic=0&revision=1.4&view=markup#l34
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/bin/ebuild.sh?revision=1.1&view=markup#l85

... which was abolished in 2001 for good reason:

https://archives.gentoo.org/gentoo-dev/message/e20409cb1cf264f5c7a24bdf060ea060

So, I find this one rather problematic. If the goal is to have more verbose logs, then maybe have the package manager enable "set -v" or "set -x" when executing a phase function?
Comment 2 David Seifert gentoo-dev 2020-09-27 13:38:45 UTC
(In reply to Ulrich Müller from comment #1)
> What would be failure behaviour? Die if the command fails, unless run under
> nonfatal?
> 
> My main concern is that this would (under a different name) reintroduce the
> "try" syntax ...
> 
> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-editors/emacs/
> emacs-20.7.ebuild?hideattic=0&revision=1.4&view=markup#l34
> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/bin/ebuild.
> sh?revision=1.1&view=markup#l85
> 
> ... which was abolished in 2001 for good reason:
> 
> https://archives.gentoo.org/gentoo-dev/message/
> e20409cb1cf264f5c7a24bdf060ea060
> 
> So, I find this one rather problematic. If the goal is to have more verbose
> logs, then maybe have the package manager enable "set -v" or "set -x" when
> executing a phase function?

Exherbo makes it "die unless under nonfatal". All the cases of this idiom in all ebuilds I found were fatal (or forgot to make it fatal as a matter of QA, they didn't rely on "maybe fatal and I will recover" patterns), so I think making it unconditionally fatal is absolutely fine. I don't really see a use case for making this non-fatal anyways.
Comment 3 David Seifert gentoo-dev 2020-09-27 13:39:59 UTC
> So, I find this one rather problematic. If the goal is to have more verbose
> logs, then maybe have the package manager enable "set -v" or "set -x" when
> executing a phase function?

I think both set -v -x are too broad, and they'll massively flood logs.
Comment 4 Ulrich Müller gentoo-dev 2020-09-27 14:31:37 UTC
I believe it is conceptionally wrong to have to put a wrapper function in front of every command, just to enable additional verbosity. Also it would suffer from all the issues mentioned in the mailing list post cited above.

Portage already outputs the command as part of the "die" call stack, so the interesting case when a command fails is already covered.

(In reply to David Seifert from comment #2)
> Exherbo makes it "die unless under nonfatal". All the cases of this idiom in
> all ebuilds I found were fatal (or forgot to make it fatal as a matter of
> QA, they didn't rely on "maybe fatal and I will recover" patterns), so I
> think making it unconditionally fatal is absolutely fine. I don't really see
> a use case for making this non-fatal anyways.

It would lose the possibility to specify a "die" command with an explicit error message.