Re: [gentoo-user] baselayout2/openrc question
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
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 signature.asc Description: PGP signature
Re: [gentoo-user] baselayout2/openrc question
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) signature.asc Description: PGP signature
Re: [gentoo-user] baselayout2/openrc question
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
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
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. signature.asc Description: PGP signature
Re: [gentoo-user] baselayout2/openrc question
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
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)? signature.asc Description: PGP signature
Re: [gentoo-user] baselayout2/openrc question
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
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
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
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
Re: [gentoo-user] baselayout2/openrc question
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 signature.asc Description: PGP signature
Re: [gentoo-user] baselayout2/openrc question
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
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
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. signature.asc Description: PGP signature
Re: [gentoo-user] baselayout2/openrc question
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
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
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
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. signature.asc Description: PGP signature
Re: [gentoo-user] baselayout2/openrc question
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
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
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
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
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 pgpUYn0oC1pIv.pgp Description: PGP signature
Re: [gentoo-user] baselayout2/openrc question
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
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
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
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
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
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
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
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
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 zmed...@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
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
