[gentoo-user] baselayout2/openrc question

[gentoo-user] baselayout2/openrc question

[David Relson]

G'day,

I've been running baselayout-2 for several months and it's been working
fine AFAICT.  Over the weekend I noticed that my USB thumb drive is no
longer automounting.  

This evening I ran "/etc/init.d/udev status" which reported:

 * status: stopped".  

Running "/etc/init.d/udev start" reported:

 * The udev init-script is written for baselayout-2!
 * Please do not use it with baselayout-1!.
 * ERROR: udev failed to start

The message occurs because /etc/init.d/udev checks for
/etc/init.d/sysfs, which is not present.  

Googling indicates that /etc/init.d/sysf comes from sys-apps/openrc.  I
have openrc-0.3.0-r1 installed (from long ago).  openrc-0.6.0-r1 is
available, though keyworded ~amd64.  Unmasking it and running "emerge
-p ..." shows that sysvinit is a blocker.

Is it safe to delete sysvinit and emerge openrc-0.6.0-r1?  Am I likely
to get myself into troubleif I do this?  If so, how much and how deep?

Regards,

David

Re: [gentoo-user] baselayout2/openrc question

[Alan McKinnon]

On Tuesday 02 February 2010 06:03:10 David Relson wrote:
> G'day,
> 
> I've been running baselayout-2 for several months and it's been working
> fine AFAICT.  Over the weekend I noticed that my USB thumb drive is no
> longer automounting.
> 
> This evening I ran "/etc/init.d/udev status" which reported:
> 
>  * status: stopped".
> 
> Running "/etc/init.d/udev start" reported:
> 
>  * The udev init-script is written for baselayout-2!
>  * Please do not use it with baselayout-1!.
>  * ERROR: udev failed to start
> 
> The message occurs because /etc/init.d/udev checks for
> /etc/init.d/sysfs, which is not present.
> 
> Googling indicates that /etc/init.d/sysf comes from sys-apps/openrc.  I
> have openrc-0.3.0-r1 installed (from long ago).  openrc-0.6.0-r1 is
> available, though keyworded ~amd64.  Unmasking it and running "emerge
> -p ..." shows that sysvinit is a blocker.
> 
> Is it safe to delete sysvinit and emerge openrc-0.6.0-r1?  Am I likely
> to get myself into troubleif I do this?  If so, how much and how deep?

very very very very deep trouble if you restart the machine and everything is 
not complete yet. Do not do that.

all version of baselayout-2 are marked unstable and you likely have an old 
version of sysvinit that is not compatible with the ancient openrc you do 
have. That openrc is not in portage anymore.

You should upgrade to the latest unstable portage (which supports 
automatically resolving blockers). You need baselayout, openrc and sysvinit as 
well as /etc/init.d/sysfs. I have none of these in world yet all are present.

With the latest portage, try again and let portage figure out for itself what 
it wants to do.


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] baselayout2/openrc question

[David Relson]

On Tue, 2 Feb 2010 08:08:25 +0200
Alan McKinnon wrote:

> On Tuesday 02 February 2010 06:03:10 David Relson wrote:
> > G'day,
> > 
> > I've been running baselayout-2 for several months and it's been
> > working fine AFAICT.  Over the weekend I noticed that my USB thumb
> > drive is no longer automounting.
> > 
> > This evening I ran "/etc/init.d/udev status" which reported:
> > 
> >  * status: stopped".
> > 
> > Running "/etc/init.d/udev start" reported:
> > 
> >  * The udev init-script is written for baselayout-2!
> >  * Please do not use it with baselayout-1!.
> >  * ERROR: udev failed to start
> > 
> > The message occurs because /etc/init.d/udev checks for
> > /etc/init.d/sysfs, which is not present.
> > 
> > Googling indicates that /etc/init.d/sysf comes from
> > sys-apps/openrc.  I have openrc-0.3.0-r1 installed (from long
> > ago).  openrc-0.6.0-r1 is available, though keyworded ~amd64.
> > Unmasking it and running "emerge -p ..." shows that sysvinit is a
> > blocker.
> > 
> > Is it safe to delete sysvinit and emerge openrc-0.6.0-r1?  Am I
> > likely to get myself into troubleif I do this?  If so, how much and
> > how deep?
> 
> very very very very deep trouble if you restart the machine and
> everything is not complete yet. Do not do that.
> 
> all version of baselayout-2 are marked unstable and you likely have
> an old version of sysvinit that is not compatible with the ancient
> openrc you do have. That openrc is not in portage anymore.
> 
> You should upgrade to the latest unstable portage (which supports 
> automatically resolving blockers). You need baselayout, openrc and
> sysvinit as well as /etc/init.d/sysfs. I have none of these in world
> yet all are present.
> 
> With the latest portage, try again and let portage figure out for
> itself what it wants to do.

Hi Alan,

Reply appreciated!

I've been running unstable versions of portage for many months and
currently have 2.1.7.17, which _is_ the newest non-masked version.

With it, sysvinit is blocking (capital "B") openrc-0.6.0-r1
and /etc/init.d/sysfs is not present (which makes /etc/init.d/udev
unhappy).

Since /etc/init.d/udev only _checks_ for the presence of 
/etc/init.d/sysfs but doesn't run it (or anything), would creating a
dummy (zero length) sysfs file be workable?

Regards,

David

Re: [gentoo-user] baselayout2/openrc question

[Peter Humphrey]

