[gentoo-dev] Re: eselect init
On Sat, May 25, 2013 at 11:54:48AM +0200, Luca Barbato wrote: I'm back to the other part of it: switching the actual init implementation. # WHY (not just edit your bootloader) Since efi at least some people started to put in the kernel the bootargs and we have at least few new options brewing for init, some are small impact (bootchar, bb-init-openrc and runit-openrc) some are more invasive (runit and systemd). In those setup changing bootargs requires a kernel rebuild and some effort, while the eselect approach stays completely transparent. That's not an argument for using a symlink switcher or the equivalent across the board, by any means. Firstly, we should be recommending people install Gentoo with enough flexibility to configure and use their system how they choose. In the UEFI arena, why not simply recommend something like rEFIt instead of making everyone go through a load of development effort, to restrict us all to a crippled use-case? NOTE: If you still wish to pursue a fixed config, then it's easy enough to build it with init=/sbin/einit since presumably you want that setup for your users. So even for the restricted corner-case of a Gentoo install without a bootloader this is not needed. In fact it would be better done using the existing mechanism. All I'm saying is: can we please stop trying to reinvent the kernel, which accepts a bootloader parameter from initramfs as well, and focus instead on the difficult part: making sure the system is in a fit state to switch in the first place. That's where the development effort is needed, if you are to provide a mechanism to switch. The symlink and hooks etc is a total dead-end, imo. It's simply reinventing the wheel using octagons instead of circles. There's nothing to stop systemd being the default init, should you want to put the install together like that. Because let's be honest: someone has to put this install together, irrespective of how incapable the end-user is of editing a file by themselves. And just because the user can do it simply, that's no reason to make our method to do it any more complex (I've never heard such a bizarre argument.) Just edit the file via script. If we're on a crippled EFI setup, or the user has specified to use the boot wrapper, then we're simply editing a file for the wrapper to read instead. It's trivial. FOCUS on getting the system safe to switch. Not on reinventing init/main.c, badly. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Draft news item: MySQL/MariaDB packages dropping support for PrimeBase (PBXT) engine
On Sat, 1 Jun 2013, Robin H Johnson wrote: Title: MySQL/MariaDB packages dropping support for PrimeBase (PBXT) engine Too long, maximum 44 characters according to GLEP 42. The above will even be truncated by eselect news. Ulrich
[gentoo-dev] Packages up for grabs
Due peper lack of time the following packages are now up for grabs: app-dicts/libydpdict app-dicts/ydpdict
[gentoo-dev] Re: eselect init
In the UEFI arena, why not simply recommend something like rEFIt sorry should have been rEFInd: http://www.rodsbooks.com/refind/ as discussed recently on gentoo-user@. --
[gentoo-dev] Packages up for grabs
Due Lack lack of time the following packages are now up for grabs: net-dns/openresolv x11-misc/etm x11-misc/ipager x11-misc/nts
[gentoo-dev] rox herd is empty
Due Lack inactivity for a long time, rox herd is now empty. If nobody joins in two weeks, we will proceed with removing that herd and moving its packages to maintainer-needed Thanks
Re: [gentoo-dev] Draft news item: MySQL/MariaDB packages dropping support for PrimeBase (PBXT) engine
On 01/06/13 06:36 AM, Ulrich Mueller wrote: On Sat, 1 Jun 2013, Robin H Johnson wrote: Title: MySQL/MariaDB packages dropping support for PrimeBase (PBXT) engine Too long, maximum 44 characters according to GLEP 42. The above will even be truncated by eselect news. Ulrich echo -n MySQL/MariaDB dropping PrimeBase (PBXT) | wc -c 39 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs
Due cedk lack of time the following packages are now up for grabs: app-admin/eselect-audicle app-admin/eselect-chuck app-admin/eselect-miniaudicle app-admin/eselect-sndpeek app-misc/hachoir-metadata app-misc/hachoir-subfile app-misc/hachoir-urwid app-misc/lsx app-office/calcurse dev-db/pg_top dev-python/hachoir-core dev-python/hachoir-parser dev-python/hachoir-regex dev-python/pycountry dev-python/pywebdav dev-util/nsis dev-vcs/hgsvn media-sound/audicle media-sound/chuck media-sound/miniaudicle media-sound/tapestrea net-im/minbif net-misc/olsrd net-news/snownews net-print/lm1100 sci-misc/pythoncad www-apache/mod_auth_nufw
Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
On Thu, May 30, 2013 at 01:23:59PM +0200, Ralph Sennhauser wrote: On Tue, 28 May 2013 17:15:40 -0500 William Hubbs willi...@gentoo.org wrote: On Tue, May 28, 2013 at 09:07:37PM +0200, Michał Górny wrote: For the others, how large is the benefit of having them switchable? At least some of them look like something that wouldn't hurt people if it was always-built. The dev manual states that use flags are to control optional dependencies and _settings_ which a user may reasonably want to select [1]. William, each time this comes up you overred the _reasonably_. Controlling dependencies is always reasonable but beyond that it's case by case. Just because you can is never a valid reason. Often there are options you clearly only want to toggle if you are a developer or options meant for porting to alternative operating systems which lack some bells and whistles and the like. Another example is configuring a library for bundling with an app. The world is bigger than linux distros. Ralph, I never said anything about disagreeing with these cases. I'm talking about purely optional features of packages which do not have any bearing on runtime dependencies or cause breakage. If a configure script offers switches for purely optional features, we should, imo, 1) give the users use flags to control these features or 2)hard code the settings we want in our ebuilds. What do you think? William signature.asc Description: Digital signature
Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
Dnia 2013-06-01, o godz. 12:41:06 William Hubbs willi...@gentoo.org napisał(a): On Thu, May 30, 2013 at 01:23:59PM +0200, Ralph Sennhauser wrote: William, each time this comes up you overred the _reasonably_. Controlling dependencies is always reasonable but beyond that it's case by case. Just because you can is never a valid reason. Often there are options you clearly only want to toggle if you are a developer or options meant for porting to alternative operating systems which lack some bells and whistles and the like. Another example is configuring a library for bundling with an app. The world is bigger than linux distros. Ralph, I never said anything about disagreeing with these cases. I'm talking about purely optional features of packages which do not have any bearing on runtime dependencies or cause breakage. If a configure script offers switches for purely optional features, we should, imo, 1) give the users use flags to control these features or 2)hard code the settings we want in our ebuilds. What do you think? That depends on a package and on the case. If a switch only changes the default in a config file, a flag is useless. If a switch toggles a feature that does not introduce additional dependencies, is small and can be toggled from within the app, a flag is useless. If a switch toggles a install of a tiny file which most people either want or don't care about, a flag is useless. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Draft news item: MySQL/MariaDB packages dropping support for PrimeBase (PBXT) engine
On Sat, Jun 01, 2013 at 12:36:50PM +0200, Ulrich Mueller wrote: On Sat, 1 Jun 2013, Robin H Johnson wrote: Title: MySQL/MariaDB packages dropping support for PrimeBase (PBXT) engine Updated title: PBXT now unsupported in MySQL/MariaDB 37 characters. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
Dnia 2013-06-01, o godz. 15:20:32 William Hubbs willi...@gentoo.org napisał(a): On Sat, Jun 01, 2013 at 08:00:22PM +0200, Michał Górny wrote: If a switch toggles a feature that does not introduce additional dependencies, is small and can be toggled from within the app, a flag is useless. If someone never wants the feature in the first place, and they can save space and build time by not building or installing the man pages, executables, config files, etc for it, forcing it onto their systems is an unnecessary waste of build time and bloating their systems. Unless the complexity added by a dozen USE flags actually *wastes more time* than installing the manpage. Especially if he ends up rebuilding something big because someone smart decided to add USE flag he wouldn't ever expect to be there. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
On Sat, Jun 01, 2013 at 10:26:54PM +0200, Michał Górny wrote: Dnia 2013-06-01, o godz. 15:20:32 William Hubbs willi...@gentoo.org napisał(a): On Sat, Jun 01, 2013 at 08:00:22PM +0200, Michał Górny wrote: If a switch toggles a feature that does not introduce additional dependencies, is small and can be toggled from within the app, a flag is useless. If someone never wants the feature in the first place, and they can save space and build time by not building or installing the man pages, executables, config files, etc for it, forcing it onto their systems is an unnecessary waste of build time and bloating their systems. Unless the complexity added by a dozen USE flags actually *wastes more time* than installing the manpage. Especially if he ends up rebuilding something big because someone smart decided to add USE flag he wouldn't ever expect to be there. Sure there may be some rebuilds initially, but that also depends on when the use flags are added. If they are added with a new release and IUSE defaults are set so that the change in functionality is minimized, the chance of people having to rebuild because of the use flags is minimized. William signature.asc Description: Digital signature
[gentoo-dev] evar_push/pop helpers
simple set of helpers to save/restore a variable in a limited section of code
you can see an example of it in action at the end of the file where i need to
tweak epatch (and no, doing `LC_COLLATE=C set -- ` does not work).
-mike
--- eutils.eclass 22 May 2013 05:10:29 - 1.421
+++ eutils.eclass 2 Jun 2013 03:00:46 -
@@ -146,6 +146,77 @@ estack_pop() {
eval unset ${__estack_name}\[${__estack_i}\]
}
+# @FUNCTION: evar_push
+# @USAGE: variable to save [more vars to save]
+# @DESCRIPTION:
+# This let's you temporarily modify a variable and then restore it (including
+# set vs unset semantics). Arrays are not supported at this time.
+#
+# For example:
+# @CODE
+# evar_push LC_ALL
+# export LC_ALL=C
+# ... do some stuff that needs LC_ALL=C set ...
+# evar_pop
+#
+# # You can also save/restore more than one var at a time
+# evar_push BUTTERFLY IN THE SKY
+# ... do stuff with the vars ...
+# evar_pop # This restores just one var, SKY
+# ... do more stuff ...
+# evar_pop 3 # This pops the remaining 3 vars
+# @CODE
+evar_push() {
+ local var val
+ for var ; do
+ [[ ${!var+set} == set ]] \
+val=${!var} \
+ || val=${___ECLASS_ONCE_EUTILS}
+ estack_push evar ${var} ${val}
+ done
+}
+
+# @FUNCTION: evar_push_set
+# @USAGE: variable to save [new value to store]
+# @DESCRIPTION:
+# This is a handy shortcut to save and temporarily set a variable. If a value
+# is not specified, the var will be unset.
+evar_push_set() {
+ local var=$1
+ evar_push ${var}
+ case $# in
+ 1) unset ${var} ;;
+ 2) eval ${var}=\$2 ;;
+ *) die ${FUNCNAME}: incorrect # of args: $* ;;
+ esac
+}
+
+# @FUNCTION: evar_pop
+# @USAGE: [number of vars to restore]
+# @DESCRIPTION:
+# Restore the variables to the state saved with the corresponding
+# evar_push call. See that function for more details.
+evar_pop() {
+ local cnt=$1
+ case $# in
+ 0) cnt=1 ;;
+ 1)
+ : ${cnt:=bad}
+ [[ -n ${cnt//[0-9]} ]] die ${FUNCNAME}: first arg must be a
number: $*
+ ;;
+ *) die ${FUNCNAME}: only accepts one arg: $* ;;
+ esac
+
+ local var val
+ while (( cnt-- )) ; do
+ estack_pop evar val || die ${FUNCNAME}: unbalanced push
+ estack_pop evar var || die ${FUNCNAME}: unbalanced push
+ [[ ${val} == ${___ECLASS_ONCE_EUTILS} ]] \
+unset ${var} \
+ || eval ${var}=\${val}
+ done
+}
+
# @FUNCTION: eshopts_push
# @USAGE: [options to `set` or `shopt`]
# @DESCRIPTION:
@@ -344,8 +415,11 @@ epatch() {
local EPATCH_SUFFIX=$1
elif [[ -d $1 ]] ; then
- # Some people like to make dirs of patches w/out suffixes (vim)
+ # We have to force sorting to C so that the wildcard expansion
is consistent #471666.
+ evar_push_set LC_COLLATE C
+ # Some people like to make dirs of patches w/out suffixes (vim).
set -- $1/*${EPATCH_SUFFIX:+.${EPATCH_SUFFIX}}
+ evar_pop
elif [[ -f ${EPATCH_SOURCE}/$1 ]] ; then
# Re-use EPATCH_SOURCE as a search dir
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] Is portage (/usr)/bin-merge safe?
On Saturday 01 June 2013 01:36:28 Duncan wrote: As in subject, is portage bin/usr-bin merge safe? portage should be merge safe for all files. it specifically writes it to a temp file and then does a rename so it's an atomic update. otherwise you'd get things like ETXTBSY errors. -mike signature.asc Description: This is a digitally signed message part.
