[gentoo-dev] Re: openrc 0.12 - netifrc/newnet mix-up
On Tue, Dec 10, 2013, Steev Klimaszewski wrote: On Tue, 2013-12-10, Rich Freeman wrote: On Tue, Dec 10, 2013, Steev Klimaszewski wrote: On Mon, 2013-12-09, Rich Freeman wrote: You're thinking with your x86/amd64 hat on here. Actually, I probably just underquoted. I am well-aware that there are issues with ARM, hence my previous suggestion that it might make sense to vary this by profile. Definitely - but then we have to do everything in the profiles, and at least for ARM, there are currently 6 profiles, and we're considering introducing a 7th (neon), and we will need to add aarch64, which will be at least 2 more. I suppose we could do it in the base arm profile... I don't think it would make sense to remove networking from any profile. Far better to develop a 14 profile using dhcpcd and make that work, without affecting current users. The virtual could be used to add any higher layer desired, but would not be required. If it actually had collisions with other network managers I think there would be more of a case for removing it. After all, we stick openrc and portage (the PM) in the stage3 and you don't exactly need those in order to run Gentoo... Yup. Which is steev's functional point, so you seem to be in agreement. While you don't need those specifically to run Gentoo, the point of the stage3 is to have a workable base to start with. So people are very much free to yank out openrc and put in, say, systemd, and rip out portage and add in paludis, if they so choose, and make those available. And from the traffic I've seen on the systemd list, it looks like they are adding some sort of networking to systemd itself as well, so we probably will need a virtual at some point. My specific point of the email though, was you saying that a stage3 in general aren't functional - but they are - they are the very base of a functional system, and you simply add things on top, or replace things with your preferred methods. A stage1 or a stage2 isn't particularly functional. Agreed. There's no real point in a stage3 that doesn't support some sort of networking. It's fine to change over, but again that should be done with a new profile, not by randomly removing netifrc USE default. The latter may not be correct on a purist level, but it's a darn sight better than breaking installs, and is only a transitional measure. The transition is much easier to handle as a profile change, for an end-user, and the experimental profile facilitates modification of base stages and working on them, without breaking the current setup. After all, if someone wants to setup a Gentoo install *without* networking they are very much doing a specialist thing, and can deal with it themselves. So I don't think we should give too much time to that use-case, in terms of implementation effort; staying out of the way when the user tells us to is all that's required, and that's easy: do nothing, or in this case, don't force any dependencies on higher-level network managers, unless required for correct functioning. Regards, steveL -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On Tue, Dec 10, 2013 at 09:55:05PM +0100, Pacho Ramos wrote: https://bugs.gentoo.org/show_bug.cgi?id=197625#c14 This has reminded me that maybe we should switch to cronie from vixie-cron as default and recommended cron provider in Handbook. Last time I checked, vixie-cron upstream was died while cronie forked it fixing some bugs :/ What do you think? I'm ok with it. At least cronie's main website is quick to find, and I remember a bug I sent in to the cronie maintainers and got a fast reply, so positive experience as well. Wkr, Sven Vermeulen
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On 12/10/2013 09:18 PM, Paul B. Henson wrote: I'd say go one step further and get rid of vixie-cron completely, is there anything it does that cronie can't do as well or better? Is cronie a drop-in replacement, or do I have to do some thinking when replacing vixie-cron?
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
Pacho Ramos wrote: Last time I checked, vixie-cron upstream was died while cronie forked it fixing some bugs :/ What do you think? I think that nobody who is not intimately familiar with the development in both projects can think anything that is actionable. It's insulting to see how people all over the internet run as fast as they possibly can in whatever direction even though they have nearly zero detailed understanding of the options they are choosing between. A fork is never automatically a good thing. fixing some bugs sounds like makeup. //Peter
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On Wed, Dec 11, 2013 at 2:25 PM, Michael Orlitzky m...@gentoo.org wrote: On 12/10/2013 09:18 PM, Paul B. Henson wrote: I'd say go one step further and get rid of vixie-cron completely, is there anything it does that cronie can't do as well or better? Is cronie a drop-in replacement, or do I have to do some thinking when replacing vixie-cron? It should be a drop-in. The only change to make would be to remove vixie-cron and add cronie to the default runlevel.
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On 12/10/2013 08:55 PM, Pacho Ramos wrote: https://bugs.gentoo.org/show_bug.cgi?id=197625#c14 This has reminded me that maybe we should switch to cronie from vixie-cron as default and recommended cron provider in Handbook. Last time I checked, vixie-cron upstream was died while cronie forked it fixing some bugs :/ What do you think? If vixie-cron upstream is dead as you say, then I agree we should move away from it. -- Regards, Markos Chandras
[gentoo-dev] rfc: renaming rc binary in OpenRC
All, We got a request from Debian to rename the rc binary of OpenRC due to a naming conflict they have. They have a port of the att plan 9 shell, which has a binary named rc as well[1]. My thought is to rename our rc to openrc, since that would be unique. I know at least one thing that will break is everyone's inittab, so should I sed their inittab in our live ebuild or expect them to fix it and give a warning? I know that once OpenRC with this change is released, it will need to probably be p.masked until there is a new release of sysvinit that updates the inittab. I'm not sure what else will break. Does anyone have any ideas wrt other things to look for, or should I make the changes upstream and have people let us know what else breaks? William [1] https://bugs.gentoo.org/show_bug.cgi?id=493958 signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: renaming rc binary in OpenRC
On Wed, Dec 11, 2013 at 10:41 PM, William Hubbs willi...@gentoo.org wrote: All, We got a request from Debian to rename the rc binary of OpenRC due to a naming conflict they have. They have a port of the att plan 9 shell, which has a binary named rc as well[1]. My thought is to rename our rc to openrc, since that would be unique. I know at least one thing that will break is everyone's inittab, so should I sed their inittab in our live ebuild or expect them to fix it and give a warning? I know that once OpenRC with this change is released, it will need to probably be p.masked until there is a new release of sysvinit that updates the inittab. I'm not sure what else will break. Does anyone have any ideas wrt other things to look for, or should I make the changes upstream and have people let us know what else breaks? are you going to rename also rc-service and rc-update? William [1] https://bugs.gentoo.org/show_bug.cgi?id=493958
Re: [gentoo-dev] rfc: renaming rc binary in OpenRC
On 12/11/2013 3:41 PM, William Hubbs wrote: All, We got a request from Debian to rename the rc binary of OpenRC due to a naming conflict they have. They have a port of the att plan 9 shell, which has a binary named rc as well[1]. My thought is to rename our rc to openrc, since that would be unique. I know at least one thing that will break is everyone's inittab, so should I sed their inittab in our live ebuild or expect them to fix it and give a warning? I know that once OpenRC with this change is released, it will need to probably be p.masked until there is a new release of sysvinit that updates the inittab. I'm not sure what else will break. Does anyone have any ideas wrt other things to look for, or should I make the changes upstream and have people let us know what else breaks? William [1] https://bugs.gentoo.org/show_bug.cgi?id=493958 The idea of running a sed on inittab in an ebuild, no matter what the context, terrifies me. Perhaps we can ease this in slowly by renaming rc - openrc and symlinking rc - openrc and making a release with that change concurrent with a news item? Or even just do that in the ebuild rather than in the actual sources. I don't think Debian will keel over and die if it takes a little extra time for the change to go through, and it beats a ton of broken systems. Chris Reffett
Re: [gentoo-dev] rfc: renaming rc binary in OpenRC
On 12/11/2013 08:47 PM, Chris Reffett wrote: On 12/11/2013 3:41 PM, William Hubbs wrote: All, We got a request from Debian to rename the rc binary of OpenRC due to a naming conflict they have. They have a port of the att plan 9 shell, which has a binary named rc as well[1]. My thought is to rename our rc to openrc, since that would be unique. I know at least one thing that will break is everyone's inittab, so should I sed their inittab in our live ebuild or expect them to fix it and give a warning? I know that once OpenRC with this change is released, it will need to probably be p.masked until there is a new release of sysvinit that updates the inittab. I'm not sure what else will break. Does anyone have any ideas wrt other things to look for, or should I make the changes upstream and have people let us know what else breaks? William [1] https://bugs.gentoo.org/show_bug.cgi?id=493958 The idea of running a sed on inittab in an ebuild, no matter what the context, terrifies me. Perhaps we can ease this in slowly by renaming rc - openrc and symlinking rc - openrc and making a release with that change concurrent with a news item? Or even just do that in the ebuild rather than in the actual sources. I don't think Debian will keel over and die if it takes a little extra time for the change to go through, and it beats a ton of broken systems. Chris Reffett +1 The ebuild can grep the inittab and it if finds an rc there, just print a huge warning telling the user to migrate || die. -- Regards, Markos Chandras
Re: [gentoo-dev] rfc: renaming rc binary in OpenRC
[I'm not the OpenRC maintainer, I'm only on gentoo-devel because I'm generally interested, and I saw this, I'm not speaking for zigo or anything here.] On Wed, Dec 11, 2013 at 03:47:57PM -0500, Chris Reffett wrote: The idea of running a sed on inittab in an ebuild, no matter what the context, terrifies me. Perhaps we can ease this in slowly by renaming rc - openrc and symlinking rc - openrc and making a release with that change concurrent with a news item? Or even just do that in the ebuild rather than in the actual sources. I don't think Debian will keel over and die if it takes a little extra time for the change to go through, and it beats a ton of broken systems. Chris Reffett Hi, Gentoo (and hello world), I'm breaking my streak of lurking to comment generally on the Debian procedure here. I'm sure the Debian folks would be happy to strip the symlink from the deb over having to patch OpenRC's rc binary = openrc against the upstream source. Shipping /usr/bin/rc = /usr/bin/openrc would be totally cool for Debian, I believe. Hopefully the OpenRC team will come in and correct me if I'm wrong :) Fondly, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: renaming rc binary in OpenRC
On Wed, Dec 11, 2013 at 10:47:49PM +0200, Alon Bar-Lev wrote: On Wed, Dec 11, 2013 at 10:41 PM, William Hubbs willi...@gentoo.org wrote: All, We got a request from Debian to rename the rc binary of OpenRC due to a naming conflict they have. They have a port of the att plan 9 shell, which has a binary named rc as well[1]. My thought is to rename our rc to openrc, since that would be are you going to rename also rc-service and rc-update? No, there isn't a need for that, just rc. William signature.asc Description: Digital signature
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On Wed Dec 11 23:30:58 2013 Peter Stuge pe...@stuge.se wrote: Pacho Ramos wrote: Last time I checked, vixie-cron upstream was died while cronie forked it fixing some bugs :/ What do you think? I think that nobody who is not intimately familiar with the development in both projects can think anything that is actionable. vixie-cron upstream is dead and this is a well-known fact. Example of development in vixie-cron project: https://bugs.gentoo.org/show_bug.cgi?id=308055 -- Alexander Tsoy
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
Markos Chandras wrote: Last time I checked, vixie-cron upstream was died If vixie-cron upstream is dead as you say Define dead? //Peter
Re: [gentoo-dev] rfc: renaming rc binary in OpenRC
On 12/11/2013 08:56 PM, Paul Tagliamonte wrote: [I'm not the OpenRC maintainer, I'm only on gentoo-devel because I'm generally interested, and I saw this, I'm not speaking for zigo or anything here.] On Wed, Dec 11, 2013 at 03:47:57PM -0500, Chris Reffett wrote: The idea of running a sed on inittab in an ebuild, no matter what the context, terrifies me. Perhaps we can ease this in slowly by renaming rc - openrc and symlinking rc - openrc and making a release with that change concurrent with a news item? Or even just do that in the ebuild rather than in the actual sources. I don't think Debian will keel over and die if it takes a little extra time for the change to go through, and it beats a ton of broken systems. Chris Reffett Hi, Gentoo (and hello world), I'm breaking my streak of lurking to comment generally on the Debian procedure here. I'm sure the Debian folks would be happy to strip the symlink from the deb over having to patch OpenRC's rc binary = openrc against the upstream source. Shipping /usr/bin/rc = /usr/bin/openrc would be totally cool for Debian, I believe. Hopefully the OpenRC team will come in and correct me if I'm wrong :) Fondly, Paul If that's the case then I see no reason to go through the migration path for users :) The symlink thing can be done immediately. I am wondering, wouldn't Debian be able to rename rc to openrc in their openrc package just before merging it to the read filesystem (I assume Debian also builds and installs in sandbox first?)? In this case we will not have to touch openrc (or the ebuild) at all. -- Regards, Markos Chandras
Re: [gentoo-dev] rfc: renaming rc binary in OpenRC
On Wed, Dec 11, 2013 at 09:09:16PM +, Markos Chandras wrote: If that's the case then I see no reason to go through the migration path for users :) The symlink thing can be done immediately. Awesome. Great to hear it! I am wondering, wouldn't Debian be able to rename rc to openrc in their openrc package just before merging it to the read filesystem (I assume Debian also builds and installs in sandbox first?)? In this case we will not have to touch openrc (or the ebuild) at all. Again, I'm not the maintainer, so don't hold me to this - but I remember hearing something about something somewhere thinking the name is `rc', even after moving the binary out of the way. It'd also be great to have a similar setup in Gentoo and Debian, but I can clearly see how Gentoo'ers would be resistant to such a tough change to make. -- Regards, Markos Chandras Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
[gentoo-dev] some multilib-minimal enhancements [0/6]: de-headerization
sorry for attaching these rather than in-lining but google insists on 78-wrapping plain-text e-mail. If HTML mail would be a better solution for people I'd be happy to re-send (unless maybe a single person requests it and a chorus of objections are raised :P). This series is available also in bug #493214. --- orig/multilib-minimal.eclass 2013-12-03 02:02:51.874201632 -0800 +++ 000-header/multilib-minimal.eclass 2013-12-03 02:13:48.115445273 -0800 @@ -1,6 +1,6 @@ # Copyright 1999-2013 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/eclass/multilib-minimal.eclass,v 1.6 2013/10/20 16:27:24 hasufell Exp $ +# $Header: $ # @ECLASS: multilib-minimal.eclass # @MAINTAINER:
[gentoo-dev] some multilib-minimal enhancements [1/6]: some debug-print-function boilerplate
Groking flow-of-control in multibuild-based ebuilds is
nontrivial. These can help.
--- 000-header/multilib-minimal.eclass 2013-12-03 02:13:48.115445273 -0800
+++ 001-debug-print-function/multilib-minimal.eclass 2013-12-03 02:17:30.144384409 -0800
@@ -36,7 +36,11 @@ EXPORT_FUNCTIONS src_configure src_compi
multilib-minimal_src_configure() {
+ debug-print-function ${FUNCNAME} $@
+
multilib-minimal_abi_src_configure() {
+ debug-print-function ${FUNCNAME} $@
+
mkdir -p ${BUILD_DIR} || die
pushd ${BUILD_DIR} /dev/null || die
if declare -f multilib_src_configure /dev/null ; then
@@ -51,7 +55,11 @@ multilib-minimal_src_configure() {
}
multilib-minimal_src_compile() {
+ debug-print-function ${FUNCNAME} $@
+
multilib-minimal_abi_src_compile() {
+ debug-print-function ${FUNCNAME} $@
+
pushd ${BUILD_DIR} /dev/null || die
if declare -f multilib_src_compile /dev/null ; then
multilib_src_compile
@@ -65,7 +73,11 @@ multilib-minimal_src_compile() {
}
multilib-minimal_src_test() {
+ debug-print-function ${FUNCNAME} $@
+
multilib-minimal_abi_src_test() {
+ debug-print-function ${FUNCNAME} $@
+
pushd ${BUILD_DIR} /dev/null || die
if declare -f multilib_src_test /dev/null ; then
multilib_src_test
@@ -79,7 +91,11 @@ multilib-minimal_src_test() {
}
multilib-minimal_src_install() {
+ debug-print-function ${FUNCNAME} $@
+
multilib-minimal_abi_src_install() {
+ debug-print-function ${FUNCNAME} $@
+
pushd ${BUILD_DIR} /dev/null || die
if declare -f multilib_src_install /dev/null ; then
multilib_src_install
[gentoo-dev] some multilib-minimal enhancements [2/6]: add frob for consumers to disable automagic header wrapping
Add a MULTILIB_INSECURE_INSTALL variable to eclass/multilib-minimal.eclass
Sometimes the multilib magic header business is an unwanted
feature. For example, it is infuriating to be forced
to wrap a header file (or, less offensively, but still quite
offensively, to be forced to implement inter-ABI
header-smuggling code) just to appease multilib_check_headers,
in the case where an ABI-specific header triggers a multilib_check_headers
failure.
This provides a frob to turn the whole thing off, collisions be
damned. Arguably, it would be better to have a per-header frob,
as well, but this this is better than nothing and trivial to implement.
--- 001-debug-print-function/multilib-minimal.eclass 2013-12-03 02:17:30.144384409 -0800
+++ 002-MULTILIB_INSECURE_INSTALL/multilib-minimal.eclass 2013-12-03 02:23:06.888008751 -0800
@@ -29,6 +29,20 @@ case ${EAPI:-0} in
*) die EAPI=${EAPI} is not supported ;;
esac
+# @ECLASS-VARIABLE: MULTILIB_INSECURE_INSTALL
+# @DEFAULT-UNSET
+# @DESCRIPTION:
+# If set to a nonempty value, multilib-minimal_src_install will not perform
+# automatic checking of headers for inter-ABI conflicts, nor will it automate
+# wrapping of header files. Instead, multilib_src_install pseudophases will
+# run without any special protection and the MULTILIB_WRAPPED_HEADERS array
+# will be ignored.
+# See:
+# @CODE@
+# http://devmanual.gentoo.org/eclass-reference/multilib-build.eclass/index.html
+# @CODE@
+# (or the multilib-build.eclass source itself) for further information about this
+# feature.
inherit eutils multilib-build
@@ -108,15 +122,19 @@ multilib-minimal_src_install() {
emake DESTDIR=${D} install
fi
fi
- # Do multilib magic only when 1 ABI is used.
- if [[ ${#MULTIBUILD_VARIANTS[@]} -gt 1 ]]; then
+
+ # Do multilib magic only when 1 ABI is used and
+ # MULTILIB_INSECURE_INSTALL is not set
+ if [[ ${#MULTIBUILD_VARIANTS[@]} -gt 1 \
+ -z ${MULTILIB_INSECURE_INSTALL} ]]; then
multilib_prepare_wrappers
multilib_check_headers
fi
popd /dev/null || die
}
multilib_foreach_abi multilib-minimal_abi_src_install
- multilib_install_wrappers
+
+ [[ ${MULTILIB_INSECURE_INSTALL} ]] || multilib_install_wrappers
if declare -f multilib_src_install_all /dev/null ; then
multilib_src_install_all
[gentoo-dev] some multilib-minimal enhancements [3/6]: a shitload of in-source doc
This rewrites the multilib-minimal.eclass in-source documentation,
providing considerably more hand-holding for end-users, exploring
some pitfalls that users may encounter, and clarifying some
less-than lucid language.
It also reverses an existing in-source comment about inheritance
ordering, which, I presume, was a thinko, and provides some
background about why it matters.
--- 002-MULTILIB_INSECURE_INSTALL/multilib-minimal.eclass 2013-12-03 02:23:06.888008751 -0800
+++ 003-in-source-doc/multilib-minimal.eclass 2013-12-03 02:45:19.428664959 -0800
@@ -7,23 +7,102 @@
# Julian Ospald hasuf...@gentoo.org
# @BLURB: wrapper for multilib builds providing convenient multilib_src_* functions
# @DESCRIPTION:
+# multilib-minimal implements src_configure, src_compile, src_test
+# and src_install, and invokes callbacks which may be used by multi-abi
+# ebuilds and eclasses to cleanly separate per-ABI and global logic
+# within their implementations. It also provides logic to ensure that
+# ABI's do not scribble over each other's header files during installation.
#
-# src_configure, src_compile, src_test and src_install are exported.
+# To use multilib-minimal.eclass, inherit from it normally and implement
+# functions named multilib_phase (i.e.: multilib_src_install) containing
+# code which must run once for each ABI. multilib-minimal will invoke your
+# callback repeatedly and automatically, once for each active ABI,
+# with essential abi-specific settings for variables such as CFLAGS
+# automatically exported.
#
-# Use multilib_src_* instead of src_* which runs this phase for
-# all enabled ABIs.
+# Be advised that, for now at least, some features of
+# toolchain-funcs.eclass, specifically, those that
+# retrieve those same variables, will not work as expected, as this
+# eclass knows nothing about multilib-minimal and will return values
+# suitable only for the native ABI.
#
-# multilib-minimal should _always_ go last in inherit order!
+# A simple workaround for this limitation is to check if a variable is
+# already defined before querying toolchain-funcs. For example:
+#
+# @CODE@
+# local CC=${CC:-$(tc-getCC)}
+# @CODE
+#
+# It is also important to make sure that your ebuild or eclass's dependencies
+# correctly reflect build- and run-time dependencies of each active ABI.
+# This can be simplified by using the ${MULTILIB_USEDEP} variable during
+# construction of *DEPEND variables. Note that not all dependencies
+# will require this; a judgement call will need to be made for each
+# dependency when porting existing ebuilds. See:
+# @CODE@
+# http://devmanual.gentoo.org/eclass-reference/multilib-build.eclass/index.html
+# @CODE@
+# for more information.
+#
+# Another snag you may encounter is that, in many circumstances, it is possible
+# for variables to flow between multilib_phase functions. This is because
+# no subshell is utilized.
+# Extreme care must sometimes be taken to ensure that different ABI's don't
+# trample each other's variables.
+#
+# A reasonable precaution against this type of problem would be to localize
+# certian variables to the multilib_phase function, for example:
+#
+# @CODE@
+# multilib_src_configure() {
+# local CFLAGS=${CFLAGS} CXXFLAGS=${CXXFLAGS}
+# local FFLAGS=${FFLAGS} FCFLAGS=${FCFLAGS}
+# if [[ ${CHOST} == *x86_64* ]] ; then
+# append-flags -foo_flag -bar_flag
+# fi
+# @CODE@
+#
+# However, this approach can create subtly confusing behavior. When porting
+# traditional phase-function-based code to multilib minimal, keep an eye out
+# for code that assumes variables defined in a prior phase function will persist
+# in subsequent phases. Depending on a number of factors, this may not
+# be the case -- it certainly will not, if you have localized variables as above.
+#
+# Eventually, a feature allowing reliable automatic variable persistence across
+# multilib_phase functions may be added, so, for the moment, it is best to
+# avoid any assumption about variable persistence, for example, by isolating
+# variable setup code in a convenience function which is invoked at the outset
+# of each multilib_phase function, or, where possible, by refactoring code
+# to avoid the use of persistent variables entirely.
#
# If you want to use in-source builds, then you must run
-# multilib_copy_sources at the end of src_prepare!
-# Also make sure to set correct variables such as
+# multilib_copy_sources at the end of src_prepare.
+# Also make sure to correctly set ECONF_SOURCE, i.e.,
+#
+# @CODE@
# ECONF_SOURCE=${S}
+# @CODE@
#
-# If you need generic install rules, use multilib_src_install_all function.
-
+# as out-of-tree builds will not be building in the same directory as
+# the configure script.
+#
+# EAPI = 4 is required by multilib minimial, as without it,
+# the ${MULTILIB_USEDEP} variable cannot be correctly implemented.
+#
+# Note: inheritance order matters when inheriting from multiple
+# eclasses. In particular, it is important to
[gentoo-dev] some multilib-minimal enhancements [4/6]: ubiquitous multilib-phase-all callbacks
This patch adds multilib_src_{configure,compile,test}_all
callbacks, analogous to the existing multilib_src_install_all
callback.
--- 003-in-source-doc/multilib-minimal.eclass 2013-12-03 02:45:19.428664959 -0800
+++ 004-multilib-phase-all/multilib-minimal.eclass 2013-12-03 02:54:40.045335905 -0800
@@ -86,6 +86,20 @@
# as out-of-tree builds will not be building in the same directory as
# the configure script.
#
+# Non-abi-specific functionality is accomodated by an additional
+# set of callbacks, the multilib_phase_all functions.
+#
+# multilib_phase_all is called once only, after the per-ABI
+# multilib_src_phase functions complete, with BUILD_DIR and
+# the current working directory set to the same values as they
+# were when multilib-minimal_phase was invoked.
+# mutilib_src_configure is an exception; it runs before the
+# per-ABI configure steps. Consumers may also implement their
+# own phase functions, and invoke multilib-minimal_phase
+# directly; doing so is mostly equivalent to
+# implementing multilib_src_phase_all, although it may result
+# in more confusing code.
+#
# EAPI = 4 is required by multilib minimial, as without it,
# the ${MULTILIB_USEDEP} variable cannot be correctly implemented.
#
@@ -144,6 +158,9 @@ multilib-minimal_src_configure() {
popd /dev/null || die
}
+ if declare -f multilib_src_configure_all /dev/null ; then
+ multilib_src_configure_all
+ fi
multilib_foreach_abi multilib-minimal_abi_src_configure
}
@@ -163,6 +180,9 @@ multilib-minimal_src_compile() {
}
multilib_foreach_abi multilib-minimal_abi_src_compile
+ if declare -f multilib_src_compile_all /dev/null ; then
+ multilib_src_compile_all
+ fi
}
multilib-minimal_src_test() {
@@ -181,6 +201,9 @@ multilib-minimal_src_test() {
}
multilib_foreach_abi multilib-minimal_abi_src_test
+ if declare -f multilib_src_test_all /dev/null ; then
+ multilib_src_test_all
+ fi
}
multilib-minimal_src_install() {
[gentoo-dev] some multilib-minimal enhancements [6/6]: update authorship metadata
That's all folks! Let the flame-war begin! :P -gmt P.S., stay tuned, there's more where these came from. --- 005-MULTILIB_PARALLEL_PHASES/multilib-minimal.eclass 2013-12-03 02:59:33.687448429 -0800 +++ 006-authors/multilib-minimal.eclass 2013-12-03 03:03:07.574913106 -0800 @@ -5,6 +5,10 @@ # @ECLASS: multilib-minimal.eclass # @MAINTAINER: # Julian Ospald hasuf...@gentoo.org +# @AUTHOR: +# Julian Ospald hasuf...@gentoo.org +# Michał Górny mgo...@gentoo.org +# Greg Turner g...@be-evil.net # @BLURB: wrapper for multilib builds providing convenient multilib_src_* functions # @DESCRIPTION: # multilib-minimal implements src_configure, src_compile, src_test
[gentoo-dev] some multilib-minimal enhancements [5/6]: add frob to control phase parallelization
This patch adds a new frob, MULTILIB_PARALLEL_PHASES, to
multlib-minimal.eclass, which implements eclass-consumer-selectable
parallelization of src_configure, src_compile, and src_test.
By default, all parallelization is deactivated, which represents
a change from the previous gentoo-x86 behavior (which was
parallelizing src_configure automatically).
--- 004-multilib-phase-all/multilib-minimal.eclass 2013-12-03 02:54:40.045335905 -0800
+++ 005-MULTILIB_PARALLEL_PHASES/multilib-minimal.eclass 2013-12-03 02:59:33.687448429 -0800
@@ -45,8 +45,8 @@
# for more information.
#
# Another snag you may encounter is that, in many circumstances, it is possible
-# for variables to flow between multilib_phase functions. This is because
-# no subshell is utilized.
+# for variables to flow between multilib_phase functions. This is because,
+# unless you parallelize the phase in question, no subshell is utilized.
# Extreme care must sometimes be taken to ensure that different ABI's don't
# trample each other's variables.
#
@@ -122,6 +122,58 @@ case ${EAPI:-0} in
*) die EAPI=${EAPI} is not supported ;;
esac
+# @ECLASS-VARIABLE: MULTILIB_PARALLEL_PHASES
+# @DEFAULT-UNSET
+# @DESCRIPTION:
+# multilib-minimal.eclass consumers may set this to a string containing
+# a space-separated list of phase-function names, like so:
+#
+# @CODE@
+# MULTILIB_PARALLEL_PHASES=src_configure src_test
+# @CODE@
+#
+# For each (supported) phase-function name in the list, the corresponding
+# multilib-minimal_phase phase function will execute in parallel, in
+# the sense that, within limits (set by multiprocessing.eclass) the
+# multilib_phase function invocations (or, if none is present, the
+# built-in default implementation) for each ABI will run simultaneously.
+#
+# Any phase-function-names not specified are executed serially, with the
+# native ABI coming last.
+#
+# It is OK to add extra bonus whitespace or duplicated values.
+# Changes take effect immediately, so it may be set before or after
+# inheriting multilib-minimal, or even during execution of a phase function
+# (but not in parallelized multilib_phase functions; see below).
+#
+# By default, MULTILIB_PARALLEL_PHASES is empty. Consuming eclasses could
+# override this default by setting a new default before the inherits clause.
+# For example,
+#
+# @CODE
+# : {MULTILIB_PARALLEL_PHASES:=src_configure}
+# inherit multilib-minimal
+# @CODE
+#
+# would create a default behavior of parallel src_configure. The question
+# of whether, in practice, eclasses ever should do so is potentially
+# complicated; you'll have to figure that out for yourself.
+#
+# Supported phase-function-names are: src_configure, src_compile, and src_test.
+# All other values are silently ignored.
+#
+# Note that parallel execution can lead to ugly -- and sometimes very, very ugly --
+# console output at build-time. Consumers of multilib-minimal.eclass
+# may wish to consider activating less verbose build-time output modes, if they are
+# readily available, to mitigate this effect, although doing so goes against a
+# long-standing Gentoo tradition and might make debugging a hassle for bugzilla
+# and IRC participants, so use your best judgement.
+#
+# A handy per-ABI log is kept in ${T}/build-${ABI}.log by multibuild.eclass.
+# Debugging and bug-reporting may also benefit (unless your bug specifically
+# pertains to parallelization) from setting MAKEOPTS=-j1, which will prevent
+# parallelization entirely.
+
# @ECLASS-VARIABLE: MULTILIB_INSECURE_INSTALL
# @DEFAULT-UNSET
# @DESCRIPTION:
@@ -161,7 +213,12 @@ multilib-minimal_src_configure() {
if declare -f multilib_src_configure_all /dev/null ; then
multilib_src_configure_all
fi
- multilib_foreach_abi multilib-minimal_abi_src_configure
+
+ if has src_configure ${MULTILIB_PARALLEL_PHASES} ; then
+ multilib_parallel_foreach_abi multilib-minimal_abi_src_configure
+ else
+ multilib_foreach_abi multilib-minimal_abi_src_configure
+ fi
}
multilib-minimal_src_compile() {
@@ -179,7 +236,12 @@ multilib-minimal_src_compile() {
popd /dev/null || die
}
- multilib_foreach_abi multilib-minimal_abi_src_compile
+ if has src_compile ${MULTILIB_PARALLEL_PHASES} ; then
+ multilib_parallel_foreach_abi multilib-minimal_abi_src_compile
+ else
+ multilib_foreach_abi multilib-minimal_abi_src_compile
+ fi
+
if declare -f multilib_src_compile_all /dev/null ; then
multilib_src_compile_all
fi
@@ -200,7 +262,12 @@ multilib-minimal_src_test() {
popd /dev/null || die
}
- multilib_foreach_abi multilib-minimal_abi_src_test
+ if has src_test ${MULTILIB_PARALLEL_PHASES} ; then
+ multilib_parallel_foreach_abi multilib-minimal_abi_src_test
+ else
+ multilib_foreach_abi multilib-minimal_abi_src_test
+ fi
+
if declare -f multilib_src_test_all /dev/null ; then
multilib_src_test_all
fi
Re: [gentoo-dev] rfc: renaming rc binary in OpenRC
On Wed, Dec 11, 2013 at 3:47 PM, Chris Reffett creff...@gentoo.org wrote: The idea of running a sed on inittab in an ebuild, no matter what the context, terrifies me. Perhaps we can ease this in slowly by renaming rc - openrc and symlinking rc - openrc and making a release with that change concurrent with a news item? Or even just do that in the ebuild rather than in the actual sources. I don't think Debian will keel over and die if it takes a little extra time for the change to go through, and it beats a ton of broken systems. ++ No reason the symlink couldn't be done in the ebuild either - which keeps the package itself clean. There could be news to clean up inittab and such, and then perhaps down the road the compat symlink could be removed. Nice to see interest in Debian (granted, I know there was interest quite a while back). Having more and better options is just good for everybody - I'd like to see OpenRC become the best traditional-style service manager around (though honestly I'd be hard-pressed to think of any that are quite as good already). I think one thing that would be nice to dream about someday would be a systemd-compatibility init.d script. That would be symlinked to a service name just like a typical network interface script, and would look for a unit file and interpret it (perhaps just taking a path from conf.d). I'd think it wouldn't be hard to do, setting aside the more active-management features of systemd. Rich
[gentoo-dev] Re: rfc: renaming rc binary in OpenRC
Markos Chandras posted on Wed, 11 Dec 2013 20:53:04 + as excerpted: On 12/11/2013 08:47 PM, Chris Reffett wrote: On 12/11/2013 3:41 PM, William Hubbs wrote: My thought is to rename our rc to openrc, since that would be unique. I know at least one thing that will break is everyone's inittab, so should I sed their inittab in our live ebuild or expect them to fix it and give a warning? I know that once OpenRC with this change is released, it will need to probably be p.masked until there is a new release of sysvinit that updates the inittab. The idea of running a sed on inittab in an ebuild, no matter what the context, terrifies me. Perhaps we can ease this in slowly by renaming rc - openrc and symlinking rc - openrc and making a release with that change concurrent with a news item? Or even just do that in the ebuild rather than in the actual sources. I don't think Debian will keel over and die if it takes a little extra time for the change to go through, and it beats a ton of broken systems. +1 The ebuild can grep the inittab and it if finds an rc there, just print a huge warning telling the user to migrate || die. I think it's worth noting two small details of williamh's original mail that may have gone unnoticed: 1) He proposes seding the *LIVE* ebuild, which I take as meaning openrc-. 2) He then proposes p.masking an openrc release until a sysvinit release updating inittab, with the contrast between that and the LIVE ebuild proposal thus again emphasized. Question: How many people run the openrc- LIVE ebuild, and given that it's masked and general gentoo policy is that people running live ebuilds should expect to keep the pieces of they can't handle occasionally unpredicted changes, how much should we actually worry about doing just that? *I ask the above as an openrc- user myself! Of course, I also not only follow this list for heads-up notes such as this, but I also have a partially scripted update routine that checks openrc for changes every time I update, runs git log to check them out if there are any, and further runs git show on anything that I have questions about, *BEFORE* I actually do the update. There's certainly a small window between my checks and the actual run of the openrc emerge, during which a git commit or two might in theory slip in, but other than that, I'd see such a change BEFORE I ever actually installed that openrc live update in the first place. As a result, while I probably wouldn't have noted the linkage to inittab without this mail, I would have at least been aware of the name change when I did that live-build update, and would be prepared to boot with init=/bin/bash and find the problem, should it come to that, as I know it well might given the live-ebuild I choose to run. Meanwhile, given the openrc- bug history, with me as about the only bug reporter, I don't think there's that many actually running it. Certainly nothing I'd qualify as a ton of broken systems even if there's no sed and every one of those running it fails to see the warning until they've rebooted and suffered the consequences. And the p.mask proposal for an actual release with the change, until a parallel sysvinit package update likely unmasked at the same time, does sound appropriately more responsible for ~arch as well, thus making both proposals at least not entirely insane. Tho I too am a bit uncomfortable about sedding inittab directly from the ebuild. Assuming it can work, the more gradual symlink and safer grep proposals sound much more reasonable, even at the live ebuild level. Tho that said, given that I /am/ running a live ebuild for something as critical as openrc, if sed screws up and replaces the current inittab with an empty file, I'd better be prepared to deal with it. That's part of the risk I took when unmasking that ebuild. Now I'd be rather more annoyed if the ebuild pulled a trick like I did in one of my own scripts a few years ago, such that I used the wrong variable name as the absolute prefix to a rm command run as root, and said mis-named variable ended up null... I was brown-bagging /that/ one for a few days! =:^\ But killing a single inittab file, meh! If I can't deal with that, I've no business running an openrc- version! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] some multilib-minimal enhancements [4/6]: ubiquitous multilib-phase-all callbacks
I'd actually consider to remove all *_all phases since you can achive
the same via:
src_install() {
multilib-minimal_src_install
generic install crap || die
}
and have more control over the call order.
But then again that will change behavior. So I am not sure about this
feature.
Re: [gentoo-dev] some multilib-minimal enhancements [2/6]: add frob for consumers to disable automagic header wrapping
On 12/11/2013 10:18 PM, Greg Turner wrote: this needs more explanation. Why do we want this?
Re: [gentoo-dev] some multilib-minimal enhancements [6/6]: update authorship metadata
It should be made clear who is the initial/original author. Maintainer can be quite anyone.
Re: [gentoo-dev] some multilib-minimal enhancements [4/6]: ubiquitous multilib-phase-all callbacks
On Wed, 11 Dec 2013, hasufell wrote:
I'd actually consider to remove all *_all phases since you can achive
the same via:
src_install() {
multilib-minimal_src_install
generic install crap || die
}
and have more control over the call order.
It's not completely equivalent: In the above code the einstalldocs
function will be called from multilib-minimal_src_install, whereas
with multilib_src_install_all it won't be called.
Is there actually a need for *_all, apart from the src_install phase?
Ulrich
Re: [gentoo-dev] some multilib-minimal enhancements [0/6]: de-headerization
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 we will need to wait for @multilib to comment as well, because multilib-minimal is used in autotools-multilib.eclass and netsurf.eclass -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSqN2NAAoJEFpvPKfnPDWzqdcH/2K78g4yCGmvLCweUPfLo1TI xa/S1gKFChQpmMQHdEnvJNGVB04fP7y+0UAUZ7JuzQOzqUGpFaMRDrgXutrkLCtm 7LHFfuxDlcQRtw3OECsbJ10bPXNQJbx6+ttU90omRuN9w/ckZcYrpxb6Vngto/k0 Fkrljm8N2z7spCM1rq9iLW93w40WUmvFxriU3RCQClvb3GmKDdAZy7R1m6Kv4W2R e1IQsw801O5gGL9LVha8nsSczYGdHNd5QKrmjo5RbsSQ/0z3/2sQx7QnJM6R0k9A GC2bLHcVe2JnpW26WX2VnfURxO0LAFIcR8IaY4wK1+DGIHgqNnZbYkHcAC0Fxd8= =TwJe -END PGP SIGNATURE-
Re: [gentoo-dev] some multilib-minimal enhancements [4/6]: ubiquitous multilib-phase-all callbacks
On 12/11/2013 10:47 PM, Ulrich Mueller wrote:
On Wed, 11 Dec 2013, hasufell wrote:
I'd actually consider to remove all *_all phases since you can achive
the same via:
src_install() {
multilib-minimal_src_install
generic install crap || die
}
and have more control over the call order.
It's not completely equivalent: In the above code the einstalldocs
function will be called from multilib-minimal_src_install, whereas
with multilib_src_install_all it won't be called.
Is there actually a need for *_all, apart from the src_install phase?
Ulrich
I personally don't feel like it. But yeah... src_install was a bit
special, so that's why I did that.
What do the other multilib people think about it?
Re: [gentoo-dev] some multilib-minimal enhancements [3/6]: a shitload of in-source doc
On 12/11/2013 10:18 PM, Greg Turner wrote: I actually feel that some parts of this is not documentation, but rather wiki. So maybe that's exactly where to put it? The doc in the eclass should only describe the behavior of the eclass and the main points you need to know in order to get it going. But it is not a strong feeling. +# it is often best to put multilib-minimal first on the inherits list. first? You mean last or what?
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On Wed, Dec 11, 2013 at 1:30 PM, Peter Stuge pe...@stuge.se wrote: I think that nobody who is not intimately familiar with the development in both projects can think anything that is actionable. It's insulting to see how people all over the internet run as fast as they possibly can in whatever direction even though they have nearly zero detailed understanding of the options they are choosing between. Suggesting cronie in the handbook seems like a no-brainer. Do you have some information on vixie-cron that we're all missing? -Ben
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.12.2013 22:07, Peter Stuge wrote: If vixie-cron upstream is dead as you say Define dead? The latest upstream release is this: cron_4.1.shar 2004-Jan-23 19:20:23200.7K application/octet-stream As you can see, it will turn ten soon. Of course, distros are patching the crap out of it but nobody ever took over maintenance. RedHat instead forked it about six years ago and called it cronie. ISC, who released the above version, don't even list it any more among their software. I daresay that's basically the very definition of dead. - -- Best regards, Wulf -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKo44EACgkQnuVXRcSi+5oJNgCeKpeeyFmxEJ462GnfQaboBDV+ ubAAni1jxYpGfrD63CiJmw7vKRfsrSnJ =fPPx -END PGP SIGNATURE-
Re: [gentoo-dev] some multilib-minimal enhancements [5/6]: add frob to control phase parallelization
Dnia 2013-12-11, o godz. 13:19:04 Greg Turner g...@malth.us napisał(a): Very limited usefulness, a lot of extra complexity. We'd rather work on making eclasses simpler. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: renaming rc binary in OpenRC
On Wed, Dec 11, 2013 at 09:28:09PM +, Duncan wrote: Markos Chandras posted on Wed, 11 Dec 2013 20:53:04 + as excerpted: On 12/11/2013 08:47 PM, Chris Reffett wrote: On 12/11/2013 3:41 PM, William Hubbs wrote: My thought is to rename our rc to openrc, since that would be unique. I know at least one thing that will break is everyone's inittab, so should I sed their inittab in our live ebuild or expect them to fix it and give a warning? I know that once OpenRC with this change is released, it will need to probably be p.masked until there is a new release of sysvinit that updates the inittab. The idea of running a sed on inittab in an ebuild, no matter what the context, terrifies me. Perhaps we can ease this in slowly by renaming rc - openrc and symlinking rc - openrc and making a release with that change concurrent with a news item? Or even just do that in the ebuild rather than in the actual sources. I don't think Debian will keel over and die if it takes a little extra time for the change to go through, and it beats a ton of broken systems. +1 The ebuild can grep the inittab and it if finds an rc there, just print a huge warning telling the user to migrate || die. I think it's worth noting two small details of williamh's original mail that may have gone unnoticed: 1) He proposes seding the *LIVE* ebuild, which I take as meaning openrc-. 2) He then proposes p.masking an openrc release until a sysvinit release updating inittab, with the contrast between that and the LIVE ebuild proposal thus again emphasized. Question: How many people run the openrc- LIVE ebuild, and given that it's masked and general gentoo policy is that people running live ebuilds should expect to keep the pieces of they can't handle occasionally unpredicted changes, how much should we actually worry about doing just that? We don't have to worry about the live ebuild per se, I was more concerned about what to do when the next release comes out. Duncan, it sounds like you would know how to recover with the live ebuild. But, with the proposal of creating a symlink from /sbin/rc-openrc, there would no longer be a reason to p.mask the next release, because people would be able to upgrade. A news item would definitely be appropriate though. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: renaming rc binary in OpenRC
On Wed, Dec 11, 2013 at 09:09:16PM +, Markos Chandras wrote: If that's the case then I see no reason to go through the migration path for users :) The symlink thing can be done immediately. I am wondering, wouldn't Debian be able to rename rc to openrc in their openrc package just before merging it to the read filesystem (I assume Debian also builds and installs in sandbox first?)? In this case we will not have to touch openrc (or the ebuild) at all. No, because of the symlinks that we point to it. Remember that rc is a multi-call binary. for example, all of the symlinks in /lib*/rc/bin will have to be adjusted. William signature.asc Description: Digital signature
Re: [gentoo-dev] some multilib-minimal enhancements [4/6]: ubiquitous multilib-phase-all callbacks
Dnia 2013-12-11, o godz. 13:18:54
Greg Turner g...@malth.us napisał(a):
This patch adds multilib_src_{configure,compile,test}_all
callbacks, analogous to the existing multilib_src_install_all
callback.
No real benefit in having those. They will introduce more confusion
because -- as hasufell pointed out -- you can do the same without those.
src_install() is special because:
a) it has default doc install. Others don't have default non-ABI stuff
to do.
b) it's quite common.
Playing similarly with src_compile() is not really beneficial. You can
achieve almost everything you need with either
'if multilib_build_binaries' conditionals or overriding generic
src_compile().
Also, next time, please keep all your mails in a single thread.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On Tue, Dec 10, 2013 at 8:55 PM, Pacho Ramos pa...@gentoo.org wrote: https://bugs.gentoo.org/show_bug.cgi?id=197625#c14 This has reminded me that maybe we should switch to cronie from vixie-cron as default and recommended cron provider in Handbook. Last time I checked, vixie-cron upstream was died while cronie forked it fixing some bugs :/ What do you think? I am all for it. I wouldn't say that vixie-cron is dead since it is still functional, however I would rather say that it is outdated. In my opinion, cronie, unlike the other cron variants is the most reliable. Also, many other distributions like Arch[1] and openSUSE[2] have already switched from vixie-cron to cronie. Note: We need a new entry for cronie to our Cron wiki page [3] [1] https://wiki.archlinux.org/index.php/cron [2] http://en.opensuse.org/openSUSE:Cron_replace [3] https://wiki.gentoo.org/wiki/Cron Pavlos
Re: [gentoo-dev] some multilib-minimal enhancements [4/6]: ubiquitous multilib-phase-all callbacks
On Wed, Dec 11, 2013 at 2:40 PM, Michał Górny mgo...@gentoo.org wrote:
This patch adds multilib_src_{configure,compile,test}_all
callbacks, analogous to the existing multilib_src_install_all
callback.
No real benefit in having those.
There is no fundamental semantic benefit I can think of; indeed, as
pointed out above, the portage-standard
phase-function-implementation-override +
direct-invocation-of-overridden-phase-function recipe has slightly
greater semantic power. However, subjectively speaking, I feel that
using the multilib_phase_all callbacks make for cleaner and easier
to follow code. My thinking was that providing two ways to achieve
the same thing should be harmless -- ebuild authors are, after all,
coding bash scripts to run in a UNIX-like environment, so hopefully
they are comfortable choosing between multiple-ways-to-do-it :)
However, I'm not so attached to this patch that I'd put up a big fight
over it; my overlay doesn't use them, and they are, strictly-speaking,
superfluous.
-gmt
Re: [gentoo-dev] some multilib-minimal enhancements [5/6]: add frob to control phase parallelization
On Wed, Dec 11, 2013 at 2:41 PM, Michał Górny mgo...@gentoo.org wrote: Very limited usefulness, a lot of extra complexity Can't say I entirely agree on either point, but it wouldn't meaningfully jam up my patch queues, which makes me much less inclined to be attached to it. Another reason, upon consideration, not to rush to merge this into gx86, is that this could perhaps be implemented in multibuild, rather than multilib-anything (i.e.: by allowing folks to set a variable that would cause (only) the next multibuild_foreach_variant invocation to route to multibuild_parallel_foreach_variant... but maybe that's not a great idea since it would provide third parties with too easy a way to accidentally break stuff like the header wrapping in multilib-minimal_src_install). -gmt
Re: [gentoo-dev] rfc: renaming rc binary in OpenRC
On 12/12/2013 04:41 AM, William Hubbs wrote: All, We got a request from Debian to rename the rc binary of OpenRC due to a naming conflict they have. They have a port of the att plan 9 shell, which has a binary named rc as well[1]. My thought is to rename our rc to openrc, since that would be unique. Make it build-time configurable. Keep default at rc. Let Debian and others rename it as they want/need. I know at least one thing that will break is everyone's inittab, so should I sed their inittab in our live ebuild or expect them to fix it and give a warning? It's change to change things, it doesn't fix any bugs we have. So don't break things for fun, please ... I know that once OpenRC with this change is released, it will need to probably be p.masked until there is a new release of sysvinit that updates the inittab. I'm not sure what else will break. Does anyone have any ideas wrt other things to look for, or should I make the changes upstream and have people let us know what else breaks? William [1] https://bugs.gentoo.org/show_bug.cgi?id=493958
Re: [gentoo-dev] rfc: renaming rc binary in OpenRC
On 12/12/2013 05:28 AM, Rich Freeman wrote: On Wed, Dec 11, 2013 at 3:47 PM, Chris Reffett creff...@gentoo.org wrote: The idea of running a sed on inittab in an ebuild, no matter what the context, terrifies me. Perhaps we can ease this in slowly by renaming rc - openrc and symlinking rc - openrc and making a release with that change concurrent with a news item? Or even just do that in the ebuild rather than in the actual sources. I don't think Debian will keel over and die if it takes a little extra time for the change to go through, and it beats a ton of broken systems. ++ No reason the symlink couldn't be done in the ebuild either - which keeps the package itself clean. There could be news to clean up inittab and such, and then perhaps down the road the compat symlink could be removed. Nice to see interest in Debian (granted, I know there was interest quite a while back). Having more and better options is just good for everybody - I'd like to see OpenRC become the best traditional-style service manager around (though honestly I'd be hard-pressed to think of any that are quite as good already). I think one thing that would be nice to dream about someday would be a systemd-compatibility init.d script. That would be symlinked to a service name just like a typical network interface script, and would look for a unit file and interpret it (perhaps just taking a path from conf.d). I'd think it wouldn't be hard to do, setting aside the more active-management features of systemd. Well, given that systemd unit files don't express dependencies ... I've thought about it and can't figure out a way to make mixed-mode work sanely, at all. You'd have to either manually order the startup sequence, or annotate the unit files with dependency info. Plus you'd need some machinery like socket-activation proxies or you're throwing away even more (to the point where the unit file is just a way to run an executable) I don't think this can be done in a way that adds value to users.
Re: [gentoo-dev] some multilib-minimal enhancements [3/6]: a shitload of in-source doc
On Wed, Dec 11, 2013 at 2:01 PM, hasufell hasuf...@gentoo.org wrote: I actually feel that some parts of this is not documentation, but rather wiki. So maybe that's exactly where to put it? The doc in the eclass should only describe the behavior of the eclass and the main points you need to know in order to get it going. But it is not a strong feeling. I think you're probably right... I'll endeavor to re-factor this patch and put the wiki stuff into the wiki. +# it is often best to put multilib-minimal first on the inherits list. first? You mean last or what? I definitely meant first -- the existing in-source doc said last but I thought that must surely be a thinko... unless my understanding of how inherits works is backwards -- the first, not the last, inheritee gets the default phase-function implementations wired up to it, correct? I suppose another assumption I have, that, if not shared, might be leading us to opposite conclusions, is that a majority of inheritors would want the default phase function implementations to be wired up to multilib-minimal...? btw, based on the same criteria you mention above, some of what I've said about the matter probably better belongs in the wiki rather than the in-source doc. -gmt
Re: [gentoo-dev] some multilib-minimal enhancements [6/6]: update authorship metadata
On Wed, Dec 11, 2013 at 1:44 PM, hasufell hasuf...@gentoo.org wrote: It should be made clear who is the initial/original author. Maintainer can be quite anyone. IIRC there's now a @DOC_THINGY for that; I'll use it in the next version of this patch series, should there be one. -gmt
Re: [gentoo-dev] some multilib-minimal enhancements [2/6]: add frob for consumers to disable automagic header wrapping
On Wed, Dec 11, 2013 at 1:37 PM, hasufell hasuf...@gentoo.org wrote: On 12/11/2013 10:18 PM, Greg Turner wrote: this needs more explanation. Why do we want this? Sometimes the automagic header stuff is working against the ebuild author, or at least threatens to, in the future. The most plausible etiology would be: ABI X is going to generate header_x.h but ABI Y is going to generate header_y.h, or no header at all. An argument could certainly be made this this calls for either (a) a way to exempt a particular header from the header automagic -- not all of them or (b) a general exemption from ebuild-crashing, for headers that are present for a certain ABI but not in other ABI's. The only reason I didn't implement either of those (both of which are probably preferable to mine) is that it seemed nontrivial, and I'm lazy. Regardless, if our standard advice is try not to use this automagic header wrapping feature, it can break autoconf assumptions (IIRC, it is -- but if it isn't, it probably should be), then we ought to provide /some/ convenient means to get around it, other than sneaking those headers in through some kind of inter-abi back-door, in order to fake out the automagic (which is, effectively, what we require right now). FWIW, I'm pretty sure that thus far, every time I've thought, initially, that I needed this feature, I've ended up deciding I didn't need it, after all. -gmt
Re: [gentoo-dev] rfc: renaming rc binary in OpenRC
On Wed, Dec 11, 2013 at 6:37 PM, Patrick Lauer patr...@gentoo.org wrote: On 12/12/2013 04:41 AM, William Hubbs wrote: All, We got a request from Debian to rename the rc binary of OpenRC due to a naming conflict they have. They have a port of the att plan 9 shell, which has a binary named rc as well[1]. My thought is to rename our rc to openrc, since that would be unique. Make it build-time configurable. Keep default at rc. Let Debian and others rename it as they want/need. I know at least one thing that will break is everyone's inittab, so should I sed their inittab in our live ebuild or expect them to fix it and give a warning? It's change to change things, it doesn't fix any bugs we have. So don't break things for fun, please ... Honestly, with Linux systems a symlink won't matter. Just rename the binary to openrc so that we are closer with Debian. It would be nice if in the future docs and blogs and other things could share the same info. For Gentoo just symlink rc - openrc and call it a day. There's also no reason to remove the symlink in the next release like others have said. Keep the thing around for as long as is possible. Cause if you drop it, you're liable to break someone upgrading an old system and they have a higher chance to miss an important ewarn and you know how much I hate breaking upgrades. -- Doug Goldstein
Re: [gentoo-dev] some multilib-minimal enhancements [0/6]: de-headerization
On Wed, Dec 11, 2013 at 3:18 PM, Greg Turner g...@malth.us wrote: sorry for attaching these rather than in-lining but google insists on 78-wrapping plain-text e-mail. If HTML mail would be a better solution for people I'd be happy to re-send (unless maybe a single person requests it and a chorus of objections are raised :P). This series is available also in bug #493214. Use git send-email, works perfectly fine with gmail. Attachments are worthless and mostly considered spam. -- Doug Goldstein
[gentoo-dev] Re: some multilib-minimal enhancements [3/6]: a shitload of in-source doc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/11/2013 07:54 PM, Greg Turner wrote: On Wed, Dec 11, 2013 at 2:01 PM, hasufell hasuf...@gentoo.org wrote: I actually feel that some parts of this is not documentation, but rather wiki. So maybe that's exactly where to put it? The doc in the eclass should only describe the behavior of the eclass and the main points you need to know in order to get it going. But it is not a strong feeling. I think you're probably right... I'll endeavor to re-factor this patch and put the wiki stuff into the wiki. +# it is often best to put multilib-minimal first on the inherits list. first? You mean last or what? I definitely meant first -- the existing in-source doc said last but I thought that must surely be a thinko... unless my understanding of how inherits works is backwards -- the first, not the last, inheritee gets the default phase-function implementations wired up to it, correct? I suppose another assumption I have, that, if not shared, might be leading us to opposite conclusions, is that a majority of inheritors would want the default phase function implementations to be wired up to multilib-minimal...? btw, based on the same criteria you mention above, some of what I've said about the matter probably better belongs in the wiki rather than the in-source doc. -gmt The *last* eclass inherited that exports a particular function (via EXPORT_FUNCTIONS) is the one that prevails, not the *first*. Therefore, if it is expected that multilib-minimal.eclass's versions will be used, it should be nearer the end of the inherit line, not the beginning. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJSqSBrAAoJELHSF2kinlg4JcgP/2KKiXTcRkBUQmT0A5X0NLJV TqthtEKHlQhAuc9VjVtMj+h1UhAuDxsK4tasUBlXG6b3ab3o5drXVyD+rZWJHr8N FaqWuwSsbnIxp461DNVbQk5vhHAHY9oxFxT1rV/wjgFIK0d6yZxSBBDWWtWLbOba ev/FRw5LqnK8JkX/YaGCo6HYNSxaSGTRdeuSlndfF5dLYXRFO5JIR98S6YtsZWFY jXjKNcYQNVX/HAeU42LCMffgODSiCmLQPE9D5vhP9hOD9tLlBe6WZLt8iKKaBOug rBvRaQq9lL7obivYohMqR+7MCeCcvlDc6rMu1ZEdBMEfN39lzmTiAp9wXlYpbB7Q pM1YI97bqXGwS8lpBL6AIkS5Uep/0q1UD8bDw67PMtOrCh5Oi/SniCY8pdZCqpms bFYp+MgtYtvopI+vtn1P7/P4LBv9LspReQ7lVV4ukKSkuqx7L4B3Az3fiHcTV8ce XCzbSkR4ZOwvAypXtMRhmfcpIchVegqLwUIZHVRkUH9Qwd+o4dvpmBIxkUVdqFJD OINNplQ1/WqxJdonkFVzWUAO1jE67M91uf3zcimB63ioNKwSQGalVGQt3Rp1RfCd eJgsgkmtvI8fqhnkZTO+i70Xl89+JXhz+R4tfMewTId4wch+w3EiX3PKJUbF9rWK P6tuUW0eRNp6t7SU2ZdY =WMyy -END PGP SIGNATURE-
Re: [gentoo-dev] Re: some multilib-minimal enhancements [3/6]: a shitload of in-source doc
On Wed, Dec 11, 2013 at 6:33 PM, Jonathan Callen jcal...@gentoo.org wrote: The *last* eclass inherited Well I'll be ferschnookered! Googling confirms this. I'm quite shocked. I have believed the opposite, for a very long time, with perfect confidence. No idea why I thought so -- in retrospect, I'm pretty sure I was aware that they were sourced in order -- so why would the phase function overrides act in an entirely opposite pattern? Some stupid aislexydic thinko, years ago, no doubt. Good catch, Julian! I'll fix it when I rev this patch series. -gmt
Re: [gentoo-dev] some multilib-minimal enhancements [2/6]: add frob for consumers to disable automagic header wrapping
Dnia 2013-12-11, o godz. 17:20:08 Greg Turner g...@malth.us napisał(a): On Wed, Dec 11, 2013 at 1:37 PM, hasufell hasuf...@gentoo.org wrote: On 12/11/2013 10:18 PM, Greg Turner wrote: this needs more explanation. Why do we want this? Sometimes the automagic header stuff is working against the ebuild author, or at least threatens to, in the future. If you can't solve a problem, ask someone else. Working around it is almost never a good solution. The most plausible etiology would be: ABI X is going to generate header_x.h but ABI Y is going to generate header_y.h, or no header at all. An argument could certainly be made this this calls for either (a) a way to exempt a particular header from the header automagic -- not all of them or (b) a general exemption from ebuild-crashing, for headers that are present for a certain ABI but not in other ABI's. The only reason I didn't implement either of those (both of which are probably preferable to mine) is that it seemed nontrivial, and I'm lazy. Then you need to wrap all the possible headers. The function works well if you specify headers that are only available in some of the ABIs. Regardless, if our standard advice is try not to use this automagic header wrapping feature, it can break autoconf assumptions (IIRC, it is -- but if it isn't, it probably should be), then we ought to provide /some/ convenient means to get around it, other than sneaking those headers in through some kind of inter-abi back-door, in order to fake out the automagic (which is, effectively, what we require right now). The advice tells to do things properly, not to choose even worse solution. If wrapping breaks something, random header install is going to screw up even worse. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] some multilib-minimal enhancements [2/6]: add frob for consumers to disable automagic header wrapping
On Wed, Dec 11, 2013 at 10:33 PM, Michał Górny mgo...@gentoo.org wrote: Regardless, if our standard advice is try not to use this automagic header wrapping feature, it can break autoconf assumptions (IIRC, it is -- but if it isn't, it probably should be), then we ought to provide /some/ convenient means to get around it, other than sneaking those headers in through some kind of inter-abi back-door, in order to fake out the automagic (which is, effectively, what we require right now). The advice tells to do things properly, not to choose even worse solution. If wrapping breaks something, random header install is going to screw up even worse. The matter of whether ebuild authors know how to implement multilib headers correctly or not is mostly orthogonal to that of whether or not multilib-minimal.eclass throws up obstructions in the way of a correct (or incorrect) implementation. I'm attempting to address the latter issue, not the former. Encouraging everyone to wrap headers, even, for example, in pathological cases where there is not, in fact, any header conflict between ABI's, to begin with, seems to me like incurring a cost (likelihood of broken autotools macros) with no benefit, I can identify, to end-users. Furthermore, the possibility of a superior, but more involved and hypothetical solution to a problem is, in my experience, not always a good reason to avoid a quick and simple solution, available immediately. If you prefer that I code up one of the more sophisticated approaches I mentioned, I'd be happy and perfectly capable to do so, just let me know which you prefer. -gmt
Re: [gentoo-dev] some multilib-minimal enhancements [2/6]: add frob for consumers to disable automagic header wrapping
Dnia 2013-12-11, o godz. 23:10:12 Greg Turner g...@malth.us napisał(a): Encouraging everyone to wrap headers, even, for example, in pathological cases where there is not, in fact, any header conflict between ABI's, to begin with, seems to me like incurring a cost (likelihood of broken autotools macros) with no benefit, I can identify, to end-users. Real life example first, pathological theories later. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: renaming rc binary in OpenRC
On 11/12/13 22:41, William Hubbs wrote: All, We got a request from Debian to rename the rc binary of OpenRC due to a naming conflict they have. They have a port of the att plan 9 shell, which has a binary named rc as well[1]. which we ship as app-shells/rc and rename 'rc' to 'rcsh' for unique name just saying
Re: [gentoo-portage-dev] [PATCH] QA warning for files in /var/{cache,lib,lock,run}/ or /run/ (bug 493154)
Am 11.12.2013 08:57, schrieb Mike Frysinger:
On Thursday 05 December 2013 15:57:17 sebastianlut...@gmx.de
wrote:
--- a/bin/misc-functions.sh +++ b/bin/misc-functions.sh @@ -242,6
+242,11 @@ install_qa_check() { [[ -d ${ED}/$x ]] f+= $x\n
done
+# It's ok create these directories, but not to install into
them. (bug 493154)
our style uses #12345 rather than (bug 12345) # It's ok create
these directories, but not to install into them. #493154
+for x in var/cache var/lib var/lock var/run run ; do + [[ -d
${ED}/$x ]] [[ $(find ${ED}/${x} -prune -empty) = ]]
f+= $x\n
the -d check doesn't handle symlinks correctly ... baselayout would
install /var/run - /run, and the -d would deref that to the real
symlink. however, `find` will not descend into the symlink, so we
end up being saved by that.
we have -z for detecting empty output rather than comparing to an
empty string
non-builtin vars should use braces, so that'd be ${x}. i know some
of the code in here doesn't follow that, but we should be marching
in that direction with new code.
My bash knowledge is rather limited. So, thanks for your comments.
if [[ -n $f ]] ; then eqawarn QA Notice: This ebuild installs
into the following
deprecated directories:
this warning is incorrect for these paths. we need to create a new
warning that clearly explains what is going on.
Right, thanks for fixing.
i'll send out a new version. -mike
FWIW, new patch looks fine.
Sebastian