On Tuesday 02 February 2010 12:47:46 David Relson wrote:

> I've been running unstable versions of portage for many months and
> currently have 2.1.7.17, which _is_ the newest non-masked version.

Nevertheless, it isn't the latest version. To get that you need an entry in 
package.unmask; then portage will be able to sort out far more complex 
problems than the unmasked version can. Don't worry - many people here have 
been doing this for many months, with no problems attributable to portage. 

-- 
Rgds
Peter.

Re: [gentoo-user] baselayout2/openrc question

[Tom Hendrikx]

Peter Humphrey wrote:
> On Tuesday 02 February 2010 12:47:46 David Relson wrote:
> 
>> I've been running unstable versions of portage for many months and
>> currently have 2.1.7.17, which _is_ the newest non-masked version.
> 
> Nevertheless, it isn't the latest version. To get that you need an entry in 
> package.unmask; then portage will be able to sort out far more complex 
> problems than the unmasked version can. Don't worry - many people here have 
> been doing this for many months, with no problems attributable to portage. 
> 

I'm not sure if upgrading portage to a masked version is a sane solution
 for the OP's issue (i.e. resolving a single dependency issue).
Reading the error output from portage (and sometimes the ebuild) to
solve the blocker (as people do who run a stable portage) would suffice,
imho.

As for the issue with openrc:

=sys-apps/openrc-0.6.0-r1 depends on =sys-apps/sysvinit-2.87-r3, and
both are in ~arch. Unmask both, emerge them, run etc-update and be fine.

--
Regards,
	Tom

Re: [gentoo-user] baselayout2/openrc question

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

On Mon, Feb 01, 2010 at 11:03:10PM -0500, David Relson wrote:
> Is it safe to delete sysvinit and emerge openrc-0.6.0-r1?  Am I likely
> to get myself into troubleif I do this?  If so, how much and how deep?

The latest version of sysvinit, 2.87-r3, is the one you should be
running with openrc.

This version is scheduled to go stable around 2/8, so to get it onto
your system early, do this:

echo =sys-apps/sysvinit-2.87-r3 >> /etc/portage/package.keywords

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] baselayout2/openrc question

[Alan McKinnon]

On Tuesday 02 February 2010 14:47:46 David Relson wrote:
> On Tue, 2 Feb 2010 08:08:25 +0200
> 
> Alan McKinnon wrote:
> > On Tuesday 02 February 2010 06:03:10 David Relson wrote:
> > > G'day,
> > >
> > > I've been running baselayout-2 for several months and it's been
> > > working fine AFAICT.  Over the weekend I noticed that my USB thumb
> > > drive is no longer automounting.
> > >
> > > This evening I ran "/etc/init.d/udev status" which reported:
> > >
> > >  * status: stopped".
> > >
> > > Running "/etc/init.d/udev start" reported:
> > >
> > >  * The udev init-script is written for baselayout-2!
> > >  * Please do not use it with baselayout-1!.
> > >  * ERROR: udev failed to start
> > >
> > > The message occurs because /etc/init.d/udev checks for
> > > /etc/init.d/sysfs, which is not present.
> > >
> > > Googling indicates that /etc/init.d/sysf comes from
> > > sys-apps/openrc.  I have openrc-0.3.0-r1 installed (from long
> > > ago).  openrc-0.6.0-r1 is available, though keyworded ~amd64.
> > > Unmasking it and running "emerge -p ..." shows that sysvinit is a
> > > blocker.
> > >
> > > Is it safe to delete sysvinit and emerge openrc-0.6.0-r1?  Am I
> > > likely to get myself into troubleif I do this?  If so, how much and
> > > how deep?
> >
> > very very very very deep trouble if you restart the machine and
> > everything is not complete yet. Do not do that.
> >
> > all version of baselayout-2 are marked unstable and you likely have
> > an old version of sysvinit that is not compatible with the ancient
> > openrc you do have. That openrc is not in portage anymore.
> >
> > You should upgrade to the latest unstable portage (which supports
> > automatically resolving blockers). You need baselayout, openrc and
> > sysvinit as well as /etc/init.d/sysfs. I have none of these in world
> > yet all are present.
> >
> > With the latest portage, try again and let portage figure out for
> > itself what it wants to do.
> 
> Hi Alan,
> 
> Reply appreciated!
> 
> I've been running unstable versions of portage for many months and
> currently have 2.1.7.17, which _is_ the newest non-masked version.

No, you completely misunderstand what stable, unstable and masked mean.

You are using stable (and call it unstable which is wrong). What you call 
masked is actually called unstable. Masked is something else entirely.

Do not confuse these terms. They have *exact* meaning.

You need to keyword portage as ~ in packages.keywords to release portage-2.2, 
which is the version that supports automagic blocker resolution.
 
> With it, sysvinit is blocking (capital "B") openrc-0.6.0-r1
> and /etc/init.d/sysfs is not present (which makes /etc/init.d/udev
> unhappy).

Thsi is correct. You have temporary blockers and the version of portage I said 
you should use just magically knows what to do. It knows this better than you 
do.

> Since /etc/init.d/udev only _checks_ for the presence of
> /etc/init.d/sysfs but doesn't run it (or anything), would creating a
> dummy (zero length) sysfs file be workable?

Latest unstable openrc will likely fix this.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] baselayout2/openrc question

[Alan McKinnon]

