Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wednesday, June 29, 2011 22:19:09 Michał Górny wrote: > On Wed, 29 Jun 2011 16:46:13 -0500 William Hubbs wrote: > > Ok, the option that I'm looking at now is to set up openrc so that the > > init scripts are optional and whether or not they are installed is > > controlled by a use flag which I will default to on in IUSE. Most > > people would leave this flag alone, but if you want to use something > > like systemd and do not want the init scripts or the /etc/runlevels > > directory on your system, you would just re-emerge > > openrc with this flag disabled. > > > > For now this flag will just control init scripts installation, but I > > will also look into taking it further and not installing other parts > > of openrc, such as binaries, man pages, etc which are only used if > > you are working on init scripts. > > Wouldn't it be better to just leave these people with INSTALL_MASK? > USEflag means needless rebuilds just for the benefit of one file. so you're saying the solution for systemd users is to setup INSTALL_MASK and we shouldnt worry about tweaking openrc at all ? -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, 29 Jun 2011 16:46:13 -0500 William Hubbs wrote: > On Wed, Jun 29, 2011 at 12:56:32PM -0400, Mike Frysinger wrote: > > On Wed, Jun 29, 2011 at 10:57, William Hubbs wrote: > > > The third option is for openrc to not install the > > > symbolic link at /etc/init.d/functions.sh since the code is > > > actually at /lib/rc/functions.sh or /libexec/rc/functions.sh on > > > the bsds. If I do that in openrc, that would mean that baselayout > > > or another package would have to provide either a symbolic link in > > > /etc/init.d/functions.sh or a script there that provided the > > > functions if openrc was not available. > > > > this sounds bad on multiple levels > > Ok, the option that I'm looking at now is to set up openrc so that the > init scripts are optional and whether or not they are installed is > controlled by a use flag which I will default to on in IUSE. Most > people would leave this flag alone, but if you want to use something > like systemd and do not want the init scripts or the /etc/runlevels > directory on your system, you would just re-emerge > openrc with this flag disabled. > > For now this flag will just control init scripts installation, but I > will also look into taking it further and not installing other parts > of openrc, such as binaries, man pages, etc which are only used if > you are working on init scripts. > > Thoughts? Wouldn't it be better to just leave these people with INSTALL_MASK? USEflag means needless rebuilds just for the benefit of one file. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
2011/6/29 Olivier Crête : > systemd is where the innovation is today and we, Gentoo, > should get on board or be left behind. Certainly agree that systemd is innovative. I think this whole thing is becoming a bit moot. The openrc maintainer is already planning to add use flags to allow for clean comingling of the two init systems. Why don't we let everybody play around with and generally improve both, and then let the "market" sort it out as it were? I'd rather read planet.g.o articles about neat things being done with either systemd or openrc than a lot of bickering about which one is better on a mailing list. Give the users a choice, and then the distro can go with whatever proves to be stronger. As has long been a tradition in Gentoo we can also help to improve both upstream experiences while we're at it. Rich
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, 2011-06-29 at 16:46 +0100, Ciaran McCreesh wrote: > On Wed, 29 Jun 2011 11:14:22 -0400 > Olivier Crête wrote: > > And you also underestimate the amount of momentum that Lennart has > > managed to amass behind systemd. I expect that much sooner than you > > think, we won't have a choice but to switch to systemd as many core > > components will start depending on it. > > Ah, are we talking about the "GNOME Operating System" here? If so, I'd > rather see Gentoo drop Gnome than force everyone to switch to using > DistributionKit... When I became a Gentoo developer, 8 years ago, Gentoo had the most advanced init system of any distribution. It still works exactly the same, openrc being just a mostly pointless effort to re-do the same thing in C. systemd is where the innovation is today and we, Gentoo, should get on board or be left behind. And GNOME is indeed in the driving seat for much of the innovation in system components these days, because as Gnome developers, we fix the system components instead of working around their bugs. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, Jun 29, 2011 at 9:16 PM, Ciaran McCreesh wrote: > On Wed, 29 Jun 2011 11:14:22 -0400 > Olivier Crête wrote: >> And you also underestimate the amount of momentum that Lennart has >> managed to amass behind systemd. I expect that much sooner than you >> think, we won't have a choice but to switch to systemd as many core >> components will start depending on it. > > Ah, are we talking about the "GNOME Operating System" here? If so, I'd > rather see Gentoo drop Gnome than force everyone to switch to using > DistributionKit... > Yes, I agree. We should be like Slackware which dropped GNOME in 2005. What an excellent decision they made and it helped them retain so many users too... -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, Jun 29, 2011 at 12:56:32PM -0400, Mike Frysinger wrote: > On Wed, Jun 29, 2011 at 10:57, William Hubbs wrote: > > The third option is for openrc to not install the > > symbolic link at /etc/init.d/functions.sh since the code is actually at > > /lib/rc/functions.sh or /libexec/rc/functions.sh on the bsds. If I do > > that in openrc, that would mean that baselayout or another package > > would have to provide either a symbolic link in > > /etc/init.d/functions.sh or a script there that provided the functions > > if openrc was not available. > > this sounds bad on multiple levels Ok, the option that I'm looking at now is to set up openrc so that the init scripts are optional and whether or not they are installed is controlled by a use flag which I will default to on in IUSE. Most people would leave this flag alone, but if you want to use something like systemd and do not want the init scripts or the /etc/runlevels directory on your system, you would just re-emerge openrc with this flag disabled. For now this flag will just control init scripts installation, but I will also look into taking it further and not installing other parts of openrc, such as binaries, man pages, etc which are only used if you are working on init scripts. Thoughts? William pgpa6lm6LlVwb.pgp Description: PGP signature
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, Jun 29, 2011 at 06:05, Michał Górny wrote: > I'm not sure if it is a good idea to source a script mangling PATH > there. the mangling makes sure the system paths are present and come first. it doesnt remove any elements. it probably could be redone to only prepend elements, but i'm not sure the resulting behavior would be quite right when talking about / vs /usr vs /usr/local. also, the preference seen here is the same as provided by /etc/profile. to be sure, PATH handling in the script is ancillary to the general topic at hand. -mike
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, Jun 29, 2011 at 03:38, Ulrich Mueller wrote: >> On Wed, 29 Jun 2011, Mike Frysinger wrote: >> /etc/init.d/functions.sh has existed for the last decade, and >> was long ago decided as the canonical public entry point for >> scripts external to baselayout (as opposed to a path in >> /sbin/). >> >> the file should provide the classic e* output funcs that we've all >> grown to love, and are now enshrined in PMS. it has had other >> functions come and go over the years, but i think things have >> settled on just the output helpers. was there anything other than >> the output helpers you were interested in ? > > eselect also uses other functions from it, like rc_runlevel(). yes, but in this case, eselect is closely bound to what version (baselayout-1 vs openrc vs ...) is installed so that it can manage the init.d scripts and runlevels. as soon as the init code changes drastically, then the eselect module does as well. i think this is a different beast than what most every other external script is using it for. -mike
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, Jun 29, 2011 at 10:57, William Hubbs wrote: > The third option is for openrc to not install the > symbolic link at /etc/init.d/functions.sh since the code is actually at > /lib/rc/functions.sh or /libexec/rc/functions.sh on the bsds. If I do > that in openrc, that would mean that baselayout or another package > would have to provide either a symbolic link in > /etc/init.d/functions.sh or a script there that provided the functions > if openrc was not available. this sounds bad on multiple levels -mike
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, 29 Jun 2011 11:14:22 -0400 Olivier Crête wrote: > And you also underestimate the amount of momentum that Lennart has > managed to amass behind systemd. I expect that much sooner than you > think, we won't have a choice but to switch to systemd as many core > components will start depending on it. Ah, are we talking about the "GNOME Operating System" here? If so, I'd rather see Gentoo drop Gnome than force everyone to switch to using DistributionKit... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, 29 Jun 2011 17:31:43 +0200, Patrick Lauer wrote: On 06/29/11 17:14, Olivier Crête wrote: Stop polluting the thread with $init vs $init2, please. -Jeremy
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On 06/29/11 17:14, Olivier Crête wrote:
> On Wed, 2011-06-29 at 11:08 +0200, Patrick Lauer wrote:
>> On 06/29/11 03:07, Olivier Crête wrote:
>>> Hi,
>>>
>>> On Tue, 2011-06-28 at 17:10 -0500, William Hubbs wrote:
The background is that /etc/init.d/functions.sh is a link to
/lib/rc/functions.sh, which is part of openrc.
Other init systems, like systemd, are coming along which completely
replace sysvinit and do not use openrc's init scripts at all. However,
since things other than init scripts are using /etc/init.d/functions.sh,
all gentoo users are forced to have openrc on their systems whether they
use its init scripts or not.
As you can see in the bug, I am working on creating a
minimalist version of openrc that can be installed to allow users to
have access to the functions that are in functions.sh regardless of
whether or not they are using openrc's init system.
I'm not convinced that this is the best approach, so any input would be
greatly appreciated.
>>>
>>> As long as we have Gentoo-style init scripts in the tree, we will need
>>> these functions to be available. So yes, they should probably be in a
>>> separate package from openrc itself to ease the transition to the bright
>>> systemd future.
>>>
>> We tolerate the systemd madness as long as it doesn't interfere with
>> other things.
>>
>> But as OpenRC has some rare features ("being able to start and stop
>> stuff" and "being reasonably fast" among them) and there's no
>> replacement at the moment I see no reason to add a convoluted mess of
>> insanity just to feel good.
>
> I think you're missing how systemd is above and beyond OpenRC (and all
> other init systems). It has stuff like using cgroups to guarantee that
> all the processes associated with a service have stopped (openrc doesn't
> do that),
I've started playing around with it. Pretty tiny feature, I expect it to
end up as <200 lines of shell. Once I finish that openrc will support it
too, but without the Lennartizing that makes people so very joyful happy.
> it provides very fast boot (openrc doesn't do that),
Hmm, the comparisons I've seen are very mixed, with the performance
difference between 0 and 50% in favour of OpenRC. I haven't seen
anything catch OpenRC yet, but at least there's now an equivalent for
rc-status ...
> it can
> activate services on demand (openrc doesn't do that), etc..
What's the usecase for that? Sounds more like an antifeature (either
it's started or not, determinism rocks), and then there's things like
xinetd that tend to get deprecated and rediscovered every 5 years ...
What systemd can't do is run more than one command for a service, so ...
hmm ... that's a rather funny riddle. And it hides things behind an
opaque layer, so as soon as you need to edit internals (which I tend to
do about 2-3 times a year with OpenRC) you're going to have to stab
around in bad C instead of changing a simple shell script.
But - having seen the horrors that others do in shell I *understand* why
some people still think that shell-free startup is a good idea. It's
not. Leg-free humans are a good way to avoid broken toes ...
> And you also underestimate the amount of momentum that Lennart has
> managed to amass behind systemd. I expect that much sooner than you
> think, we won't have a choice but to switch to systemd as many core
> components will start depending on it.
>
You underestimate the amount of "positive feelings" that Lennart has
managed to create. Also for almost everyone else it adds functionality,
but we've had that for a long time. I mean, Upstart is still unable to
reliably start, stop or restart services. So migrating to systemd is
good. OpenRC has been doing that since the beginning, so we don't gain
anything. We just lose our flexible human-readable init scripts for no
gain at all - hey, why doesn't that sound like a bonus to me?
And you can bet that if anyone is so, how to say this politely, retarded
to think that depending on systemd is a good idea will discover that
people will patch around the stupid very fast.
Plus there's some of us that will never be able to use systemd because
it has artificial limitations in the kernels it supports. That's not a
good idea.
As much as I like your optimism, it's pretty much misguided and trying
to make my life more difficult. I hope you don't mind if I try to stop
you from creating work for me :)
--
Patrick Lauer http://service.gentooexperimental.org
Gentoo Council Member and Evangelist
Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, 2011-06-29 at 11:08 +0200, Patrick Lauer wrote:
> On 06/29/11 03:07, Olivier Crête wrote:
> > Hi,
> >
> > On Tue, 2011-06-28 at 17:10 -0500, William Hubbs wrote:
> >> The background is that /etc/init.d/functions.sh is a link to
> >> /lib/rc/functions.sh, which is part of openrc.
> >>
> >> Other init systems, like systemd, are coming along which completely
> >> replace sysvinit and do not use openrc's init scripts at all. However,
> >> since things other than init scripts are using /etc/init.d/functions.sh,
> >> all gentoo users are forced to have openrc on their systems whether they
> >> use its init scripts or not.
> >>
> >> As you can see in the bug, I am working on creating a
> >> minimalist version of openrc that can be installed to allow users to
> >> have access to the functions that are in functions.sh regardless of
> >> whether or not they are using openrc's init system.
> >>
> >> I'm not convinced that this is the best approach, so any input would be
> >> greatly appreciated.
> >
> > As long as we have Gentoo-style init scripts in the tree, we will need
> > these functions to be available. So yes, they should probably be in a
> > separate package from openrc itself to ease the transition to the bright
> > systemd future.
> >
> We tolerate the systemd madness as long as it doesn't interfere with
> other things.
>
> But as OpenRC has some rare features ("being able to start and stop
> stuff" and "being reasonably fast" among them) and there's no
> replacement at the moment I see no reason to add a convoluted mess of
> insanity just to feel good.
I think you're missing how systemd is above and beyond OpenRC (and all
other init systems). It has stuff like using cgroups to guarantee that
all the processes associated with a service have stopped (openrc doesn't
do that), it provides very fast boot (openrc doesn't do that), it can
activate services on demand (openrc doesn't do that), etc..
And you also underestimate the amount of momentum that Lennart has
managed to amass behind systemd. I expect that much sooner than you
think, we won't have a choice but to switch to systemd as many core
components will start depending on it.
--
Olivier Crête
tes...@gentoo.org
Gentoo Developer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, Jun 29, 2011 at 02:07:52AM -0400, Mike Frysinger wrote: > On Wednesday, June 29, 2011 01:48:16 Nirbheek Chauhan wrote: > > On Wed, Jun 29, 2011 at 10:35 AM, Mike Frysinger wrote: > > > On Wednesday, June 29, 2011 00:04:57 Michał Górny wrote: > > >> Honestly, I think a better solution would be to provide a convenience > > >> function library, independent of OpenRC. Sourcing random internal > > >> scripts of a random package is just broken by concept. > > > > > > except it hasnt been random and has clearly been defined by having > > > existed since the beginning of Gentoo > > > > I have no idea what this is supposed to mean. > > /etc/init.d/functions.sh has existed for the last decade, and was long ago > decided as the canonical public entry point for scripts external to > baselayout > (as opposed to a path in /sbin/). it isnt going anywhere, and painting it as > something in flux at this point is disingenuous. I never said that /etc/init.d/functions.sh should go anywhere. I guess I'm just questioning why core functionality for our distribution is part of an optional package. Yes, OpenRC is our default init system, but it is optional. If I put a separate package in portage, say called gentoo-core that has only the core functions, openrc and gentoo-core would have to block each other and packages that need the core functionality would have to depend on || ( sys-apps/openrc sys-apps/gentoo-core ). If I use a use flag for openrc (I'm thinking about core or minimal) to build only the necessary parts of it, that leaves these packages depending on sys-apps/openrc and the user controling the use flag. The third option is for openrc to not install the symbolic link at /etc/init.d/functions.sh since the code is actually at /lib/rc/functions.sh or /libexec/rc/functions.sh on the bsds. If I do that in openrc, that would mean that baselayout or another package would have to provide either a symbolic link in /etc/init.d/functions.sh or a script there that provided the functions if openrc was not available. Thoughts? William pgpwUtuOiFuBS.pgp Description: PGP signature
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, Jun 29, 2011 at 03:49:13PM +0400, Peter Volkov wrote: > В Срд, 29/06/2011 в 07:53 +0100, Ciaran McCreesh пишет: > > On Wed, 29 Jun 2011 02:47:36 -0400 > > Mike Frysinger wrote: > > > > Both. There's code in Paludis that duplicates a bunch of that stuff > > > > simply because I wasn't sure what I could and couldn't rely upon. > > > > > > the file should provide the classic e* output funcs that we've all > > > grown to love, and are now enshrined in PMS. it has had other > > > functions come and go over the years, but i think things have settled > > > on just the output helpers. was there anything other than the output > > > helpers you were interested in ? > > > > I seem to recall duplicating the colours stuff for Eselect too. But the > > variable names seem to be different there, and the 'portageq' call > > screws around with things, so perhaps by now things have diverged to the > > extent that it's easier to just keep similar but different code around. > > Having single location for this functions allows system wide > customization of colors... > > Personally I'd like to have this functions in separate package. What if > we'll provide two tarballs from the single openrc sources, e.g. > efunctions.tar.bz2 and openrc.tar.bz2, and correspodingly two packages? > openrc tarbal will have code for efunctions included but its > installation will be disabled in ebuild. This way we'll have full openrc > sources for those who need it and in Gentoo we'll have separate package > with efunctions for other packages to depend on. That is similar to what I'm looking at doing with openrc. What I'm thinking if we go that route is that openrc will have a use flag, "core", or something similar which will install enough of openrc to make those functions available. I am opposed to two separate packages; I think that is a lot more work than necessary. The disadvantage is that functions.sh is not a simple script; most of the functions are actually part of /sbin/rc which is a multi call binary, so I'll need to make sure the unnecessary functionality is disabled in the binary as well. William pgpIRplrGHXKH.pgp Description: PGP signature
[gentoo-dev] Lastrite: x11-libs/gtksourceview:1.0
# Pacho Ramos (29 Jun 2011) # Mask for removal in 30 days x11-libs/gtksourceview:1.0 # and reverse dependencies, bug #354241 =x11-libs/gtksourceview-1.8.5-r1 app-editors/conglomerate app-editors/mlview app-editors/screem dev-python/gtksourceview-python app-editors/scribes dev-ruby/ruby-gtksourceview =sci-electronics/oregano-0.69.0* signature.asc Description: This is a digitally signed message part
[gentoo-dev] PSF-2 license
gentoo-x86/licenses contains the following licenses:
PSF-2.2
PSF-2.3
PSF-2.4
PYTHON
PSF-2.2, PSF-2.3 and PSF-2.4 contain some versions of Python Software
Foundation License Version 2,
which differ only in versions of Python, copyright years etc. They also contain
some history of
Python and licenses for Python 2.0 and older versions.
PYTHON contains only some history of Python and licenses for Python 2.0 and
older versions.
I suggest that PSF-2 file is introduced, which will contain only Python
Software Foundation
License Version 2 with "" instead of some specific years and will
(slowly) replace
PSF-2.2, PSF-2.3, PSF-2.4 and PYTHON in values of LICENSE in ebuilds.
I'm attaching suggested PSF-2 file based on LICENSE file from default branch of
Python upstream
repository.
--
Arfrever Frehtes Taifersar Arahesis
PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2
1. This LICENSE AGREEMENT is between the Python Software Foundation
("PSF"), and the Individual or Organization ("Licensee") accessing and
otherwise using this software ("Python") in source or binary form and
its associated documentation.
2. Subject to the terms and conditions of this License Agreement, PSF hereby
grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce,
analyze, test, perform and/or display publicly, prepare derivative works,
distribute, and otherwise use Python alone or in any derivative version,
provided, however, that PSF's License Agreement and PSF's notice of copyright,
i.e., "Copyright (c) Python Software Foundation; All Rights Reserved"
are retained in Python alone or in any derivative version prepared by Licensee.
3. In the event Licensee prepares a derivative work that is based on
or incorporates Python or any part thereof, and wants to make
the derivative work available to others as provided herein, then
Licensee hereby agrees to include in any such work a brief summary of
the changes made to Python.
4. PSF is making Python available to Licensee on an "AS IS"
basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND
DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON WILL NOT
INFRINGE ANY THIRD PARTY RIGHTS.
5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON
FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS
A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON,
OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.
6. This License Agreement will automatically terminate upon a material
breach of its terms and conditions.
7. Nothing in this License Agreement shall be deemed to create any
relationship of agency, partnership, or joint venture between PSF and
Licensee. This License Agreement does not grant permission to use PSF
trademarks or trade name in a trademark sense to endorse or promote
products or services of Licensee, or any third party.
8. By copying, installing or otherwise using Python, Licensee
agrees to be bound by the terms and conditions of this License
Agreement.
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] The Python problem
2011-06-27 22:57:05 Thomas Sachau napisał(a):
> Dirkjan Ochtman wrote:
> > On Mon, Jun 27, 2011 at 15:08, Fabian Groffen wrote:
> >> On 27-06-2011 14:28:34 +0200, Dirkjan Ochtman wrote:
> >> It would be nice when a similar technique could be implemented only
> >> once, in a consistent way. In a way, multilib-portage can be considered
> >> equal to one of the objectives of the python (and ruby) eclass:
> >> multiple times compiling and installing for different ABIs.
> >
> > Yeah, but it'd be nice not to have to compile subversion three times
> > just because we want the python bindings installed in three different
> > Python environments.
>
> You wont be able to prevent this with a general solution, only with some
> specialized solution inside
> the build, if you really want and need that.
> Currently, if you want python bindings for three different python
> environments, you will have to
> build everything for all three python environments, even if you only need a
> subset.
Building everything for all Python ABIs is not required in case of majority of
packages, which
optionally install Python bindings. Makefiles of many packages (including
dev-vcs/subversion)
provide separate targets for building/installation of core libraries and
various bindings.
Example:
src_compile() {
emake || die
if use python; then
python_copy_sources bindings/python
build_python_bindings() {
emake \
PYTHON_INCLUDES="$(python_get_includedir)" \
PYTHON_SITE_PACKAGES="$(python_get_sitedir)" \
python_bindings
}
python_execute_function -s --source-dir bindings/python
build_python_bindings
fi
}
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Thoughts about broken package handling
2011-06-26 13:48:02 Thomas Sachau napisał(a):
> In case of slotted dependencies (like python, ruby or php), this would also
> allow the user to define
> per package, if he wants support for one or more slots of e.g. python.
You can set USE_PYTHON in /etc/portage/env/${CATEGORY}/${PN} or
/etc/portage/env/${CATEGORY}/${PN}:${SLOT}.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] The Python problem
2011-06-29 02:33:34 Jesus Rivero (Neurogeek) napisał(a): > With python-updater, well, some time ago Ali Polatel implemented some > approaches to get rid of python-updater, by exporting some variable in > ebuilds that needed to be rebuilt when new python versions were > installed. I dont recall what happened with that, but we could think > of some ways to finally get rid of python-updater. He added python_need_rebuild() function, which sets PYTHON_NEED_REBUILD variable, which is checked by python-updater, so that python-updater can avoid checking CONTENTS files in VDB and calling scanelf on all installed files. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] removing of autotools from system set
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 29-06-2011 06:53, Mike Frysinger wrote: > now that we have autotools.eclass to ease regenerating of autotools in > ebuilds and people have generally adopted this tree-wide, i'd like to > look at dropping autoconf, automake, and libtool from the system set. > > i'll wait for the current stage-breaking issue to get sorted out (/dev > nodes in stage3) before making the commit, but i want to get this out > there asap because i love making Jorge work for it. Yay, more work for me :-P I've started a new local build to test this. > i dont think we'll need to add them to packages.build for stage1 as > all the deps should be correct. > > any other issues people can think of ? > -mike > - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJOCxaLAAoJEC8ZTXQF1qEPSsAQAJterew5pclN83Hw86FRyBW+ 72fd9eDYVJ6wBtj0BwW+FIWkQJrb59Hhs9gkHjiCAjmc/sPnU2vaUkZlI380d+/x Yg7bLIBmWpkaqxdEDFHHFAjdtpLxyTnExmE9N2cvu5ZgxlZjFSRo2QjzufOPwtn+ 3+A/haOZqr3Y6wu6dEftkArLjqzgT/l/WO+pQX5chQ8OCJ521rI1HRFA0fuR1vm9 nsSxrACI6KPB57NtxsG36IX1FdFuRWYxCNcs2N7WHS5Dx3ZQLTpJq9ZYPRtKn2XS Sdrre6bkKH+WTLzaJq2xy6kWC/q/prUbUC63c3oiHIwsSOATETVMMjS74IHGPTR9 EGO4q3//cDNxr4LL3KZMac8NzIKSRW4BrcsrpD77s88QjJCSGpJ4Cybfu7S8ujve L4CSwoGMxMI7vwh5c5tHdb5bj4zHBg9Mffsn4KObMQnKiw0kuQI6OUh2OYSZJ/sj Z9Byx/8QWCuB5Fz9E8y/dPMK48tfM3OTVVcHBvZMsnvJvBcHjSf21j7/9cpP17yY BM9LKBOdLUqXBkENXDIix4FRM+zjaEIV38yqJOgiEtQONJ/zq4S6O6fsYblkhS84 42aIjIHalj9c3EqejyTWEj2hxZI1dOCXNu/pHj6Eb48G5L9pTMwYxhxuXqxtDfu4 qwYyu+19mmYDxD0rIA5v =wDME -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
В Срд, 29/06/2011 в 07:53 +0100, Ciaran McCreesh пишет: > On Wed, 29 Jun 2011 02:47:36 -0400 > Mike Frysinger wrote: > > > Both. There's code in Paludis that duplicates a bunch of that stuff > > > simply because I wasn't sure what I could and couldn't rely upon. > > > > the file should provide the classic e* output funcs that we've all > > grown to love, and are now enshrined in PMS. it has had other > > functions come and go over the years, but i think things have settled > > on just the output helpers. was there anything other than the output > > helpers you were interested in ? > > I seem to recall duplicating the colours stuff for Eselect too. But the > variable names seem to be different there, and the 'portageq' call > screws around with things, so perhaps by now things have diverged to the > extent that it's easier to just keep similar but different code around. Having single location for this functions allows system wide customization of colors... Personally I'd like to have this functions in separate package. What if we'll provide two tarballs from the single openrc sources, e.g. efunctions.tar.bz2 and openrc.tar.bz2, and correspodingly two packages? openrc tarbal will have code for efunctions included but its installation will be disabled in ebuild. This way we'll have full openrc sources for those who need it and in Gentoo we'll have separate package with efunctions for other packages to depend on. -- Peter.
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, Jun 29, 2011 at 5:08 AM, Patrick Lauer wrote: > We tolerate the systemd madness as long as it doesn't interfere with > other things. I'd say that "welcome" is a better word than "tolerate" - after all, Gentoo is about choice. :) Still, I do agree that we should avoid disruptive changes to existing system packages for the sake of packages that are still fairly experimental on Gentoo. The most elegant solution is probably to split up openrc, but the original suggestion was to just make an "openrc-lite" of some sort and that seems like a much safer interim solution until systemd has some kind of critical mass around it. By then there might be a few other experimental init systems floating around and any serious changes might be more informed than anything we do now. The advantages and disadvantages of any particular init system, desktop environment, or text-editor/OS-combo aren't terribly relevant to this issue. Rich
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On 06/29/2011 05:08 AM, Patrick Lauer wrote:
> On 06/29/11 03:07, Olivier Crête wrote:
>> Hi,
>>
>> On Tue, 2011-06-28 at 17:10 -0500, William Hubbs wrote:
>>> The background is that /etc/init.d/functions.sh is a link to
>>> /lib/rc/functions.sh, which is part of openrc.
>>>
>>> Other init systems, like systemd, are coming along which completely
>>> replace sysvinit and do not use openrc's init scripts at all. However,
>>> since things other than init scripts are using /etc/init.d/functions.sh,
>>> all gentoo users are forced to have openrc on their systems whether they
>>> use its init scripts or not.
>>>
>>> As you can see in the bug, I am working on creating a
>>> minimalist version of openrc that can be installed to allow users to
>>> have access to the functions that are in functions.sh regardless of
>>> whether or not they are using openrc's init system.
>>>
>>> I'm not convinced that this is the best approach, so any input would be
>>> greatly appreciated.
>> As long as we have Gentoo-style init scripts in the tree, we will need
>> these functions to be available. So yes, they should probably be in a
>> separate package from openrc itself to ease the transition to the bright
>> systemd future.
>>
> We tolerate the systemd madness as long as it doesn't interfere with
> other things.
>
> But as OpenRC has some rare features ("being able to start and stop
> stuff" and "being reasonably fast" among them) and there's no
> replacement at the moment I see no reason to add a convoluted mess of
> insanity just to feel good.
>
Hi Patrick,
I started the madness :) But it wasn't because I didn't prefer openrc
over all other init systems, but because I wanted to create minimal
chroot environments without any init system whatsoever. In addition to
opening up the choice for our users, this also avoids ugly DEPENDs in
our ebuilds, like eix or gentoolkit which, strictly speaking, should
depend on openrc to provide functions.sh and don't currently.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
Re: [gentoo-dev] The Python problem
El mié, 29-06-2011 a las 09:18 +0200, Andreas K. Huettel escribió: > Am Mittwoch, 29. Juni 2011, 06:34:52 schrieb Michał Górny: > > > > > As I said it already, we could start doing things simpler in the > > > current python.eclass and maybe that would attract some devs to help > > > out with it, as they find it more comfortable to work with. > > > > I think it would be better to simply start from scratch with > > a clean python-2.eclass. Instead of adding new features and another lot > > of conditionals for EAPI=4, just make that code a part of new eclass. > > > > Ack. The cleanest way would definitely be to start from scratch, and provide > a > long transition period. Please please make things similar compared to the > other language eclasses, though... > Arfrever added support for eapi4 in python-overlay, maybe trying to move it to the tree would be faster :-/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, 29 Jun 2011 07:38:45 +0100 Ciaran McCreesh wrote: > On Wed, 29 Jun 2011 02:36:05 -0400 > Mike Frysinger wrote: > > On Wed, Jun 29, 2011 at 02:14, Ciaran McCreesh wrote: > > > On Wed, 29 Jun 2011 02:07:52 -0400 Mike Frysinger wrote: > > >> /etc/init.d/functions.sh has existed for the last decade, and was > > >> long ago decided as the canonical public entry point for scripts > > >> external to baselayout (as opposed to a path in /sbin/). it isnt > > >> going anywhere, and painting it as something in flux at this > > >> point is disingenuous. > > > > > > Is it documented and specified? If not, can it be? > > > > the file path ? or the API that it provides ? > > Both. There's code in Paludis that duplicates a bunch of that stuff > simply because I wasn't sure what I could and couldn't rely upon. I'm not sure if it is a good idea to source a script mangling PATH there. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On 06/29/11 03:07, Olivier Crête wrote:
> Hi,
>
> On Tue, 2011-06-28 at 17:10 -0500, William Hubbs wrote:
>> The background is that /etc/init.d/functions.sh is a link to
>> /lib/rc/functions.sh, which is part of openrc.
>>
>> Other init systems, like systemd, are coming along which completely
>> replace sysvinit and do not use openrc's init scripts at all. However,
>> since things other than init scripts are using /etc/init.d/functions.sh,
>> all gentoo users are forced to have openrc on their systems whether they
>> use its init scripts or not.
>>
>> As you can see in the bug, I am working on creating a
>> minimalist version of openrc that can be installed to allow users to
>> have access to the functions that are in functions.sh regardless of
>> whether or not they are using openrc's init system.
>>
>> I'm not convinced that this is the best approach, so any input would be
>> greatly appreciated.
>
> As long as we have Gentoo-style init scripts in the tree, we will need
> these functions to be available. So yes, they should probably be in a
> separate package from openrc itself to ease the transition to the bright
> systemd future.
>
We tolerate the systemd madness as long as it doesn't interfere with
other things.
But as OpenRC has some rare features ("being able to start and stop
stuff" and "being reasonably fast" among them) and there's no
replacement at the moment I see no reason to add a convoluted mess of
insanity just to feel good.
--
Patrick Lauer http://service.gentooexperimental.org
Gentoo Council Member and Evangelist
Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
> On Wed, 29 Jun 2011, Mike Frysinger wrote: >>> >> /etc/init.d/functions.sh has existed for the last decade, and >>> >> was long ago decided as the canonical public entry point for >>> >> scripts external to baselayout (as opposed to a path in >>> >> /sbin/). > the file should provide the classic e* output funcs that we've all > grown to love, and are now enshrined in PMS. it has had other > functions come and go over the years, but i think things have > settled on just the output helpers. was there anything other than > the output helpers you were interested in ? eselect also uses other functions from it, like rc_runlevel(). Ulrich
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, Jun 29, 2011 at 02:53, Ciaran McCreesh wrote: > On Wed, 29 Jun 2011 02:47:36 -0400 Mike Frysinger wrote: >> > Both. There's code in Paludis that duplicates a bunch of that stuff >> > simply because I wasn't sure what I could and couldn't rely upon. >> >> the file should provide the classic e* output funcs that we've all >> grown to love, and are now enshrined in PMS. it has had other >> functions come and go over the years, but i think things have settled >> on just the output helpers. was there anything other than the output >> helpers you were interested in ? > > I seem to recall duplicating the colours stuff for Eselect too. But the > variable names seem to be different there, and the 'portageq' call > screws around with things, so perhaps by now things have diverged to the > extent that it's easier to just keep similar but different code around. the env var names should be the same as they've always been, but this wasnt generally something i focused on. i dont think PMS does either. although in looking and some scripts which use it, they sometimes leverage the env vars directly, so i guess encoding it should be simple enough. just documenting what has always been. openrc's functions.sh doesnt call portageq, so i'm not sure what you're referring to there. the func names and behavior between openrc shouldnt have diverged from what portage/PMS does. if it has, probably should open a bug for it. -mike
Re: [gentoo-dev] The Python problem
Am Mittwoch, 29. Juni 2011, 06:34:52 schrieb Michał Górny: > > > As I said it already, we could start doing things simpler in the > > current python.eclass and maybe that would attract some devs to help > > out with it, as they find it more comfortable to work with. > > I think it would be better to simply start from scratch with > a clean python-2.eclass. Instead of adding new features and another lot > of conditionals for EAPI=4, just make that code a part of new eclass. > Ack. The cleanest way would definitely be to start from scratch, and provide a long transition period. Please please make things similar compared to the other language eclasses, though... -- Andreas K. Huettel (dilfridge) Gentoo Linux developer kde, sci, arm, tex
