Re: [gentoo-dev] Better handling of USE flags to enable/disable system libraries

2013-05-29 Thread Sergey Popov
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

2013-05-29 Thread Michael Palimaka

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

2013-05-29 Thread 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?






Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

2013-05-29 Thread Tom Wijsman
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

2013-05-29 Thread Michael Weber
-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

2013-05-29 Thread Alexey Shvetsov
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

2013-05-29 Thread Michael Palimaka

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

2013-05-29 Thread Michael Palimaka

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

2013-05-29 Thread hasufell
-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

2013-05-29 Thread Michael Palimaka

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

2013-05-29 Thread Vadim A. Misbakh-Soloviov
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

2013-05-29 Thread Ian Stakenvicius
-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

2013-05-29 Thread Walter Dnes
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

2013-05-29 Thread Tom Wijsman
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

2013-05-29 Thread William Hubbs
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

2013-05-29 Thread Pacho Ramos
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

2013-05-29 Thread Tom Wijsman
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

2013-05-29 Thread William Hubbs
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

2013-05-29 Thread Duncan
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

2013-05-29 Thread Walter Dnes
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