On Tuesday 02 February 2010 17:34:42 Tom Hendrikx wrote:
> Peter Humphrey wrote:
> > On Tuesday 02 February 2010 12:47:46 David Relson wrote:
> >> I've been running unstable versions of portage for many months and
> >> currently have 2.1.7.17, which _is_ the newest non-masked version.
> >
> > Nevertheless, it isn't the latest version. To get that you need an entry
> > in package.unmask; then portage will be able to sort out far more complex
> > problems than the unmasked version can. Don't worry - many people here
> > have been doing this for many months, with no problems attributable to
> > portage.
> 
> I'm not sure if upgrading portage to a masked version is a sane solution
>  for the OP's issue (i.e. resolving a single dependency issue).
> Reading the error output from portage (and sometimes the ebuild) to
> solve the blocker (as people do who run a stable portage) would suffice,
> imho.

The list of benefits from using latest unstable portage is very long.

The list of persons running stable systems who have reported problems here 
with latest unstable portage is very short, tending to zero in fact.

Whereas willy-nilly mixing stable and unstable is normally condemned as a bad 
idea (with good reason), it generally considered OK with portage for the above 
reason. Portage is self-contained, unmasking it doesn't contaminate the system 
with legions of other unstable $STUFF
 
> As for the issue with openrc:
> 
> =sys-apps/openrc-0.6.0-r1 depends on =sys-apps/sysvinit-2.87-r3, and
> both are in ~arch. Unmask both, emerge them, run etc-update and be fine.

Portage's blocker list has historically been confusing and difficult for users 
to parse. They often don't know what to do - how many posts like that have you 
answered where the answer is simply "unmerge this, merge that, merge world"?

It makes sense to me, probably to you too, and not much sense to a large chunk 
of gentoo userland. Latest portage fixes all that and makes it a non-issue.


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] baselayout2/openrc question

[Philip Webb]

100202 Alan McKinnon wrote:
> The list of benefits from using latest unstable portage is very long.
> Portage is self-contained, unmasking it doesn't contaminate the system 
> with legions of other unstable $STUFF

So why has it continued to be marked 'unstable' for so long ?
My long-standing policy ( > 6 yr ) has been to stick to 'stable'
for all system pkgs, but use 'unstable' for well-supported apps (eg KDE):
I haven't run into a serious problem in all that time.

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] baselayout2/openrc question

[Mike Edenfield]

On 2/2/2010 3:48 PM, Alan McKinnon wrote:

> No, you completely misunderstand what stable, unstable and masked mean.
>
> You are using stable (and call it unstable which is wrong). What you call
> masked is actually called unstable. Masked is something else entirely.
>
> Do not confuse these terms. They have *exact* meaning.

Has there ever been any discussion on coming up with more precise 
wording for portage's error messages?  I suspect a lot of confusion 
between masked/keyworded comes from the fact that portage calls them all 
"Masked", e.g.:

!!! All ebuilds that could satisfy "=app-editors/vim-7.2.303" have been 
masked.
!!! One of the following masked packages is required to complete your 
request:
- app-editors/vim-7.2.303 (masked by: ~amd64 keyword)

Not that I came up with any better wording off the top of my head, but 
is the portage team open to suggestions?  Or has this issue been beaten 
to death already?

--K

Re: [gentoo-user] baselayout2/openrc question

[Alan McKinnon]

On Tuesday 02 February 2010 23:37:33 Philip Webb wrote:
> 100202 Alan McKinnon wrote:
> > The list of benefits from using latest unstable portage is very long.
> > Portage is self-contained, unmasking it doesn't contaminate the system
> > with legions of other unstable $STUFF
> 
> So why has it continued to be marked 'unstable' for so long ?

I have no idea. You should ask Zac.

There's an entry in packages.mask about wanting user test feedback, that 
doesn't say much. It especially says nothing about the quality of the stable 
vs unstable code bases

> My long-standing policy ( > 6 yr ) has been to stick to 'stable'
> for all system pkgs, but use 'unstable' for well-supported apps (eg KDE):
> I haven't run into a serious problem in all that time.

I can't think of an app that is better supported in Gentoo than portage. 

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] baselayout2/openrc question

[Alan McKinnon]

On Tuesday 02 February 2010 23:40:17 Mike Edenfield wrote:
> On 2/2/2010 3:48 PM, Alan McKinnon wrote:
> > No, you completely misunderstand what stable, unstable and masked mean.
> >
> > You are using stable (and call it unstable which is wrong). What you call
> > masked is actually called unstable. Masked is something else entirely.
> >
> > Do not confuse these terms. They have *exact* meaning.
> 
> Has there ever been any discussion on coming up with more precise
> wording for portage's error messages?  I suspect a lot of confusion
> between masked/keyworded comes from the fact that portage calls them all
> "Masked", e.g.:
> 
> !!! All ebuilds that could satisfy "=app-editors/vim-7.2.303" have been
> masked.
> !!! One of the following masked packages is required to complete your
> request:
> - app-editors/vim-7.2.303 (masked by: ~amd64 keyword)
> 
> Not that I came up with any better wording off the top of my head, but
> is the portage team open to suggestions?  Or has this issue been beaten
> to death already?


"mask" is a computer term. It means something that defines an exclusion list. 
All packages in gentoo have masks, even if they are null. "Stable" can be 
considered to be a mask, it just happens to be empty so is always available on 
a system where the arch matches.

When the devs talk about "hard masking" they mean something with an entry in 
packages.mask. Other terms are completely understood: arch, ~arch, etc.

When users miscomprehend the terminology, it's not a failure in the 
terminology it's a failure by the user. Human languages are like that. No 
matter how well you try and nail down a definition for all time, users of the 
language will always try to change stuff.

The current terms work well. Changing them is unlikely to be well received  as 
they are so deeply entrenched already.
-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] baselayout2/openrc question

[Dale]

Alan McKinnon wrote:
> On Tuesday 02 February 2010 17:34:42 Tom Hendrikx wrote:
>   
>> As for the issue with openrc:
>>
>> =sys-apps/openrc-0.6.0-r1 depends on =sys-apps/sysvinit-2.87-r3, and
>> both are in ~arch. Unmask both, emerge them, run etc-update and be fine.
>>     
>
> Portage's blocker list has historically been confusing and difficult for users 
> to parse. They often don't know what to do - how many posts like that have you 
> answered where the answer is simply "unmerge this, merge that, merge world"?
>
> It makes sense to me, probably to you too, and not much sense to a large chunk 
> of gentoo userland. Latest portage fixes all that and makes it a non-issue.
>
>   

Those messages stump me too.  I'm sort of getting to where they make 
sense but you have to think backward so that they do make sense.  You 
sort of have to start at the bottom of the list and work your way up. 

I'm sure glad the latest portage takes care of most of that.  I'm using 
Portage 2.2_rc62 and I have not had any problems with it. 

Dale

:-)  :-) 

Re: [gentoo-user] baselayout2/openrc question

[Dale]

Alan McKinnon wrote:
> On Tuesday 02 February 2010 23:37:33 Philip Webb wrote:
>   
>> 100202 Alan McKinnon wrote:
>>     
>>> The list of benefits from using latest unstable portage is very long.
>>> Portage is self-contained, unmasking it doesn't contaminate the system
>>> with legions of other unstable $STUFF
>>>       
>> So why has it continued to be marked 'unstable' for so long ?
>>     
>
> I have no idea. You should ask Zac.
>
> There's an entry in packages.mask about wanting user test feedback, that 
> doesn't say much. It especially says nothing about the quality of the stable 
> vs unstable code bases
>
>   

I read on -dev that they want the older version tested more.  I'm not 
sure why since it seems most people have just unmasked the newer version 
and moved on.  It's not like the older version is better or anything.  ;-)

In my opinion, the old portage was good, the new one is even better.  
Now if the next version will prevent a person from borking their system, 
that would be heaven.  lol  You know, unmerge python and see what 
happens.  Yes, you can still unmerge python, even the only version you 
have left, and portage not say a darn thing.  It kills the heck out of 
portage tho. 

Dale

:-)  :-)

Re: [gentoo-user] baselayout2/openrc question

[Daniel Barkalow]

On Tue, 2 Feb 2010, Alan McKinnon wrote:

> On Tuesday 02 February 2010 14:47:46 David Relson wrote:
> > On Tue, 2 Feb 2010 08:08:25 +0200
> > 
> > Alan McKinnon wrote:
> > > On Tuesday 02 February 2010 06:03:10 David Relson wrote:
> > > > G'day,
> > > >
> > > > I've been running baselayout-2 for several months and it's been
> > > > working fine AFAICT.  Over the weekend I noticed that my USB thumb
> > > > drive is no longer automounting.
> > > >
> > > > This evening I ran "/etc/init.d/udev status" which reported:
> > > >
> > > >  * status: stopped".
> > > >
> > > > Running "/etc/init.d/udev start" reported:
> > > >
> > > >  * The udev init-script is written for baselayout-2!
> > > >  * Please do not use it with baselayout-1!.
> > > >  * ERROR: udev failed to start
> > > >
> > > > The message occurs because /etc/init.d/udev checks for
> > > > /etc/init.d/sysfs, which is not present.
> > > >
> > > > Googling indicates that /etc/init.d/sysf comes from
> > > > sys-apps/openrc.  I have openrc-0.3.0-r1 installed (from long
> > > > ago).  openrc-0.6.0-r1 is available, though keyworded ~amd64.
> > > > Unmasking it and running "emerge -p ..." shows that sysvinit is a
> > > > blocker.
> > > >
> > > > Is it safe to delete sysvinit and emerge openrc-0.6.0-r1?  Am I
> > > > likely to get myself into troubleif I do this?  If so, how much and
> > > > how deep?
> > >
> > > very very very very deep trouble if you restart the machine and
> > > everything is not complete yet. Do not do that.
> > >
> > > all version of baselayout-2 are marked unstable and you likely have
> > > an old version of sysvinit that is not compatible with the ancient
> > > openrc you do have. That openrc is not in portage anymore.
> > >
> > > You should upgrade to the latest unstable portage (which supports
> > > automatically resolving blockers). You need baselayout, openrc and
> > > sysvinit as well as /etc/init.d/sysfs. I have none of these in world
> > > yet all are present.
> > >
> > > With the latest portage, try again and let portage figure out for
> > > itself what it wants to do.
> > 
> > Hi Alan,
> > 
> > Reply appreciated!
> > 
> > I've been running unstable versions of portage for many months and
> > currently have 2.1.7.17, which _is_ the newest non-masked version.
> 
> No, you completely misunderstand what stable, unstable and masked mean.
> 
> You are using stable (and call it unstable which is wrong). What you call 
> masked is actually called unstable. Masked is something else entirely.
> 
> Do not confuse these terms. They have *exact* meaning.
> 
> You need to keyword portage as ~ in packages.keywords to release portage-2.2, 
> which is the version that supports automagic blocker resolution.

