Re: [gentoo-dev] Better handling of USE flags to enable/disable system libraries
29.05.2013 03:01, David Carlos Manuelda пишет: El Martes, 28 de mayo de 2013 14:03:52 Mike Frysinger escribió: On Tuesday 28 May 2013 13:53:54 Michał Górny wrote: On Tue, 28 May 2013 16:43:10 +0200 David Carlos Manuelda wrote: I posted a bug about that along with a suggestion, despite sometimes I do not explain myself correctly (I am very sorry): bug #471590 Many packages are bundling its own libraries rather than link against system ones, and there is a bug tracker for that (bug #251464) [...] What I propose for example, is a very good and simple approach: to have an option in portage's make.conf, something like that (the name may change): 1.- USE_SYSTEM_LIBRARIES=cairo sqlite XXX 2.- USE_SYSTEM_LIBRARIES=* -cairo 3.- USE_SYSTEM_LIBRARIES=* I don't think we should do it like this. Bundling libraries is a pathological case. In general, we should work on fixing this and getting rid of bundled libraries. In that general case, the flags are not required. +1 -mike Ok, thinking it better I agree, that having them use system libraries is far better, but why then those affected ebuilds have corresponding USE disabled by default? How do you imaging use of system library( called foo, for example) if foo, bundled in program(called bar, for same reason :-)) is fork with new features that is suitable only for bar? It's ideal situation when bar works also with system foo(not all features works, however). Sometimes(and it happens very often, to be honest) bar can not work with system foo at all! For example, look at quake3-1.36-r1.ebuild, at commented use system jpeg patch. If you uncomment it, quake3 will be built against system jpeg. It will build successfully, but textures will be a big mess of polygons. So, unfortunately, it's not even an option here, unless somebody will do a great work for splitting this library and write a huge patch, that will be totally rejected by upstream(so he will have to maintain this patch on his own). -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Review Board for Gentoo
On 29/05/2013 02:07, Alexey Shvetsov wrote: Hi! Cool! I didnt use RB before, but i use gerrit. Do you pan to integrate it to g.o.g.o? It seems can be done by git commit hooks What sort of integration did you have in mind?
Re: [gentoo-dev] Re: Review Board for Gentoo
He is probably thinking about buildtests and automatic commit merges which are not possible with reviewboard. Dne 29.5.2013 9:09 Michael Palimaka kensing...@gentoo.org napsal(a): On 29/05/2013 02:07, Alexey Shvetsov wrote: Hi! Cool! I didnt use RB before, but i use gerrit. Do you pan to integrate it to g.o.g.o? It seems can be done by git commit hooks What sort of integration did you have in mind?
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 00:36:58 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: 3b) Except... at that point root isn't writable Let me stop you here. Does it need to be writable at that point? We're reading the path of the init file to boot from a file, we start the executable at that path; no writes are involved here. The only problem left here is that some init systems need a specific version of the inittab file, although this can likely be changed in late shutdown as the only exception to this approach. It sounds very feasible for init systems that are an exception to just being able to switch init alone or have conflicting files to fix up whatever is inconsistent; either by scheduling changes till when the disk is writable, or by doing it on shutdown... But it occurred to me that we actually do have a demonstrated workable and long used in actual practice exception to the normal boot case as precedent, where such maintenance tasks traditionally occur, single user mode. Iff nothing else is feasible enough, this makes a lot of sense to me. [initr* SNIP] Having an initr* as a requirement for being able to switch init system is maybe a bit too much to ask; same as above, iff nothing else ... 4) Finally, the fact that each init-system package gets to control its own switcher-mode script keeps control of it with the init-system package maintainers, allowing them to choose as complex or simple a script as they need/wish, reasonably addressing the whole maintainer control problem so evident in another current thread. We should avoid maintenance burden where we can; we can't also force things upon them, as you can see in other ML threads here. Init systems are quite necessary in Gentoo, let's not risk losing their maintainers. That being said; if there are exceptions to the approach we end up taking, we need to put these somewhere. It kind of depends on how we will integrate the init system approach in the Portage tree. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/20/2013 08:29 PM, Tom Wijsman wrote: We have `iamlate` for this in app-portage/gentoolkit-dev. /usr/bin/imlate , nice ;-) - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlGlyLAACgkQknrdDGLu8JDJ3QEAhYrgzLHT5NCINaXBVYCNs1PH 12+nHNMy9V+6BQ4EMi8A/RLvadt7RndQPk8m5BuDlzRuwaO05WNVfkArMOxovd1v =7eoE -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Review Board for Gentoo
Yep I'm thinking about gerrit like workflow. But seems it doesnt make sense with RB and CVS. В письме от 29 мая 2013 10:22:29 пользователь Tomáš Chvátal написал: He is probably thinking about buildtests and automatic commit merges which are not possible with reviewboard. Dne 29.5.2013 9:09 Michael Palimaka kensing...@gentoo.org napsal(a): On 29/05/2013 02:07, Alexey Shvetsov wrote: Hi! Cool! I didnt use RB before, but i use gerrit. Do you pan to integrate it to g.o.g.o? It seems can be done by git commit hooks What sort of integration did you have in mind? -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Review Board for Gentoo
On 29/05/2013 21:18, Alexey Shvetsov wrote: Yep I'm thinking about gerrit like workflow. But seems it doesnt make sense with RB and CVS. Yes, Review Board and Gerrit target different things.
[gentoo-dev] Re: PSA: python-r1.eclass, python-single-r1.eclass, and REQUIRED_USE
On 28/05/2013 01:35, Jonathan Callen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 A quick reminder for anyone using python-r1.eclass or python-single-r1.eclass: These eclasses provide a ${PYTHON_REQUIRED_USE} variable that should be included in REQUIRED_USE under the same USE conditionals (if any) that ${PYTHON_DEPS} is included in DEPEND/RDEPEND. For example, if your ebuild has: RDEPEND= python? ( ${PYTHON_DEPS} then you should also have: REQUIRED_USE= python? ( ${PYTHON_REQUIRED_USE} ) And if your ebuild just has: RDEPEND=${PYTHON_DEPS} then you should also have: REQUIRED_USE=${PYTHON_REQUIRED_USE} Failure to include these in REQUIRED_USE may cause the eclass to die very late in the build process. Thank you, Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJRo309AAoJELHSF2kinlg4dVcP/2t3v1t8CId8jK/c4VG8HLWL zTEvTI3d8wQILuHydI9VkOZllo3dPWhhUhg/1qJjwEXXnKQXiYNUiVzbtwdkGro/ OlkCrrpDstHgawHiovIZjgyEG9Y+Nz2Z5nKorZIAMFSFepaFsIkihVR3VkeHiG9Q 7XOOVaH8mqGuj7JWZNqikCmB11a6t08jVM68tzwtTZUuil1IRE2qjO5akMPczsvk 3ndoMsv5hQwUE4wmmTH4ffiz+wp/JUylK2Ypy6p/UWlMw+oq8IusyvQdKztF2rU4 SyjnEOHcPtbLXMA24NHSAUov5L3xVcSu4he5A+QnY0Ghn0dZ7Wbk72aRZQP+MOk+ e18tdPRaXE35ux8s0ogLeuD04lju6z5/esJbP8LF8H6loiKCURxVOfYEhUugIMIc ihb6h4o4cflz2tYV6USOHxUQ6pA78X7ftXGJhOOR1sf1/2GZcg7ZQvD0WqjNLbAo U52yQl3/bKMVpezYLhkLxgzmRAdwbBdBFdiav8dX+QNYabLPG/0y6mkqK0pc59sS Lsse/dXCPrxfI6MVbsSQAaFt4s/YNrf9NLabdPHShRlWX8pRc16feQFb7FoTCmWe BzwBwG63Mvw2OOS0GrXIfXdFs9klbezoZ8Ql8Zb3CIZPWaBPAOYfCqZDHkDDAyQL UYQyPJdIntHmxKbtMQr9 =frSU -END PGP SIGNATURE- Would it be possible to add repoman checks for this, and other common failures like missing PYTHON_USEDEP?
Re: [gentoo-dev] Re: PSA: python-r1.eclass, python-single-r1.eclass, and REQUIRED_USE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/29/2013 04:51 PM, Michael Palimaka wrote: Would it be possible to add repoman checks for this, and other common failures like missing PYTHON_USEDEP? The latter is impossible. Repoman has no way to figure out if PYTHON_USEDEP is necessary. You have to keep in mind that PYTHON_USEDEP does _not_ apply to every python dependency. If your application just runs a python script of another application, then it might not care under which implementation that is executed. If it's about importing modules, then we always need PYTHON_USEDEP. But how should repoman know? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRphl3AAoJEFpvPKfnPDWzKvkIAK9KTyK6bAjLMz7xD2xaC5lD QJptr5mEWH3MR+rTyyTSF0YJdPpDR0R3lJDDmUUqqE+xlCSO1kKaEYdJ1bNzQ/Kv fMxJEi99UA90Znn+G0gIzBOuqECOk9KZkuhkgCqZAatGgIJ6dc7sboVS7c8pZo8x vwbSvhKw8iJEY26HENspZQSmWupsYy++JG6iERU0GBnpSRDxvTbquanZ6zdo/og7 GbbDYbGA8OVICNBwhpIgDeStxRtpBaLw9c6BDtN+6FXf33s/hR2nAPpwX/3kLHrD thb+/Xf17G8Ao8JJdNns0gAA5ivzDZvETgQTvh8QH4wFzrlDH4MVcoeuLdhhlUU= =EwlO -END PGP SIGNATURE-
[gentoo-dev] Re: PSA: python-r1.eclass, python-single-r1.eclass, and REQUIRED_USE
On 30/05/2013 01:06, hasufell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/29/2013 04:51 PM, Michael Palimaka wrote: Would it be possible to add repoman checks for this, and other common failures like missing PYTHON_USEDEP? The latter is impossible. Repoman has no way to figure out if PYTHON_USEDEP is necessary. You have to keep in mind that PYTHON_USEDEP does _not_ apply to every python dependency. If your application just runs a python script of another application, then it might not care under which implementation that is executed. If it's about importing modules, then we always need PYTHON_USEDEP. But how should repoman know? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRphl3AAoJEFpvPKfnPDWzKvkIAK9KTyK6bAjLMz7xD2xaC5lD QJptr5mEWH3MR+rTyyTSF0YJdPpDR0R3lJDDmUUqqE+xlCSO1kKaEYdJ1bNzQ/Kv fMxJEi99UA90Znn+G0gIzBOuqECOk9KZkuhkgCqZAatGgIJ6dc7sboVS7c8pZo8x vwbSvhKw8iJEY26HENspZQSmWupsYy++JG6iERU0GBnpSRDxvTbquanZ6zdo/og7 GbbDYbGA8OVICNBwhpIgDeStxRtpBaLw9c6BDtN+6FXf33s/hR2nAPpwX/3kLHrD thb+/Xf17G8Ao8JJdNns0gAA5ivzDZvETgQTvh8QH4wFzrlDH4MVcoeuLdhhlUU= =EwlO -END PGP SIGNATURE- Sorry, I meant to write PYTHON_DEPS.
[gentoo-dev] [RFC] Suggested packages option in portage
I think, it'll be nice to have a way to suggest some packages to user, when (s)he installs something. For now it is only way to do that by something like: pkg_postinst() { if ! has_version dev-lua/iluajit; then einfo You'd probably want to install dev-lua/iluajit to; ewarn get fully functional interactive shell for LuaJIT; fi if has_version app-editors/emacs || has_version app-editors/xemacs; then einfo You'd probably want to install app-emacs/lua-mode to; ewarn get Lua completion in emacs.; fi } but some people find that way annoying and some devs also thinks it is bad way. Another way (use USEflags-related PDEPs — is a bad way too). Any thoughts? :) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Suggested packages option in portage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 29/05/13 11:43 AM, Vadim A. Misbakh-Soloviov wrote: I think, it'll be nice to have a way to suggest some packages to user, when (s)he installs something. For now it is only way to do that by something like: pkg_postinst() { if ! has_version dev-lua/iluajit; then einfo You'd probably want to install dev-lua/iluajit to; ewarn get fully functional interactive shell for LuaJIT; fi if has_version app-editors/emacs || has_version app-editors/xemacs; then einfo You'd probably want to install app-emacs/lua-mode to; ewarn get Lua completion in emacs.; fi } but some people find that way annoying and some devs also thinks it is bad way. Another way (use USEflags-related PDEPs — is a bad way too). Any thoughts? :) There are many thoughts, iirc there was at least one 100+ long thread in august/september 2012. Search for SDEPEND and IUSE_RUNTIME in the mailing list logs. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGmIs0ACgkQ2ugaI38ACPCzcQD/bANxbOhGaxwNhdXJ7Nxhw3Ld yZr96dhlKwfp6I1D2pIA+gPO0eYRGo4FDkbMQ1z72lawQgufTKbXpHwobjCTUVlb =c6wc -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, May 29, 2013 at 10:52:49AM +0200, Tom Wijsman wrote On Wed, 29 May 2013 00:36:58 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: 3b) Except... at that point root isn't writable Let me stop you here. Does it need to be writable at that point? We're reading the path of the init file to boot from a file, we start the executable at that path; no writes are involved here. The only problem left here is that some init systems need a specific version of the inittab file, although this can likely be changed in late shutdown as the only exception to this approach. In order for a different init system to come up, some file(s) somewhere *MUST* be different, no ifs/ands/ors/buts. The problem with an eselect approach is that it's like asking a brain surgeon to operate on himself. The proper procedure is to have another brain surgeon operate on him while the patient is under anesthesia. It sounds very feasible for init systems that are an exception to just being able to switch init alone or have conflicting files to fix up whatever is inconsistent; either by scheduling changes till when the disk is writable, or by doing it on shutdown... But it occurred to me that we actually do have a demonstrated workable and long used in actual practice exception to the normal boot case as precedent, where such maintenance tasks traditionally occur, single user mode. Iff nothing else is feasible enough, this makes a lot of sense to me. There are a couple of other possible approaches... 1) If the 2 systems can achieve peacefull co-existance (i.e. no identically-named files with different contents) then simply have 2 boot entries in /etc/lilo.conf (or grub equivalant)... append = init=/etc/foo append = init=/etc/bar ...and select whichever one you want from the boot menu. This guarantees a) the system shuts down properly with the old init b) the system starts up properly with the new init c) if the new files are incorrect/unbootable, you can simply reboot to the old version and try to figure out what went wrong [initr* SNIP] Having an initr* as a requirement for being able to switch init system is maybe a bit too much to ask; same as above, iff nothing else ... 2) We already have such a solution; it's called the Gentoo minimal install ISO. If the 2 init systems conflict over identically-named files, I strongly recommend that the changes be done while booted from a gentoo minimal install ISO. This guarantees a) the system shuts down properly with the old init b) the system starts up properly with the new init c) if the new files are incorrect/unbootable, you can simply chroot into the machine and send pleas for help to the Gentoo user mailing list ;) -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 14:15:54 -0400 Walter Dnes waltd...@waltdnes.org wrote: In order for a different init system to come up, some file(s) somewhere *MUST* be different, no ifs/ands/ors/buts. How true is this in general? It is usually only a change of the init parameter. As far as I heard there is only one exception, /etc/inittab being different between just two init systems; if you know more exceptions, feel free to list them. So, please prove your statement. The problem with an eselect approach is that it's like asking a brain surgeon to operate on himself. eselect and wrappers don't operate on themselves, please elaborate. The proper procedure is to have another brain surgeon operate on him while the patient is under anesthesia. Actually no, we're going a step further. The eselect doesn't touch the wrapper, but only its config; it's like actually changing brain memory. There are a couple of other possible approaches... 1) If the 2 systems can achieve peacefull co-existance (i.e. no identically-named files with different contents) then simply have 2 boot entries in /etc/lilo.conf (or grub equivalant)... [SNIP to shorten mail] Users can already do this, this isn't a solution. We want to make this easier towards the user, therefore doing heavy discussion to exhaust all the alternatives and maybe someone's interested in implementing one of them that appears most feasible. Having an initr* as a requirement for being able to switch init system is maybe a bit too much to ask; same as above, iff nothing else ... 2) We already have such a solution; it's called the Gentoo minimal install ISO. I agree, I have mine always available; yet some people are consistent in coming up with solutions for when all hell breaks lose. If the 2 init systems conflict over identically-named files, I strongly recommend that the changes be done while booted from a gentoo minimal install ISO. [SNIP to shorten mail] Again: Users can already do this, this isn't a solution. See above... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, May 29, 2013 at 09:56:00PM +0200, Tom Wijsman wrote: There are a couple of other possible approaches... 1) If the 2 systems can achieve peacefull co-existance (i.e. no identically-named files with different contents) then simply have 2 boot entries in /etc/lilo.conf (or grub equivalant)... [SNIP to shorten mail] Users can already do this, this isn't a solution. We want to make this easier towards the user, therefore doing heavy discussion to exhaust all the alternatives and maybe someone's interested in implementing one of them that appears most feasible. Since users can already do this, why are we bothering with re-inventing the wheel? How does running an eselect init command make it easier for the user than telling them to edit their boot loader config file? Gentoo users are expected to build their kernel and write their boot loader config file initially, so why are we trying to dumb this down? William signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] Suggested packages option in portage
El mié, 29-05-2013 a las 11:46 -0400, Ian Stakenvicius escribió: On 29/05/13 11:43 AM, Vadim A. Misbakh-Soloviov wrote: I think, it'll be nice to have a way to suggest some packages to user, when (s)he installs something. For now it is only way to do that by something like: pkg_postinst() { if ! has_version dev-lua/iluajit; then einfo You'd probably want to install dev-lua/iluajit to; ewarn get fully functional interactive shell for LuaJIT; fi if has_version app-editors/emacs || has_version app-editors/xemacs; then einfo You'd probably want to install app-emacs/lua-mode to; ewarn get Lua completion in emacs.; fi } but some people find that way annoying and some devs also thinks it is bad way. Another way (use USEflags-related PDEPs — is a bad way too). Any thoughts? :) There are many thoughts, iirc there was at least one 100+ long thread in august/september 2012. Search for SDEPEND and IUSE_RUNTIME in the mailing list logs. Also: https://bugs.gentoo.org/show_bug.cgi?id=373323 https://bugs.gentoo.org/show_bug.cgi?id=453618 But I cannot remember what was finally blocking them (specially solution pointed in second bug report)
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 15:55:23 -0500 William Hubbs willi...@gentoo.org wrote: We want to make this easier towards the user, therefore doing heavy discussion to exhaust all the alternatives and maybe someone's interested in implementing one of them that appears most feasible. Since users can already do this, why are we bothering with re-inventing the wheel? How does running an eselect init command make it easier for the user than telling them to edit their boot loader config file? Gentoo users are expected to build their kernel and write their boot loader config file initially, so why are we trying to dumb this down? For the same reason we have all the other eselect modules. http://www.gentoo.org/proj/en/eselect/ Ironically, that project description even mentions init system... :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Thu, May 30, 2013 at 02:06:42AM +0200, Tom Wijsman wrote: On Wed, 29 May 2013 15:55:23 -0500 William Hubbs willi...@gentoo.org wrote: We want to make this easier towards the user, therefore doing heavy discussion to exhaust all the alternatives and maybe someone's interested in implementing one of them that appears most feasible. Since users can already do this, why are we bothering with re-inventing the wheel? How does running an eselect init command make it easier for the user than telling them to edit their boot loader config file? Gentoo users are expected to build their kernel and write their boot loader config file initially, so why are we trying to dumb this down? For the same reason we have all the other eselect modules. We could probably also turn gcc-config into an eselect module if we want to use that argument. http://www.gentoo.org/proj/en/eselect/ Ironically, that project description even mentions init system... :) Yes, but the init system module that project refers to is already there. Check out eselect rc. It has nothing to do with switching init systems. It appears to be a wrapper around rc-update and a couple of other things to manage init scripts and runlevels. Thanks, William signature.asc Description: Digital signature
[gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
William Hubbs posted on Wed, 29 May 2013 19:22:32 -0500 as excerpted: We could probably also turn gcc-config into an eselect module if we want to use that argument. IIRC it actually was, at one point. The eselect gcc module even allowed separate configs for 32-bit and 64-bit on at least amd64/multilib. However, the gentoo dev, Jeremy Huddleston IIRC (tho I used to get him and another dev with I believe the same initials mixed up, so I might have gotten the wrong one), that developed and maintained the package moved on (IIRC to Apple... looks like he's still there if I'm googling the same one?), and nobody cared to take it up so it rotted until it was masked and I guess eventually removed. Since then I guess nobody's dared (or simply didn't have the prioritized time if they dared) mess with the existing gcc-config enough to try to turn it into an eselect module again. -- 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] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, May 29, 2013 at 09:56:00PM +0200, Tom Wijsman wrote Walter Dnes waltd...@waltdnes.org wrote: In order for a different init system to come up, some file(s) somewhere *MUST* be different, no ifs/ands/ors/buts. How true is this in general? It is usually only a change of the init parameter. Where is the init parameter changed? Even if it's only the append line in /etc/lilo.conf, my above statement still holds true. If you've got two identical machines with byte-identical hard drives, they can not boot two different OS's or init systems. The problem with an eselect approach is that it's like asking a brain surgeon to operate on himself. eselect and wrappers don't operate on themselves, please elaborate. The operating system is changing itself. [SNIP to shorten mail] Users can already do this, this isn't a solution. [SNIP to shorten mail] Again: Users can already do this, this isn't a solution. See above... If users can already do it themselves, then why this entire thread? Why do we need eselect/whatever? -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications