Re: [gentoo-dev] rfc: deprecation of baselayout-1.x

[Ulrich Mueller]

> On Thu, 30 Jun 2011, William Hubbs wrote:

> Please discuss. Did I leave out any steps? Are there any points I
> have left out besides the time window between steps 2 and 3? Should
> there be a time window before removing baselayout-1? What about
> between steps 1 and 2? What do you consider to be a reasonable time
> window before we stop supporting migration from baselayout-1 to
> baselayout-2/openrc? I'm thinking on the order of a few months, but
> not years.

We have a policy on this, see 
:

| Upgrade path for old systems
| 
| Vote (unanimous): The ebuild tree must provide an upgrade path to a
| stable system that hasn't been updated for one year.

So the time window should be at least one year after stabilisation of
baselayout-2 and openrc.

Ulrich

Re: [gentoo-dev] rfc: deprecation of baselayout-1.x

[Dale]

Nirbheek Chauhan wrote:

On Fri, Jul 1, 2011 at 11:03 AM, Dale  wrote:
   

William Hubbs wrote:
As a user, if a person hasn't upgraded in about 6 months, they may as well
reinstall anyway.  That is usually the advice given on -user.  After a year
without updating, it is certainly easier and most likely faster to
reinstall.
 

Except for the fact that while you upgrade, you still have a usable
system. Reinstallation means a massive time-sink during which your
machine is completely unusable. This is not an option for a lot of
people.

If -user is regularly giving that kind of advice, I think you guys are
making a huge mistake.

I'm not going to support this kind of max-6-month-upgrade life cycle
for Gentoo. We're effectively driving our users away to distros like
Ubuntu that allow you to upgrade every LTS release instead of
constantly or every 6 months.

   


Well, it has been done.  A while ago, if I recall this correctly, 
someone hadn't updated in about a year.  He tried to upgrade but ran 
into issue after issue.  After a couple days, he ended up reinstalling.  
It just depends on what updates have come along that causes issues.


I think things are better than they used to be but sometimes, it is 
faster to just reinstall and be done with it.  It's either spend a day 
or more dealing with problems or spending a day getting a fresh start.


As for not having a system, I have one when I do my install.  I just 
boot Knoppix and use it.  I can use a web browser to follow the docs and 
check email.  It's one of many ways to install Gentoo.


It's not about what Gentoo supports, it's about what is faster, easier 
or at times, both.


Dale

:-)  :-)

Re: [gentoo-dev] rfc: deprecation of baselayout-1.x

[Nirbheek Chauhan]

On Fri, Jul 1, 2011 at 11:03 AM, Dale  wrote:
> William Hubbs wrote:
> As a user, if a person hasn't upgraded in about 6 months, they may as well
> reinstall anyway.  That is usually the advice given on -user.  After a year
> without updating, it is certainly easier and most likely faster to
> reinstall.

Except for the fact that while you upgrade, you still have a usable
system. Reinstallation means a massive time-sink during which your
machine is completely unusable. This is not an option for a lot of
people.

If -user is regularly giving that kind of advice, I think you guys are
making a huge mistake.

I'm not going to support this kind of max-6-month-upgrade life cycle
for Gentoo. We're effectively driving our users away to distros like
Ubuntu that allow you to upgrade every LTS release instead of
constantly or every 6 months.


-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] rfc: deprecation of baselayout-1.x

[Dale]

William Hubbs wrote:

All,

the time has come when baselayout-2.x and openrc are stable on all of
our architectures. That means that we should look into removing
baselayout-1 from the tree, removing support for it from our init
scripts and removing support for migration from the openrc
ebuilds.

1. we can remove baselayout-1 from the tree, I think, as soon as bug
#368597 is closed, because once that is done, all new installs should
be based on baselayout-2.x and openrc.

2. The next step is to reverse the changes we made in bug #273138 and
any other init scripts that have been reacting differently depending on
whether they were under baselayout-1 or openrc. Optionally we could
rework init scripts to take advantage of openrc specific features such
as the *_pre/post functions at this point.

Once this is completed, the init scripts in portage will not support
baselayout-1, so if anyone is still on baselayout-1 we should find a way
to encourage them to migrate -- maybe a news item? Also, we should come
up with a time window that will be published in this news item that will
mark the end of supporting migration from baselayout-1 to openrc.

3. The final step is to remove the code from the openrc ebuilds that
supports migrating from baselayout-1.x. Once we do this another news
item should be published since this is the point of no return; anyone
running a baselayout-1 based system will have to re-install to upgrade
once we drop this support.

Please discuss. Did I leave out any steps? Are there any  points I have
left out besides the time window between steps 2 and 3? Should there be
a time window before removing baselayout-1? What about between steps 1
and 2? What do you consider to be a reasonable time window before we
stop supporting migration from baselayout-1 to baselayout-2/openrc? I'm
thinking on the order of a few months, but not years.

Thanks,

William

   


As a user, if a person hasn't upgraded in about 6 months, they may as 
well reinstall anyway.  That is usually the advice given on -user.  
After a year without updating, it is certainly easier and most likely 
faster to reinstall.  Almost everything will be updated and there is 
usually a few upgrades that are touchy and will have to be dealt with.


My thoughts, after a year, baselayout1 could be laid to rest.  At that 
point, a reinstall would be the easiest and fastest anyway.


Just a users perspective.  YMMV.

Dale

:-)  :-)

[gentoo-dev] rfc: deprecation of baselayout-1.x

[William Hubbs]

All,

the time has come when baselayout-2.x and openrc are stable on all of
our architectures. That means that we should look into removing
baselayout-1 from the tree, removing support for it from our init
scripts and removing support for migration from the openrc
ebuilds.

1. we can remove baselayout-1 from the tree, I think, as soon as bug
#368597 is closed, because once that is done, all new installs should
be based on baselayout-2.x and openrc.

2. The next step is to reverse the changes we made in bug #273138 and
any other init scripts that have been reacting differently depending on
whether they were under baselayout-1 or openrc. Optionally we could
rework init scripts to take advantage of openrc specific features such
as the *_pre/post functions at this point.

Once this is completed, the init scripts in portage will not support
baselayout-1, so if anyone is still on baselayout-1 we should find a way
to encourage them to migrate -- maybe a news item? Also, we should come
up with a time window that will be published in this news item that will
mark the end of supporting migration from baselayout-1 to openrc.

3. The final step is to remove the code from the openrc ebuilds that
supports migrating from baselayout-1.x. Once we do this another news
item should be published since this is the point of no return; anyone
running a baselayout-1 based system will have to re-install to upgrade
once we drop this support.

Please discuss. Did I leave out any steps? Are there any  points I have
left out besides the time window between steps 2 and 3? Should there be
a time window before removing baselayout-1? What about between steps 1
and 2? What do you consider to be a reasonable time window before we
stop supporting migration from baselayout-1 to baselayout-2/openrc? I'm
thinking on the order of a few months, but not years.

Thanks,

William



pgpe1aEgTfPwn.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Mike Frysinger]

On Thu, Jun 30, 2011 at 17:30, Michał Górny wrote:
> On Thu, 30 Jun 2011 17:16:14 -0400 Mike Frysinger wrote:
>> On Thu, Jun 30, 2011 at 17:14, Michał Górny wrote:
>> > On Wed, 29 Jun 2011 23:47:42 -0400 Mike Frysinger wrote:
>> >> 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 ?
>> >
>> > Have you even heard the word called 'context'? It might be too short
>> > for your taste.
>>
>> perhaps if you focused less on being snarky and more on the thread
>> content, you'd realize that the context here is "providing
>> /etc/init.d/functions.sh support for non-openrc users".  that was the
>> point of William's e-mail that is at the start of this current
>> "context".
>
> And if you focused more on reading what others write, you'd realize
> that the whole citation here mentions only installing init.d scripts
> and /etc/runlevels?

umm, no.  that's actually the opposite of what William said.  the
ultimate direction is exactly as i described, and William is hashing
out different ways to get there.

so yes, focus less on snarky and more on contributing something useful.
-mike

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[William Hubbs]

On Thu, Jun 30, 2011 at 11:30:51PM +0200, Michał Górny wrote:
> On Thu, 30 Jun 2011 17:16:14 -0400
> Mike Frysinger  wrote:
> 
> > On Thu, Jun 30, 2011 at 17:14, Michał Górny wrote:
> > > On Wed, 29 Jun 2011 23:47:42 -0400 Mike Frysinger wrote:
> > >> 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 ?
> > >
> > > Have you even heard the word called 'context'? It might be too short
> > > for your taste.
> > 
> > perhaps if you focused less on being snarky and more on the thread
> > content, you'd realize that the context here is "providing
> > /etc/init.d/functions.sh support for non-openrc users".  that was the
> > point of William's e-mail that is at the start of this current
> > "context".
> 
> And if you focused more on reading what others write, you'd realize
> that the whole citation here mentions only installing init.d scripts
> and /etc/runlevels?

We are trying to  hash out a way to make /etc/init.d/functions.sh
available to all users, regardless of the init system they are using.

The issue is that right now /etc/init.d/functions.sh is a symbolic link
owned by OpenRC which points to /lib/rc/sh/functions.sh. Also,
/lib/rc/sh/functions.sh in openrc really isn't much of a script, most of the e*
functions are part of the /sbin/rc binary which is a multi call binary.

We have some gentoo base functions which should be available
on all gentoo systems built into the OpenRC init system. This was fine
in the day when OpenRC was the only init system we used, but now it
isn't fine because it is requiring everyone to have OpenRC and sysvinit
installed even if they do not want to use them.

I do not want to deprecate *any* gentoo base functions. I just want to
make them all available in a way that does not force a dependency on
OpenRC and sysvinit.

The discussion on the bug has now evolved to having a separate package,
gentoo-base-functions, that provides these base functions.

William



pgpodFV8Q0eeX.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Michał Górny]

On Thu, 30 Jun 2011 17:16:14 -0400
Mike Frysinger  wrote:

> On Thu, Jun 30, 2011 at 17:14, Michał Górny wrote:
> > On Wed, 29 Jun 2011 23:47:42 -0400 Mike Frysinger wrote:
> >> 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 ?
> >
> > Have you even heard the word called 'context'? It might be too short
> > for your taste.
> 
> perhaps if you focused less on being snarky and more on the thread
> content, you'd realize that the context here is "providing
> /etc/init.d/functions.sh support for non-openrc users".  that was the
> point of William's e-mail that is at the start of this current
> "context".

And if you focused more on reading what others write, you'd realize
that the whole citation here mentions only installing init.d scripts
and /etc/runlevels?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: optinal run time dependencies

[Michał Górny]

After some thinking, I'd like to re-state the USE_EXPAND variant
as having the following advantages:

1) backwards compatible -- we can make the new feature optional for
older EAPIs, making it useful for older ebuilds as well. If a PM
doesn't support it, it will just treat them as ordinary USE;

2) almost no new learning for users -- as users set flags now, they can
set optional deps;

3) dep (or dep groups) would be named by features and not only package
names,

4) easy grouping of optional dependencies -- if a particular feature
requires more than one optional package,

5) ability to use existing infra -- REQUIRED_USE, metadata.xml for
descriptions.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Mike Frysinger]

On Thu, Jun 30, 2011 at 17:14, Michał Górny wrote:
> On Wed, 29 Jun 2011 23:47:42 -0400 Mike Frysinger wrote:
>> 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 ?
>
> Have you even heard the word called 'context'? It might be too short
> for your taste.

perhaps if you focused less on being snarky and more on the thread
content, you'd realize that the context here is "providing
/etc/init.d/functions.sh support for non-openrc users".  that was the
point of William's e-mail that is at the start of this current
"context".
-mike

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Michał Górny]

On Wed, 29 Jun 2011 23:47:42 -0400
Mike Frysinger  wrote:

> 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 ?

Have you even heard the word called 'context'? It might be too short
for your taste.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Add support for RDMA enabled devices in main tree

[Alexey Shvetsov]

On Thursday 30 of June 2011 20:54:21 Robin H. Johnson wrote:
> On Thu, Jun 30, 2011 at 10:40:26PM +0400, Alexey Shvetsov wrote:
> > I'm working on putting infiniband support to main tree. Currently
> > infiniband related stuff hosted in science overlay in sys-infiniband
> > [1] category (this category currently contains ~25 packages but they
> > will be ~40) so i wanna move them as whole category. Also i'm going to
> > add USE_EXPAND for infiniband
> > userspace drivers:
> Why a new category of sys-infiniband vs. existing sys-* categories.
> I thought I had seen some existing infiniband packages lurking in the
> tree.

Because its very scpecific stuff containing system libs and userspace drivers 
and daemons that will make ib hw functional =)
-- 
Best Regards,
 Alexey 'Alexxy' Shvetsov
 Petersburg Nuclear Physics Institute, 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.

Re: [gentoo-dev] [RFC] Add support for RDMA enabled devices in main tree

[Robin H. Johnson]

On Thu, Jun 30, 2011 at 10:40:26PM +0400, Alexey Shvetsov wrote:
> I'm working on putting infiniband support to main tree. Currently infiniband 
> related stuff hosted in science overlay in sys-infiniband [1] category (this 
> category currently contains ~25 packages but they will be ~40) so i wanna 
> move 
> them as whole category. Also i'm going to add USE_EXPAND for infiniband 
> userspace drivers:
Why a new category of sys-infiniband vs. existing sys-* categories.
I thought I had seen some existing infiniband packages lurking in the
tree.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] [RFC] Add support for RDMA enabled devices in main tree

[Mike Frysinger]

On Thu, Jun 30, 2011 at 15:13, Alexey Shvetsov wrote:
> On Thursday 30 of June 2011 14:47:06 Mike Frysinger wrote:
>> On Thu, Jun 30, 2011 at 14:40, Alexey Shvetsov wrote:
>> > Also i'm going to add USE_EXPAND for infiniband userspace drivers:
>> > libmlx4
>> > libmthca
>> > libehca
>> > libcxgb3
>
> use will be something like OPENIB_DRIVERS="mlx4 mthca ehca cxgb3"
>
> Honestly i can only tests first two.

i dont think that's a problem.  no one is expecting you to validate
every piece of hardware.
-mike

Re: [gentoo-dev] [RFC] Add support for RDMA enabled devices in main tree

[Alexey Shvetsov]

On Thursday 30 of June 2011 14:47:06 Mike Frysinger wrote:
> On Thu, Jun 30, 2011 at 14:40, Alexey Shvetsov wrote:
> > Also i'm going to add USE_EXPAND for infiniband userspace drivers:
> > libmlx4
> > libmthca
> > libehca
> > libcxgb3

use will be something like OPENIB_DRIVERS="mlx4 mthca ehca cxgb3"

Honestly i can only tests first two. 

Also since mlx4 ib driver wants kernel with xrc support i gonna add 'cluster-
sources' to tree and use flag 'xrc' to virtual/linux-sources-2.6 so sys-
infiniband/libmlx4 will depend on it.

So if there will be no objections i'll proceed with this stuff =)
And I'll move it to tree in an hour or so.


> 
> should it be based on the hardware family rather than the lib name ?
> 
> > Any objections about moving this stuff to tree?
> 
> i object to it not being done already ! ;)
> -mike
-- 
Best Regards,
 Alexey 'Alexxy' Shvetsov
 Petersburg Nuclear Physics Institute, 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.

Re: [gentoo-dev] [RFC] Add support for RDMA enabled devices in main tree

[Mike Frysinger]

On Thu, Jun 30, 2011 at 14:40, Alexey Shvetsov wrote:
> Also i'm going to add USE_EXPAND for infiniband userspace drivers:
> libmlx4
> libmthca
> libehca
> libcxgb3

should it be based on the hardware family rather than the lib name ?

> Any objections about moving this stuff to tree?

i object to it not being done already ! ;)
-mike

[gentoo-dev] [RFC] Add support for RDMA enabled devices in main tree

[Alexey Shvetsov]

Hi all!

I'm working on putting infiniband support to main tree. Currently infiniband 
related stuff hosted in science overlay in sys-infiniband [1] category (this 
category currently contains ~25 packages but they will be ~40) so i wanna move 
them as whole category. Also i'm going to add USE_EXPAND for infiniband 
userspace drivers:
libmlx4
libmthca
libehca
libcxgb3

Any objections about moving this stuff to tree?

PS some in-tree stuff already has infiniband use flag so i'd like to make it 
global or may be rename it to rdma

[1] http://git.overlays.gentoo.org/gitweb/?p=proj/sci.git;a=tree;f=sys-
infiniband;h=5442f68fcaa8cedde34772915c605fdbab8d5541;hb=HEAD
-- 
Best Regards,
 Alexey 'Alexxy' Shvetsov
 Petersburg Nuclear Physics Institute, 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.

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[William Hubbs]

Hi Paul and everyone,

On Thu, Jun 30, 2011 at 11:04:04AM -0400, Mike Frysinger wrote:
> On Thu, Jun 30, 2011 at 08:58, Paul de Vrieze wrote:
> > Why can't we just split up functions.sh into "/lib/output.sh"
> 
> we're not changing the file name

I just made a case on the bug for having a separate package called
gentoo-base-functions which contains a script called
/etc/init.d/functions.sh which would be smart enough to use openrc if it
is available and provide the functions if it is not [1]. Please take a
look and comment.

William

[1] http://bugs.gentoo.org/show_bug.cgi?id=373219#C31



pgpsXlGeOkhio.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Rich Freeman]

On Jun 30, 2011 11:06 AM, "Mike Frysinger"  wrote:
>
> we're not splitting the source trees.  the reasons have already been
> detailed in the bug open on the topic.
> -mike
>

I think we're generally aiming for perfection when we should be pragmatic.
The proposed solution isn't ideal, but is workable and I think that further
improvement should wait until systemd/etc is mainstream (if ever).

There is a similar tendency in the tags thread to aim for the revolutionary
and elegant solution for everything when we basically just need some search
keywords to get started...

Rich

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Mike Frysinger]

On Thu, Jun 30, 2011 at 08:58, Paul de Vrieze wrote:
> Why can't we just split up functions.sh into "/lib/output.sh"

we're not changing the file name

> containing the init script independent (but often gentoo specific)
> output stuff, and have functions.sh source this. Output.sh would be
> provided by a separate package (why not baselayout) and the packages
> using those would rewrite their stuff to use the right location.

we're not splitting the source trees.  the reasons have already been
detailed in the bug open on the topic.
-mike

Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?

[Paul de Vrieze]

On 30 June 2011 04:47, Mike Frysinger  wrote:
>
> 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

Why can't we just split up functions.sh into "/lib/output.sh"
containing the init script independent (but often gentoo specific)
output stuff, and have functions.sh source this. Output.sh would be
provided by a separate package (why not baselayout) and the packages
using those would rewrite their stuff to use the right location.

Paul

--
Paul de Vrieze
Researcher
Mail: paul.devri...@gmail.com
Homepage: http://www.devrieze.net