portage-2.2 *is* masked:

/usr/portage/profiles/package.mask:
# Zac Medico <zmedico@gentoo.org> (05 Jan 2009)
# Portage 2.2 is masked due to known bugs in the
# package sets and preserve-libs features.

portage-2.1.7.17 is all you can get with package.keywords (and 2.1.7.16 
without, at least on x86).

	-Daniel
*This .sig left intentionally blank*

Re: [gentoo-user] baselayout2/openrc question

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

On Tue, 02 Feb 2010 18:09:08 -0600, Dale wrote:

> In my opinion, the old portage was good, the new one is even better.  
> Now if the next version will prevent a person from borking their
> system, that would be heaven.  lol  You know, unmerge python and see
> what happens.  Yes, you can still unmerge python, even the only version
> you have left, and portage not say a darn thing.  It kills the heck out
> of portage tho. 

Portage gives you a big red warning if you try to do this, but it
doesn't, and shouldn't, try to stop you. What if you really want to
remove Python? Postage is not the only package manager, so python is not
compulsory.


-- 
Neil Bothwick

"Time is the best teacher....., unfortunately it kills all the students"

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] baselayout2/openrc question

[Peter Humphrey]

On Tuesday 02 February 2010 20:53:39 Alan McKinnon wrote:

> Whereas willy-nilly mixing stable and unstable is normally condemned as a
>  bad idea (with good reason), it generally considered OK with portage for
>  the above reason. Portage is self-contained, unmasking it doesn't
>  contaminate the system with legions of other unstable $STUFF

...with the one exception* of a couple of eselect packages, which hardly 
counts anyway.

* Is "a couple" one or two? You decide.

-- 
Rgds
Peter.

Re: [gentoo-user] baselayout2/openrc question

[Dale]

Neil Bothwick wrote:
> On Tue, 02 Feb 2010 18:09:08 -0600, Dale wrote:
>
>   
>> In my opinion, the old portage was good, the new one is even better.  
>> Now if the next version will prevent a person from borking their
>> system, that would be heaven.  lol  You know, unmerge python and see
>> what happens.  Yes, you can still unmerge python, even the only version
>> you have left, and portage not say a darn thing.  It kills the heck out
>> of portage tho. 
>>     
>
> Portage gives you a big red warning if you try to do this, but it
> doesn't, and shouldn't, try to stop you. What if you really want to
> remove Python? Postage is not the only package manager, so python is not
> compulsory.
>
>   

It doesn't here.  Someone else did the same thing a few weeks ago with 
no warning or didn't mention seeing one at least.  I've read where 
others have done this too.

It just seems to me that portage should keep it so it can work.  It 
needs python to do that.  Since portage is the package manager for 
Gentoo, portage is the one that should be protected. 

Dale

:-)  :-) 

Re: [gentoo-user] baselayout2/openrc question

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

On Wed, 03 Feb 2010 12:07:33 -0600, Dale wrote:

> > Portage gives you a big red warning if you try to do this, but it
> > doesn't, and shouldn't, try to stop you. What if you really want to
> > remove Python? Postage is not the only package manager, so python is
> > not compulsory.


> It doesn't here.  Someone else did the same thing a few weeks ago with 
> no warning or didn't mention seeing one at least.  I've read where 
> others have done this too.
have changed.
You're right. It used to do this if you tried to remove anything from
@system, but this appears to 

> It just seems to me that portage should keep it so it can work.  It 
> needs python to do that.  Since portage is the package manager for 
> Gentoo, portage is the one that should be protected. 

Portage is A package manager, but if you are using portage to remove
packages, it should be intelligent about removing its own dependencies.

Taken more globally, maybe portage should warn whenever you are trying to
remove a package that is a dependency of anything in @world.


-- 
Neil Bothwick

Computers are like Old Testament gods; lots of rules and no mercy.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] baselayout2/openrc question

[Alan McKinnon]

On Wednesday 03 February 2010 20:07:33 Dale wrote:
> Neil Bothwick wrote:
> > On Tue, 02 Feb 2010 18:09:08 -0600, Dale wrote:
> >> In my opinion, the old portage was good, the new one is even better.
> >> Now if the next version will prevent a person from borking their
> >> system, that would be heaven.  lol  You know, unmerge python and see
> >> what happens.  Yes, you can still unmerge python, even the only version
> >> you have left, and portage not say a darn thing.  It kills the heck out
> >> of portage tho.
> >
> > Portage gives you a big red warning if you try to do this, but it
> > doesn't, and shouldn't, try to stop you. What if you really want to
> > remove Python? Postage is not the only package manager, so python is not
> > compulsory.
> 
> It doesn't here.  Someone else did the same thing a few weeks ago with
> no warning or didn't mention seeing one at least.  I've read where
> others have done this too.
> 
> It just seems to me that portage should keep it so it can work.  It
> needs python to do that.  Since portage is the package manager for
> Gentoo, portage is the one that should be protected.


Portage is not the package manager for Gentoo. It is *A* package manager for 
Gentoo.

Trying to assign it some special exalted status will always get you in trouble 
when trying to understand why things are the way they are. The only special 
thing about portage is that it carries officially supported status.


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] baselayout2/openrc question

[Alan McKinnon]

