FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 08-15-2012, 11:32 AM
Rich Freeman
 
Default Questions about SystemD and OpenRC

On Wed, Aug 15, 2012 at 7:07 AM, Fabian Groffen <grobian@gentoo.org> wrote:
> On 15-08-2012 12:58:32 +0200, Michał Górny wrote:
>> Rich Freeman <rich0@gentoo.org> wrote:
>> > 2. Things like Prefix rely on the system not installing local copies
>> > of libraries in the core system it needs to link to. Careful use of
>> > package.provided in profiles might address this.
>
> Huh? Not sure I understand this, but it suggests something which isn't
> true for Prefix to me.

Do you want every other package in the tree depending on glibc, and
therefore trying to pull it in on a prefix system? (For those
unaware, prefix depends on a non-Gentoo glibc for the system call
interface.) There are probably a few ways you could do it, but if you
got rid of the implicit @system dependency then you'd need to handle
situations where @system is something non-traditional and ebuilds are
likely to do it wrong.

Agree with mgorny's suggestion that anything required by PMS could be
pulled in by the package manager, perhaps in an EAPI-dependent
fashion.

Oh, @system has another use I didn't mention - getting rid of some
chicken-and-egg issues during the initial install. That can be
addressed by providing pre-built stage1/2/3s, having package sets and
scripts for their building, and so on. Maybe make world a world.d
directory with Gentoo providing a starter file and users modifying
their own addition, but being free to remove items and depcleaning
them. Or provide a syntax for world to remove packages pulled in by a
distro-provided world, etc. Many elements of this would benefit from
public comment obviously should we choose to go along this road.

Rich
 
Old 08-15-2012, 11:41 AM
Fabian Groffen
 
Default Questions about SystemD and OpenRC

On 15-08-2012 07:32:45 -0400, Rich Freeman wrote:
> On Wed, Aug 15, 2012 at 7:07 AM, Fabian Groffen <grobian@gentoo.org> wrote:
> > On 15-08-2012 12:58:32 +0200, Michał Górny wrote:
> >> Rich Freeman <rich0@gentoo.org> wrote:
> >> > 2. Things like Prefix rely on the system not installing local copies
> >> > of libraries in the core system it needs to link to. Careful use of
> >> > package.provided in profiles might address this.
> >
> > Huh? Not sure I understand this, but it suggests something which isn't
> > true for Prefix to me.
>
> Do you want every other package in the tree depending on glibc, and
> therefore trying to pull it in on a prefix system? (For those
> unaware, prefix depends on a non-Gentoo glibc for the system call
> interface.)

Correction: Prefix uses a possibly non-Gentoo, host-provided libc, not
necessarily GNU libc of an unknown version.

There are only a few packages I've seen that depend on a certain
(min/max) version of glibc, and when in use for Prefix, mostly use
"!prefix? ( elibc_glibc? ( ...) )"
stuff at the moment.


--
Fabian Groffen
Gentoo on a different level
 
Old 08-15-2012, 11:50 AM
Rich Freeman
 
Default Questions about SystemD and OpenRC

On Wed, Aug 15, 2012 at 7:41 AM, Fabian Groffen <grobian@gentoo.org> wrote:
> There are only a few packages I've seen that depend on a certain
> (min/max) version of glibc, and when in use for Prefix, mostly use
> "!prefix? ( elibc_glibc? ( ...) )"
> stuff at the moment.

Half the packages in portage link to libc, though they don't actually
declare this dependency due to the policy of not declaring policies in
@system. If you got rid of @system then they'd need to declare them.

However, use of virtuals or package.provided would address this issue
- I was just pointing it out.

Rich
 
Old 08-15-2012, 12:01 PM
Fabian Groffen
 
Default Questions about SystemD and OpenRC

On 15-08-2012 07:50:42 -0400, Rich Freeman wrote:
> On Wed, Aug 15, 2012 at 7:41 AM, Fabian Groffen <grobian@gentoo.org> wrote:
> > There are only a few packages I've seen that depend on a certain
> > (min/max) version of glibc, and when in use for Prefix, mostly use
> > "!prefix? ( elibc_glibc? ( ...) )"
> > stuff at the moment.
>
> Half the packages in portage link to libc, though they don't actually
> declare this dependency due to the policy of not declaring policies in
> @system. If you got rid of @system then they'd need to declare them.

Yeah, so just don't do that.


--
Fabian Groffen
Gentoo on a different level
 
Old 08-15-2012, 12:18 PM
William Hubbs
 
Default Questions about SystemD and OpenRC

