Re: [gentoo-dev] Usage of econf with an additional || die
В Вск, 28/09/2008 в 20:24 +0200, Thomas Sachau пишет: I see many ebuild that still use econf || die, also econf should die by itself. Are there any specific reasons for this? Some cases where econf does not die also it fails? Or some other reason for this? This || die is redundant. Personally I remove it in every package I touch and I suggest others do the same. People use our tree to learn how to write ebuilds, so it's good idea to have consistent syntax in our ebuilds... -- Peter.
Re: [gentoo-dev] Usage of econf with an additional || die
Peter Volkov wrote: В Вск, 28/09/2008 в 20:24 +0200, Thomas Sachau пишет: I see many ebuild that still use econf || die, also econf should die by itself. This || die is redundant. Personally I remove it in every package I touch and I suggest others do the same. People use our tree to learn how to write ebuilds, so it's good idea to have consistent syntax in our ebuilds... So, can we have a nice little table of which functions die by themselves and which ones need || die added in ebuilds? Please? Thanks, -- Ben de Groot Gentoo Linux developer (lxde, media, desktop-misc) Gentoo Linux Release Engineering PR liaison __ [EMAIL PROTECTED] http://ben.liveforge.org/ irc://chat.freenode.net/#gentoo-media irc://irc.oftc.net/#lxde __ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Usage of econf with an additional || die
Ben de Groot wrote: So, can we have a nice little table of which functions die by themselves and which ones need || die added in ebuilds? Please? Thanks, A quick grep of /usr/lib/portage/bin clues you in that every function that is an external file does *not* die by itself. So, emake, do*, etc.. %% grep -c die * |grep -v :0 ebuild.sh:61 etc-update:14 isolated-functions.sh:18 misc-functions.sh:26 repoman:2 I believe this is because you can have those functions in a subshell and then die won't behave predictably. I'm sure some PM people will correct me if I am wrong. ;) -Jeremy
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: package.mask
On Tue, 30 Sep 2008 15:10:44 + Daniel Gryniewicz (dang) [EMAIL PROTECTED] wrote: dang08/09/30 15:10:44 Modified: package.mask Log: Remove poppler from mask; current evince works fine s/current/only/ I currently have pdftex,luatex xpdf failing here. It would have been nice if maintainers had been contacted before pushing this to ~arch since it is a very well known api-breaking library. Not that they seem difficult to fix but I'm not really fond of the let it break, wait for bug reports, fix later way. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Usage of econf with an additional || die
Jeremy Olexa schrieb: Ben de Groot wrote: So, can we have a nice little table of which functions die by themselves and which ones need || die added in ebuilds? Please? Thanks, A quick grep of /usr/lib/portage/bin clues you in that every function that is an external file does *not* die by itself. So, emake, do*, etc.. %% grep -c die * |grep -v :0 ebuild.sh:61 etc-update:14 isolated-functions.sh:18 misc-functions.sh:26 repoman:2 I believe this is because you can have those functions in a subshell and then die won't behave predictably. I'm sure some PM people will correct me if I am wrong. ;) -Jeremy From my knowledge and experience with sunrise: some functions that dont need || die: epatch, econf, eqmake3, eqmake4 some functions that need || die: emake, do* Afaik die wont work in a subshell independent of how it is called, so the die from econf wont work, but also the emake || die one would also not work. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
Nirbheek Chauhan kirjoitti:
On Sat, Sep 27, 2008 at 3:47 PM, Thomas Sachau [EMAIL PROTECTED] wrote:
So what about this one?
default_src_install() {
if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
emake DESTDIR=${D} install || die emake install failed
fi
if [ -n ${DOCS} ]; then
dodoc ${DOCS} || die dodoc failed
else
# No die here because we don't know if any of these exist
dodoc AUTHORS ChangeLog NEWS README
fi
}
This seems alright fine to me
Cheers,
~Nirbheek Chauhan
It's not. If you want to have default DOCS then you should loop through
the items and check with [[ -e ]] before trying to install them.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Usage of econf with an additional || die
On Dienstag, 30. September 2008, Thomas Sachau wrote:
From my knowledge and experience with sunrise:
some functions that dont need || die:
epatch, econf, eqmake3, eqmake4
some functions that need || die:
emake, do*
Afaik die wont work in a subshell independent of how it is called, so the
die from econf wont work, but also the emake || die one would also not
work.
Well there might be some cases when die does not work fine, I am not sure.
But it IS designed to work in subshells.
Looking into /usr/lib/portage/bin/isolated-functions.sh: die basically calls
kill -s SIGTERM ${EBUILD_MASTER_PID}
and sigterm is catched in /usr/lib/portage/bin/ebuild.sh
# subshell die support
EBUILD_MASTER_PID=$$
trap 'exit 1' SIGTERM
and btw. econf is also implemented as a function in ebuild.sh so it even is
executed inside the main ebuild bash process - no subshell here.
Regards
Matthias
[gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
On Mon, 29 Sep 2008 22:31:46 -0700 Zac Medico [EMAIL PROTECTED] wrote: Can package.use syntax be extended to allow set entries? @compiz-fusion -gnome kde kde4 Perhaps, but we need to clarify how that sort of setting will affect nested sets. For example, if @compiz-fusion contains nested sets, would those USE settings apply to the nested sets as well? Will nested sets be allowed to have independent USE settings from the sets that nest them? Maybe a nested set could inherit the USE flag settings of its parent set unless it has its own entry in package.use. Though what happens if a package is in both sets which have conflicting flags in package.use? I would say that the nested set has to have priority. If not, I can easily imagine people getting confused when their USE settings for a set are being applied to all but one or two packages. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