On Wednesday 03 February 2010 20:31:31 Neil Bothwick wrote:
> > It just seems to me that portage should keep it so it can work.  It 
> > needs python to do that.  Since portage is the package manager for 
> > Gentoo, portage is the one that should be protected. 
> 
> Portage is A package manager, but if you are using portage to remove
> packages, it should be intelligent about removing its own dependencies.
> 
> Taken more globally, maybe portage should warn whenever you are trying to
> remove a package that is a dependency of anything in @world.
 
Could be useful if implemented with an off switch

Or leave it off by default, users can enable it in make.conf if they wish. I 
often unmerge deps of things in world, but I know (usually) what I'm doing and 
will follow up with a --deep later. Annoying "Are you sure?" "Are you REALLY 
sure?" might make me switch to Ubuntu :-)



-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] baselayout2/openrc question

[Dale]

Alan McKinnon wrote:
> On Wednesday 03 February 2010 20:07:33 Dale wrote:
>   
>> Neil Bothwick wrote:
>>     
>>> On Tue, 02 Feb 2010 18:09:08 -0600, Dale wrote:
>>>       
>>>> In my opinion, the old portage was good, the new one is even better.
>>>> Now if the next version will prevent a person from borking their
>>>> system, that would be heaven.  lol  You know, unmerge python and see
>>>> what happens.  Yes, you can still unmerge python, even the only version
>>>> you have left, and portage not say a darn thing.  It kills the heck out
>>>> of portage tho.
>>>>         
>>> Portage gives you a big red warning if you try to do this, but it
>>> doesn't, and shouldn't, try to stop you. What if you really want to
>>> remove Python? Postage is not the only package manager, so python is not
>>> compulsory.
>>>       
>> It doesn't here.  Someone else did the same thing a few weeks ago with
>> no warning or didn't mention seeing one at least.  I've read where
>> others have done this too.
>>
>> It just seems to me that portage should keep it so it can work.  It
>> needs python to do that.  Since portage is the package manager for
>> Gentoo, portage is the one that should be protected.
>>     
>
>
> Portage is not the package manager for Gentoo. It is *A* package manager for 
> Gentoo.
>
> Trying to assign it some special exalted status will always get you in trouble 
> when trying to understand why things are the way they are. The only special 
> thing about portage is that it carries officially supported status.
>
>   

That was my point.  Someone else can make a package manager if they want 
to but portage is the official Gentoo package manager.  As far as I 
know, portage has always been Gentoo's package manager.  I been here 
since 1.4 so while it is possible that I missed it but somewhat doubtful.

Dale

:-)  :-) 

Re: [gentoo-user] baselayout2/openrc question

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

On Wed, 3 Feb 2010 21:29:30 +0200, Alan McKinnon wrote:

> > Taken more globally, maybe portage should warn whenever you are
> > trying to remove a package that is a dependency of anything in
> > @world.  
>  
> Could be useful if implemented with an off switch
> 
> Or leave it off by default, users can enable it in make.conf if they
> wish. I often unmerge deps of things in world, but I know (usually)
> what I'm doing and will follow up with a --deep later. Annoying "Are
> you sure?" "Are you REALLY sure?" might make me switch to Ubuntu :-)

A command line argument (--force?) would be fine, but you can't complain
it's annoying when you have just complained that portage doesn't do this.
Either you want to be able to shoot yourself in the foot or you don't.


-- 
Neil Bothwick

Cross-country skiing is great in small countries.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] baselayout2/openrc question

[Dale]

Neil Bothwick wrote:
> On Wed, 3 Feb 2010 21:29:30 +0200, Alan McKinnon wrote:
>
>   
>>> Taken more globally, maybe portage should warn whenever you are
>>> trying to remove a package that is a dependency of anything in
>>> @world.  
>>>       
>>  
>> Could be useful if implemented with an off switch
>>
>> Or leave it off by default, users can enable it in make.conf if they
>> wish. I often unmerge deps of things in world, but I know (usually)
>> what I'm doing and will follow up with a --deep later. Annoying "Are
>> you sure?" "Are you REALLY sure?" might make me switch to Ubuntu :-)
>>     
>
> A command line argument (--force?) would be fine, but you can't complain
> it's annoying when you have just complained that portage doesn't do this.
> Either you want to be able to shoot yourself in the foot or you don't.
>
>   

I agree with this.  I like the idea of --force.  It would let portage 
know that you are aware of what you are doing.  Thing is, sometimes new 
people remove python and they don't know YET that portage has to have 
python.  They find that out afterwards. 

Thing is, if you try to unmerge portage, it will tell you it will break 
stuff.  Removing portage can be recovered from easily.  We don't really 
need a warning for that.  You just untar the thing and carry on.  
Removing python is not that simple unless you happen to have a binary 
saved.  The bad thing is, since python is not a "system" package, it 
doesn't even save the last compiled binary in /usr/portage/packages/All/ 
if you only have buildsyspkg in make.conf.  It does portage but not 
python.  If you want to have python saved, you have to do it manually or 
set buildpkg in make.conf which will save a copy of EVERYTHING.  That 
would include the world packages as well.

I seriously doubt the devs will change any of this anytime soon tho.  
This is pretty much a mute point.

Dale

:-)  :-) 

Re: [gentoo-user] baselayout2/openrc question

[Alan McKinnon]