On Wed, Aug 15, 2012 at 06:27:41AM -0400, Rich Freeman wrote:
> RE you concerns about OpenRC being in @system. Personally I'm a fan
> of getting rid of @system entirely except as something used to build
> install CDs or having some sets for convenience in building systems.
> It only exists for a few reasons that I can think of:
> 1. Devs don't want to have ebuilds that capture dependencies on every
> little thing. A few well-chosen virtuals like "shell utilities" or
> whatever might help with this.
> 2. Things like Prefix rely on the system not installing local copies
> of libraries in the core system it needs to link to. Careful use of
> package.provided in profiles might address this.
> 3. We'd need many more virtuals to handle situations like FreeBSD
> where people don't what GNU on their systems. Right now if they are
> system packages they just define system appropriately and ebuilds
> don't directly pull in the GNU stuff anyway.
>
> I'm sure there could be others. Keep in mind that systemd is still
> pretty new and largely out-of-the-blue so it will take time for Gentoo
> to adjust to it. Right now OpenRC might install executables, but
> nothing should be actually running them - this is just wasted
> compilation time which isn't a bad interim state to be in. If
> virtualizing udev is causing controversy just wait until somebody
> actually makes a push to remove OpenRC from @system...

This isn't in the plans. OpenRC gets installed everywhere right now,
because it is a pdepend of baselayout. The plan is actually to tie it to
a virtual which will be added to @system; I just haven't gotten around
to doing this yet. [1]

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=409385
 
Old 08-15-2012, 01:43 PM
Rich Freeman
 
Default Questions about SystemD and OpenRC

On Wed, Aug 15, 2012 at 8:01 AM, Fabian Groffen <grobian@gentoo.org> wrote:
> On 15-08-2012 07:50:42 -0400, Rich Freeman wrote:
>> On Wed, Aug 15, 2012 at 7:41 AM, Fabian Groffen <grobian@gentoo.org> wrote:
>> > There are only a few packages I've seen that depend on a certain
>> > (min/max) version of glibc, and when in use for Prefix, mostly use
>> > "!prefix? ( elibc_glibc? ( ...) )"
>> > stuff at the moment.
>>
>> Half the packages in portage link to libc, though they don't actually
>> declare this dependency due to the policy of not declaring policies in
>> @system. If you got rid of @system then they'd need to declare them.
>
> Yeah, so just don't do that.

In that case then just ignore that whole section of my post.
Personally I consider the existence of @system a bit of a hack - like
the big kernel lock. It works OK, but here and there we run into
issues with it.

Williamh pointed out that the plan for now is to virtualize
openrc/systemd, which certainly is a solution to that problem. Being
an evolutionary vs revolutionary solution it is probably the better
next step. In fact, if you kept making many steps like that one
before long @system would become mostly a big collection of virtuals
anyway, and at that point its only reason for being would be as an
arbitrary list of packages that ebuild maintainers shouldn't add as
dependencies, at which point you could start stripping it away.

That isn't unlike what was done to get rid of the big kernel lock -
just remove it one instance at a time...

Rich
 
Old 08-15-2012, 06:21 PM
Duncan
 
Default Questions about SystemD and OpenRC

Rich Freeman posted on Wed, 15 Aug 2012 06:27:41 -0400 as excerpted:

> Right now having decent KDE and Gnome support with all the bells and
> whistles[...] isn't that hard, [It] will likely get harder, which means
> in practice what we'll probably have is a reasonable compromise which
> will never be quite as polished in any one direction as it could be,
> unless the end user does the polishing.

Well stated.

> RE you concerns about OpenRC being in @system. Personally I'm a fan of
> getting rid of @system entirely except as something used to build
> install CDs or having some sets for convenience in building systems. It
> only exists for a few reasons that I can think of:
> 1. Devs don't want to have ebuilds that capture dependencies on every
> little thing. A few well-chosen virtuals like "shell utilities" or
> whatever might help with this.
> 2. Things like Prefix rely on the system not installing local copies of
> libraries in the core system it needs to link to. Careful use of
> package.provided in profiles might address this.
> 3. We'd need many more virtuals to handle situations like FreeBSD where
> people don't what GNU on their systems. Right now if they are system
> packages they just define system appropriately and ebuilds don't
> directly pull in the GNU stuff anyway.

AFAIK, @system also helps resolve a few nasty circular dependencies. In
fact, I believe that's it's primary purpose. As such I'm not sure it's
practical (as opposed to possible, cost/benefit simply makes it
impractical) to entirely get rid of, but it does occur to me that sets
would be an interesting way to go. Define a few sets that together
compose @system as we have it today, and basically package.provide them
during the bootstrap phase.

AFAIK the original stage tarball also contains a minimal installed tree,
for similar reasons. I'm not actually sure how they interact. That'd be
releng/arch/catalyst territory.

--
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
 
Old 08-15-2012, 07:18 PM
Michael Mol
 
Default Questions about SystemD and OpenRC

On Wed, Aug 15, 2012 at 2:21 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>
> Rich Freeman posted on Wed, 15 Aug 2012 06:27:41 -0400 as excerpted:
>
> > Right now having decent KDE and Gnome support with all the bells and
> > whistles[...] isn't that hard, [It] will likely get harder, which means
> > in practice what we'll probably have is a reasonable compromise which
> > will never be quite as polished in any one direction as it could be,
> > unless the end user does the polishing.
>
> Well stated.
>
> > RE you concerns about OpenRC being in @system. Personally I'm a fan of
> > getting rid of @system entirely except as something used to build
> > install CDs or having some sets for convenience in building systems. It
> > only exists for a few reasons that I can think of:
> > 1. Devs don't want to have ebuilds that capture dependencies on every
> > little thing. A few well-chosen virtuals like "shell utilities" or
> > whatever might help with this.
> > 2. Things like Prefix rely on the system not installing local copies of
> > libraries in the core system it needs to link to. Careful use of
> > package.provided in profiles might address this.
> > 3. We'd need many more virtuals to handle situations like FreeBSD where
> > people don't what GNU on their systems. Right now if they are system
> > packages they just define system appropriately and ebuilds don't
> > directly pull in the GNU stuff anyway.
>
> AFAIK, @system also helps resolve a few nasty circular dependencies. In
> fact, I believe that's it's primary purpose. As such I'm not sure it's
> practical (as opposed to possible, cost/benefit simply makes it
> impractical) to entirely get rid of, but it does occur to me that sets
> would be an interesting way to go. Define a few sets that together
> compose @system as we have it today, and basically package.provide them
> during the bootstrap phase.
>
> AFAIK the original stage tarball also contains a minimal installed tree,
> for similar reasons. I'm not actually sure how they interact. That'd be
> releng/arch/catalyst territory.

Just piping up here, as this relates to an idea that's been
percolating through my mind for a couple weeks.

I've occasionally noticed portage tell me about circular dependencies,
where the most straight forward resolution is to emerge some package
in the loop twice. The first time, with a USE flag disabled (avahi and
gtk are the usual suspects), and the second time with the USE flag
enabled.

In circumstances where it's necessary to do something like that to
reach a final desired system state, I'm not sure I see any problem
with portage automatically doing the two-stage emerge.

It also sounds like something like that could be a benefit to shrinking @system.

As far as things such as libc, where many, many packages require their
use, I don't personally see a problem with recommending that ebuilds
depend on them. My only other notable experience for Linux
distributions is Debian/Ubuntu, and a quick glance shows 16,389
packages expressing explicit dependencies on libc6 in Ubuntu 12.04.

--
:wq
 
Old 08-15-2012, 07:26 PM
Ciaran McCreesh
 
Default Questions about SystemD and OpenRC

On Wed, 15 Aug 2012 15:18:24 -0400
Michael Mol <mikemol@gmail.com> wrote:
> I've occasionally noticed portage tell me about circular dependencies,
> where the most straight forward resolution is to emerge some package
> in the loop twice. The first time, with a USE flag disabled (avahi and
> gtk are the usual suspects), and the second time with the USE flag
> enabled.
>
> In circumstances where it's necessary to do something like that to
> reach a final desired system state, I'm not sure I see any problem
> with portage automatically doing the two-stage emerge.

That's going to be rather horrible when your package mangler
"temporarily" turns off acl or turns on build...

--
Ciaran McCreesh
 
Old 08-15-2012, 07:50 PM
Michael Mol
 
Default Questions about SystemD and OpenRC

On Wed, Aug 15, 2012 at 3:26 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Wed, 15 Aug 2012 15:18:24 -0400
> Michael Mol <mikemol@gmail.com> wrote:
>> I've occasionally noticed portage tell me about circular dependencies,
>> where the most straight forward resolution is to emerge some package
>> in the loop twice. The first time, with a USE flag disabled (avahi and
>> gtk are the usual suspects), and the second time with the USE flag
>> enabled.
>>
>> In circumstances where it's necessary to do something like that to
>> reach a final desired system state, I'm not sure I see any problem
>> with portage automatically doing the two-stage emerge.
>
> That's going to be rather horrible when your package mangler
> "temporarily" turns off acl or turns on build...

Fair observation; there would need to be a way either weight benign or
dangerous USE/package flags, and search paths with weights outside of
a 'safe' range would be discarded.

A mechanism like that also offers a means of finding and favoring
cheap rebuilds over expensive ones; rebuilding gcc an extra time ought
to be disfavored over rebuilding, say, sudo.

--
:wq
 

Thread Tools




All times are GMT. The time now is 10:36 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org