On Thursday 04 February 2010 02:04:36 Neil Bothwick wrote:
> On Wed, 3 Feb 2010 21:29:30 +0200, Alan McKinnon wrote:
> > > Taken more globally, maybe portage should warn whenever you are
> > > trying to remove a package that is a dependency of anything in
> > > @world.
> >
> > Could be useful if implemented with an off switch
> >
> > Or leave it off by default, users can enable it in make.conf if they
> > wish. I often unmerge deps of things in world, but I know (usually)
> > what I'm doing and will follow up with a --deep later. Annoying "Are
> > you sure?" "Are you REALLY sure?" might make me switch to Ubuntu :-)
> 
> A command line argument (--force?) would be fine, but you can't complain
> it's annoying when you have just complained that portage doesn't do this.

I didn't make that complaint...


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] baselayout2/openrc question

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]

On Thu, 4 Feb 2010 10:46:17 +0200, Alan McKinnon wrote:

> > A command line argument (--force?) would be fine, but you can't
> > complain it's annoying when you have just complained that portage
> > doesn't do this.  
> 
> I didn't make that complaint...

Sorry, that comment was aimed at Dale. I know you be quite happy to take
responsibility for borking your own system :P


-- 
Neil Bothwick

Top Oxymorons Number 10: Computer security

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] baselayout2/openrc question

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

On Wed, 03 Feb 2010 21:06:54 -0600, Dale wrote:

> The bad thing is, since python is not a "system" package, it 
> doesn't even save the last compiled binary
> in /usr/portage/packages/All/ if you only have buildsyspkg in
> make.conf.  It does portage but not python.

That's because python is no longer an essential requirement of Gentoo. It
is a dependency of portage, but Gentoo now supports multiple package
managers, so portage is not required either.


-- 
Neil Bothwick

The world is a tragedy to those who feel, but a comedy to those who
think.(Horace Walpole)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] baselayout2/openrc question

[Dale]

Neil Bothwick wrote:
> On Wed, 03 Feb 2010 21:06:54 -0600, Dale wrote:
>
>   
>> The bad thing is, since python is not a "system" package, it 
>> doesn't even save the last compiled binary
>> in /usr/portage/packages/All/ if you only have buildsyspkg in
>> make.conf.  It does portage but not python.
>>     
>
> That's because python is no longer an essential requirement of Gentoo. It
> is a dependency of portage, but Gentoo now supports multiple package
> managers, so portage is not required either.
>
>   

That's true but unmerging python still breaks portage.  Talking about 
some other package manager doesn't affect portage and the fact that 
removing python breaks it.  The facts still remain the same as before.  
Remove python and portage is broken.

Dale

:-)  :-) 

Re: [gentoo-user] baselayout2/openrc question

[Alan McKinnon]

On Thursday 04 February 2010 12:14:52 Dale wrote:
> Neil Bothwick wrote:
> > On Wed, 03 Feb 2010 21:06:54 -0600, Dale wrote:
> >> The bad thing is, since python is not a "system" package, it
> >> doesn't even save the last compiled binary
> >> in /usr/portage/packages/All/ if you only have buildsyspkg in
> >> make.conf.  It does portage but not python.
> >
> > That's because python is no longer an essential requirement of Gentoo. It
> > is a dependency of portage, but Gentoo now supports multiple package
> > managers, so portage is not required either.
> 
> That's true but unmerging python still breaks portage.  Talking about
> some other package manager doesn't affect portage and the fact that
> removing python breaks it.  The facts still remain the same as before.
> Remove python and portage is broken.


How about a portage feature request?

The contents of @system can have dependencies. Put a setting in a conf file 
which means the system uses portage, therefore python is in @system.

Without the setting, python does not get included in @system.

I have no idea how this would fly, it's just an idea off the top of my head

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] baselayout2/openrc question

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

On Thu, 4 Feb 2010 13:05:55 +0200, Alan McKinnon wrote:

> How about a portage feature request?
> 
> The contents of @system can have dependencies. Put a setting in a conf
> file which means the system uses portage, therefore python is in
> @system.
> 
> Without the setting, python does not get included in @system.

How about giving the same warning when unmerging a dependency of @system
as you do when unmerging a package directly in there. Either way, you
risk breaking the system.

Hmm, the random tagline is spookily relevant.


-- 
Neil Bothwick

I do not like this dumb machine
I really ought to sell it.
It never does just what I want
But only what I tell it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] baselayout2/openrc question

[Alan McKinnon]

On Thursday 04 February 2010 15:37:17 Neil Bothwick wrote:
> On Thu, 4 Feb 2010 13:05:55 +0200, Alan McKinnon wrote:
> > How about a portage feature request?
> >
> > The contents of @system can have dependencies. Put a setting in a conf
> > file which means the system uses portage, therefore python is in
> > @system.
> >
> > Without the setting, python does not get included in @system.
> 
> How about giving the same warning when unmerging a dependency of @system
> as you do when unmerging a package directly in there. Either way, you
> risk breaking the system.

Aren't all deps of packages in @system themselves already in @system?


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] baselayout2/openrc question

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

On Thu, 4 Feb 2010 16:14:25 +0200, Alan McKinnon wrote:

> > How about giving the same warning when unmerging a dependency of
> > @system as you do when unmerging a package directly in there. Either
> > way, you risk breaking the system.  
> 
> Aren't all deps of packages in @system themselves already in @system?

No, otherwise portage would complain if you tried to unmerge python.
Anyway, deps are USE-dependent. Try USE="X" emerge @system on a headless
server to see jut how much @system can pull in.


-- 
Neil Bothwick

Life Support System Failure - Reboot Patient (Y/n)?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] baselayout2/openrc question

[Mike Edenfield]

On 2/4/2010 6:05 AM, Alan McKinnon wrote:

> How about a portage feature request?
>
> The contents of @system can have dependencies. Put a setting in a conf file
> which means the system uses portage, therefore python is in @system.
>
> Without the setting, python does not get included in @system.

Since the system package set is package manageragnostic, perhaps that's 
the wrong place to deal with dependencies for portage or whatever?

The package manager itself should know enough to keep itself functional. 
  It just seems odd that portage lets you use portage commands to break 
portage.  If I wrote a package manager in C# (as a ridiculous example) I 
would probably make it smart enough not to let you remove mono.

--K

Re: [gentoo-user] baselayout2/openrc question

[Mike Edenfield]

On 2/4/2010 10:43 AM, Neil Bothwick wrote:
> On Thu, 4 Feb 2010 16:14:25 +0200, Alan McKinnon wrote:
>
>>> How about giving the same warning when unmerging a dependency of
>>> @system as you do when unmerging a package directly in there. Either
>>> way, you risk breaking the system.
>>
>> Aren't all deps of packages in @system themselves already in @system?
>
> No, otherwise portage would complain if you tried to unmerge python.
> Anyway, deps are USE-dependent. Try USE="X" emerge @system on a headless
> server to see jut how much @system can pull in.

Portage isn't in @system, either.  "virtual/portage" is, but paludis 
also provides that.  Python isn't a dependency of any other system 
package (except "file", but that's only enabled by the USE flag).

It appears that portage's refusal to unmerge itself is hard-coded into 
portage; that reinforces my belief that portage should be responsible 
for refusing to unmerge it's own dependencies.

--Mike

Re: [gentoo-user] baselayout2/openrc question

[Dale]

Mike Edenfield wrote:
> On 2/4/2010 10:43 AM, Neil Bothwick wrote:
>> On Thu, 4 Feb 2010 16:14:25 +0200, Alan McKinnon wrote:
>>
>>>> How about giving the same warning when unmerging a dependency of
>>>> @system as you do when unmerging a package directly in there. Either
>>>> way, you risk breaking the system.
>>>
>>> Aren't all deps of packages in @system themselves already in @system?
>>
>> No, otherwise portage would complain if you tried to unmerge python.
>> Anyway, deps are USE-dependent. Try USE="X" emerge @system on a headless
>> server to see jut how much @system can pull in.
>
> Portage isn't in @system, either.  "virtual/portage" is, but paludis 
> also provides that.  Python isn't a dependency of any other system 
> package (except "file", but that's only enabled by the USE flag).
>
> It appears that portage's refusal to unmerge itself is hard-coded into 
> portage; that reinforces my belief that portage should be responsible 
> for refusing to unmerge it's own dependencies.
>
> --Mike
>

Just picking a random post here.  The devs know this.  It has been 
pointed out on -dev and on b.g.o. as well.  They won't do anything to 
correct this.  It just seems to me that portage shouldn't break itself.  
Since there are other package managers, they should not be able to break 
themselves either.  I think maybe it should be the package manager 
itself that prevents this.  That way it fixes it for everyone.  I'm just 
not sure this is doable.

The biggest point is, the devs know but are not interested in fixing 
it.  Their response is to shut up and get over it, not in those words 
but still.

Dale

:-)  :-) 

Re: [gentoo-user] baselayout2/openrc question

[Alan McKinnon]

On Thursday 04 February 2010 17:54:06 Mike Edenfield wrote:
> On 2/4/2010 6:05 AM, Alan McKinnon wrote:
> > How about a portage feature request?
> >
> > The contents of @system can have dependencies. Put a setting in a conf
> > file which means the system uses portage, therefore python is in @system.
> >
> > Without the setting, python does not get included in @system.
> 
> Since the system package set is package manageragnostic, perhaps that's
> the wrong place to deal with dependencies for portage or whatever?
> 
> The package manager itself should know enough to keep itself functional.
>   It just seems odd that portage lets you use portage commands to break
> portage.  If I wrote a package manager in C# (as a ridiculous example) I
> would probably make it smart enough not to let you remove mono.

Well, portage IS smart enough to not let you remove the toolchain or the C 
library.

All of which is moot of course if the bloody compiler can't be launched

-- 
alan dot mckinnon at gmail dot com

[gentoo-user] Re: baselayout2/openrc question

[walt]

On 02/04/2010 01:29 AM, Neil Bothwick wrote:
> ...Gentoo now supports multiple package
> managers, so portage is not required either.

I seem to be falling behind.  What other package managers does gentoo support?

Re: [gentoo-user] Re: baselayout2/openrc question

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 788 bytes --]

On Fri, Feb 05, 2010 at 03:52:15PM -0800, walt wrote:
> On 02/04/2010 01:29 AM, Neil Bothwick wrote:
> > ...Gentoo now supports multiple package
> > managers, so portage is not required either.
> 
> I seem to be falling behind.  What other package managers does gentoo support?
 
 There are two other package managers that can be used on gentoo
 systems that I know of.  pkgcore and paludis.

However, they are supported by their developers, and, the last time I
looked, gentoo's documentation still only supports portage.
 
 In that sense, portage is still gentoo's _official_ package manager,
 but there are alternatives if you don't want to use portage.  So,
 python actually is not required if you use paludis.  I believe pkgcore,
 however, requires it.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]