Re: [gentoo-user] package conflict on update
On Monday 09 January 2006 02:07, a tiny voice compelled Abhay Kedia to write: On Monday 09 January 2006 02:28, Trenton Adams wrote: Who says they know they have a fear of computers? You can be doing something that you don't even know you're afraid of. Obviously if it was total fear, they would know about it. LOL!!! Unknown fear? I have heard about Fear of unknown but this one is new. I agree Abhay. I read the above and was speachless. I'm afraid of heights and I damned sure know what is causing my heart to race when I'm climbimg back onto the ladder after working on my roof. I seems to me that one could have an unknown fear of computers if they had never been exposed to one. Such a person wouldn't likely be installing Gentoo. -- Regards, Ernie -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
On Sunday 08 January 2006 03:25, Trenton Adams wrote: So, there's documentation that specifically explains that packages can be split, and this can cause a conflict? I tried to find that, after What? How is packages being split even comes in question and why does it need specific documentation? A conflict is a conflict. It can arise because of any new change that has been committed to portage. Man pages explain how to solve these conflicts. Job done! Now I don't understand how hand-picking each problem and then explaining about it is going to help. Documentation about a super-set is present. How will writing the same thing about each subset help the matter? If anything it will just increase the redundancy. What you want is a how to on climbing the stairs. Either you can write, Climb 1st step and then go step by step or you can write Climb 1st step, then climb 2nd step, then 3rd step, then climb...? Which one do you want? I dont' need most of gentoo's documentation, as I've found it quite easy to use, after learning and reading about a few basic things. But not everyone does. Why? Why doesn't everyone else find Gentoo easy? What is it that differs you from others? Some super intelligence? The only difference between you and the others that I can see is that you chose to read while others don't. Regards, Abhay pgpbUAdzdLeJf.pgp Description: PGP signature
Re: [gentoo-user] package conflict on update
On Sunday 08 January 2006 06:36, Trenton Adams wrote: Here we go again, who says that you have to limit it to a menu? Give a menu, but allow a graphical shell during install for those that want to do extra packages, or whatever. Or, even provide a dynamically extendable menu that can grab packages lists from other places, from another CD, floppy, Internet, etc. So, to not provide a menu would be *limiting* as well. But I do agree with you Holly, that providing *only* a *predefined* graphical menu for package installation would be limiting. Menu of what? How will a Gentoo developer know what you want to install? If you are starting from Stage 3, you just need to choose what to install and thats it. How will a menu help you in that? As far as graphics based Gentoo install is concerned. I don't think that it is even anywhere near Gentoo Dev's priorities right now. Wouldn't it be beneficial to provide automated graphical installs for gentoo, but provide the option to open a graphical shell at *all* stages of the installation process? Wouldn't that be ultimate flexibility? I read about the new graphical install for gentoo, and perhaps it already does this!?!? Yes having a graphical install process would be great. Why don't you volunteer and try to write one for us? :) Regards, Abhay pgpJ9CPke6u3s.pgp Description: PGP signature
Re: [gentoo-user] package conflict on update
On 1/8/06, Abhay Kedia [EMAIL PROTECTED] wrote: On Sunday 08 January 2006 03:25, Trenton Adams wrote: So, there's documentation that specifically explains that packages can be split, and this can cause a conflict? I tried to find that, after What? How is packages being split even comes in question and why does it need specific documentation? A conflict is a conflict. It can arise because of any new change that has been committed to portage. Man pages explain how to solve these conflicts. Job done! Now I don't understand how hand-picking each problem and then explaining about it is going to help. Documentation about a super-set is present. How will writing the same thing about each subset help the matter? If anything it will just increase the redundancy. What you want is a how to on climbing the stairs. Either you can write, Climb 1st step and then go step by step or you can write Climb 1st step, then climb 2nd step, then 3rd step, then climb...? Which one do you want? I dont' need most of gentoo's documentation, as I've found it quite easy to use, after learning and reading about a few basic things. But not everyone does. Why? Why doesn't everyone else find Gentoo easy? What is it that differs you from others? Some super intelligence? The only difference between you and the others that I can see is that you chose to read while others don't. Well, could be many things. I've found fear of computers to be one blocker to being better at computers than one can be. Having fear creates a mind block. Another one could simply be lack of experience. The more experience you have, the more likely you are able to solve a *new* problem quickly, as it could be related in some way. Perhaps you can call this intuition. And I'm sure there are many more. So no, not superior intelligence. In fact, I don't believe in *genius*. :) Actually, I had a great debate about this topic with a guy at work. He worships people like Linus and such. I told him that even people like Linus, although intelligent, will happily admit that they are products of circumstance. And, to prove my point, I did a search about Linus on this topic. As it were, he wrote a book called The Accidental Revolutionary, or something like that. I've actually been meaning to read it. So, either Linus has false humility (which is arrogance), or he means what he says. I've also found that those who think they are intelligent, usually are not. :D As it were, I believe Linus to actually be intelligent, only because he decides to actually work, rather than sit on his butt all day. But, that's all a side tangent. LOL Regards, Abhay -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
On 1/8/06, Abhay Kedia [EMAIL PROTECTED] wrote: On Sunday 08 January 2006 06:36, Trenton Adams wrote: Here we go again, who says that you have to limit it to a menu? Give a menu, but allow a graphical shell during install for those that want to do extra packages, or whatever. Or, even provide a dynamically extendable menu that can grab packages lists from other places, from another CD, floppy, Internet, etc. So, to not provide a menu would be *limiting* as well. But I do agree with you Holly, that providing *only* a *predefined* graphical menu for package installation would be limiting. Menu of what? How will a Gentoo developer know what you want to install? If you are starting from Stage 3, you just need to choose what to install and thats it. How will a menu help you in that? As far as graphics based Gentoo install is concerned. I don't think that it is even anywhere near Gentoo Dev's priorities right now. Really? Then why have they already created one? Hmm. Wouldn't it be beneficial to provide automated graphical installs for gentoo, but provide the option to open a graphical shell at *all* stages of the installation process? Wouldn't that be ultimate flexibility? I read about the new graphical install for gentoo, and perhaps it already does this!?!? Yes having a graphical install process would be great. Why don't you volunteer and try to write one for us? :) Yeah, I would love to find the time to do that. At this moment though I don't have the time, as my wife would be upset with me doing extra work when I come home from work after doing the extra work that I do after coming home from work. LOL. But I certainly will when I get the time. Regards, Abhay -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
On Sunday 08 January 2006 13:57, Trenton Adams wrote: Menu of what? How will a Gentoo developer know what you want to install? If you are starting from Stage 3, you just need to choose what to install and thats it. How will a menu help you in that? As far as graphics based Gentoo install is concerned. I don't think that it is even anywhere near Gentoo Dev's priorities right now. Really? Then why have they already created one? Hmm. They have? Where? pgprkyOaj6rP1.pgp Description: PGP signature
Re: [gentoo-user] package conflict on update
http://www.gentoo.org/proj/en/releng/installer/ On 1/8/06, Abhay Kedia [EMAIL PROTECTED] wrote: On Sunday 08 January 2006 13:57, Trenton Adams wrote: Menu of what? How will a Gentoo developer know what you want to install? If you are starting from Stage 3, you just need to choose what to install and thats it. How will a menu help you in that? As far as graphics based Gentoo install is concerned. I don't think that it is even anywhere near Gentoo Dev's priorities right now. Really? Then why have they already created one? Hmm. They have? Where? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
On Sunday 08 January 2006 14:33, Trenton Adams wrote: http://www.gentoo.org/proj/en/releng/installer/ Looks great to me. Just didn't see any discussion on gentoo-dev or may be I missed it. So now what do you want then? You have a graphical based install and once you have a working system, you can install more packages. What makes you say that gentoo is difficult? pgp8nWpNSe1aH.pgp Description: PGP signature
Re: [gentoo-user] package conflict on update
ROFL. :P I'm just saying that there's *always* room for improvement. And this install thing is a good start. Automation, with flexibility intact, is never a bad thing. On 1/8/06, Abhay Kedia [EMAIL PROTECTED] wrote: On Sunday 08 January 2006 14:33, Trenton Adams wrote: http://www.gentoo.org/proj/en/releng/installer/ Looks great to me. Just didn't see any discussion on gentoo-dev or may be I missed it. So now what do you want then? You have a graphical based install and once you have a working system, you can install more packages. What makes you say that gentoo is difficult? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
On Sunday 08 January 2006 03:23, a tiny voice compelled Trenton Adams to write: Well, could be many things. I've found fear of computers to be one blocker to being better at computers than one can be. Having fear creates a mind block. Why would someone with a fear of computers even consider Gentoo? -- Regards, Ernie -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
On 1/8/06, Ernie Schroder [EMAIL PROTECTED] wrote: On Sunday 08 January 2006 03:23, a tiny voice compelled Trenton Adams to write: Well, could be many things. I've found fear of computers to be one blocker to being better at computers than one can be. Having fear creates a mind block. Why would someone with a fear of computers even consider Gentoo? Who says they know they have a fear of computers? You can be doing something that you don't even know you're afraid of. Obviously if it was total fear, they would know about it. -- Regards, Ernie -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
On Monday 09 January 2006 02:28, Trenton Adams wrote: Who says they know they have a fear of computers? You can be doing something that you don't even know you're afraid of. Obviously if it was total fear, they would know about it. LOL!!! Unknown fear? I have heard about Fear of unknown but this one is new. pgp9TEK6EgoIp.pgp Description: PGP signature
Re: [gentoo-user] package conflict on update
Trenton Adams schreef:
Oops, forgot to reply to everything.
On 1/6/06, Holly Bostick [EMAIL PROTECTED] wrote:
Trenton Adams schreef:
On 1/5/06, Neil Bothwick [EMAIL PROTECTED] wrote:
On Thu, 5 Jan 2006 16:32:20 -0700, Trenton Adams wrote:
something like
if_blocked_by('openmotif') ewarn You must unmerge
openmotif before proceeding
Yes, or as follows...
if_blocked_by('openmotif') auto_unmerge('openmotif') #
continue with merge which should automatically be merging
openmotif anyhow.
Absolutely not! I don't want portage removing something I may
be using at the time without my saying so.
Good point. Perhaps it should ask then?
Well, it does, by stopping and waiting for you to perform an action
and either restart the stopped process (if the action you took was
to unmerge the blocking package), or to forego the stopped process
entirely, if you choose not to remove the blocked package because
you want to keep it for whatever reason (it could happen).
You're assuming that unmerging the blocking package is *always* the
right solution for everyone at all times (in this case, it's not
really relevant, since motif-config will itself re-install
openmotif), but the point of Gentoo is that you are in control. If
I am in control, then I have to decide what I want done in each
particular situation that occurs, which is exactly what I have to
do with the current setup-- very obviously, since Portage will stop
until I make a decision and act on it. So fine, your new updated
Portage informs me there's a block, and says, I could do this to
solve it, shall I? I myself am going to say no, because I want
to know the nature of the block, and how Portage's proposed action
is going to affect the system that I have carefully customized to
my individual needs.
Yes, flexibility is GREAT. That's one reason I really like gentoo,
and linux in general. However, I also like simplicity, or should I
say, I like to have the choice. So, one could easily make gentoo
have auto-detect and handle features, while allowing configuration
changes that disable automatic behaviour. You could have individual
enable/disable options for each feature, as well as one global
feature than enables/disables all auto-detect features. Then you
could have include/excludes for each feature so that the global would
not override them.
So, the bottom line is this, one person says that things are
difficult because they need to be, in order to be flexible. But I
say that if things are truly flexible, then it should also be
possible to make them automatic, or simple. That's what I call
ULTIMATE flexiblity, which is what I mentioned in another post that I
made. When I originally started with gentoo linux, I read the part
about why gentoo linux came about. Basically it was all about doing
things the way you want. Well, I like the flexiblity, but I also
want the simplicity. :) Let us have the simplicity of RedHat, and
RPMs (waiting for flames), but with flexibility as well.
Well, if this is your opinion, I must then accept the burden of being
one of those members of the Linux community you mention
Trenton Adams schreef:
Yes, and I've noticed there's a big problem with the linux community
at large. People that know and understand linux have a lot of the
times not helped the open source intiative, in that they like
things to be difficult,
Although this is not strictly true I don't *like* things to be
difficult, /per se/ but I do tend to do things the hard way rather
than the easy way
because it makes them somehow seem smarter. In all reality, it
doesn't take a genius to use linux, just someone who likes to read a
whole lot.
I do like to read a whole lot (always have), and I don't so much care
how smart anyone thinks I am, but if I am in any way smart, I do want
that to be recognized, which is a different thing.
But if you leave out the rather insulting insinuation that such users
are not in fact smart, but ego-trippers who just have nothing to do but
read dry technical texts that no normal person would ever bother with,
I'll cop to the charge.
The thing is, I prefer things to be slightly more difficult because I
believe that people using advanced tools should have a clue about how
they work and how to use them properly.
As I have said before, and will likely say again in the future, I
believe that a policy of providing advanced technology, dumbed-down so
that it Just Works to the unwashed masses (let us say, my
boyfriend's grandmother, who is a very nice lady, or my aunt, or his
mother, who are of an age and about the same level of computer expertise
and interest-- which is to say, none, although my bf's mother has now
had a computer forced on her), is dangerously unwise.
We have seen the results of doing so in both large and small ways, yet
we persist. I believe that advanced technology should be sufficiently
difficult to use until such time
Re: [gentoo-user] package conflict on update
On Saturday 07 January 2006 10:43, Trenton Adams wrote: which is what I mentioned in another post that I made. When I originally started with gentoo linux, I read the part about why gentoo linux came about. Basically it was all about doing things the way you want. Well, I like the flexiblity, but I also want the simplicity. :) Let us have the simplicity of RedHat, and RPMs (waiting for flames), but with flexibility as well. You should review what you want out of your Linux Distro cos I for once am failing to understand your point of view. What do you want? Gentoo is gentoo. It gives you full control to do what *YOU* want to do and taking full control of a full fledged OS is needless to say; difficult. If you don't desire or need the full control then imho there are various other distros available with *simplicity* written all over them. They should be there at your service. But if Gentoo starts to uninstall stuff from my system without asking me then the whole philosophy of control dies or Gentoo dies. Regards, Abhay pgp7XmAVdrIf0.pgp Description: PGP signature
Re: [gentoo-user] package conflict on update
On 1/7/06, Abhay Kedia [EMAIL PROTECTED] wrote: On Saturday 07 January 2006 10:43, Trenton Adams wrote: which is what I mentioned in another post that I made. When I originally started with gentoo linux, I read the part about why gentoo linux came about. Basically it was all about doing things the way you want. Well, I like the flexiblity, but I also want the simplicity. :) Let us have the simplicity of RedHat, and RPMs (waiting for flames), but with flexibility as well. You should review what you want out of your Linux Distro cos I for once am failing to understand your point of view. What do you want? Gentoo is gentoo. It gives you full control to do what *YOU* want to do and taking full control of a full fledged OS is needless to say; difficult. If you don't desire or need the full control then imho there are various other distros available with *simplicity* written all over them. They should be there at your service. But if Gentoo starts to uninstall stuff from my system without asking me then the whole philosophy of control dies or Gentoo dies. I never said it should uninstall stuff without asking you. In fact, I suggested it ask me. And gentoo is hardly difficult for anyone with a brain. *Perhaps* time consuming to learn, but not difficult. And as I said before, I'm using gentoo because of it's flexibility, so that's what I'm sticking with. In fact, all my Linux computers have now been converted to gentoo, as of this past week. So I don't plan on switching them back any time soon. I'm just of the mind that we really should encourage it's use, while encouraging people to also understand what's happening under the hood. I like both that my car just works, and I don't have to know how the pistons go up and down, but that I can also look under the hood if I so desire. Regards, Abhay -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
Interesting viewpoint, and some of the things you say do have
relevance Holly. Thanks. But, I still think things should be a
little easier for the average user. I'm really sick of the windows
admins who *think* linux is hard, when it's really not, and bash it
all the time because of that. I'm all for converting them. :)
On 1/7/06, Holly Bostick [EMAIL PROTECTED] wrote:
Trenton Adams schreef:
Oops, forgot to reply to everything.
On 1/6/06, Holly Bostick [EMAIL PROTECTED] wrote:
Trenton Adams schreef:
On 1/5/06, Neil Bothwick [EMAIL PROTECTED] wrote:
On Thu, 5 Jan 2006 16:32:20 -0700, Trenton Adams wrote:
something like
if_blocked_by('openmotif') ewarn You must unmerge
openmotif before proceeding
Yes, or as follows...
if_blocked_by('openmotif') auto_unmerge('openmotif') #
continue with merge which should automatically be merging
openmotif anyhow.
Absolutely not! I don't want portage removing something I may
be using at the time without my saying so.
Good point. Perhaps it should ask then?
Well, it does, by stopping and waiting for you to perform an action
and either restart the stopped process (if the action you took was
to unmerge the blocking package), or to forego the stopped process
entirely, if you choose not to remove the blocked package because
you want to keep it for whatever reason (it could happen).
You're assuming that unmerging the blocking package is *always* the
right solution for everyone at all times (in this case, it's not
really relevant, since motif-config will itself re-install
openmotif), but the point of Gentoo is that you are in control. If
I am in control, then I have to decide what I want done in each
particular situation that occurs, which is exactly what I have to
do with the current setup-- very obviously, since Portage will stop
until I make a decision and act on it. So fine, your new updated
Portage informs me there's a block, and says, I could do this to
solve it, shall I? I myself am going to say no, because I want
to know the nature of the block, and how Portage's proposed action
is going to affect the system that I have carefully customized to
my individual needs.
Yes, flexibility is GREAT. That's one reason I really like gentoo,
and linux in general. However, I also like simplicity, or should I
say, I like to have the choice. So, one could easily make gentoo
have auto-detect and handle features, while allowing configuration
changes that disable automatic behaviour. You could have individual
enable/disable options for each feature, as well as one global
feature than enables/disables all auto-detect features. Then you
could have include/excludes for each feature so that the global would
not override them.
So, the bottom line is this, one person says that things are
difficult because they need to be, in order to be flexible. But I
say that if things are truly flexible, then it should also be
possible to make them automatic, or simple. That's what I call
ULTIMATE flexiblity, which is what I mentioned in another post that I
made. When I originally started with gentoo linux, I read the part
about why gentoo linux came about. Basically it was all about doing
things the way you want. Well, I like the flexiblity, but I also
want the simplicity. :) Let us have the simplicity of RedHat, and
RPMs (waiting for flames), but with flexibility as well.
Well, if this is your opinion, I must then accept the burden of being
one of those members of the Linux community you mention
Trenton Adams schreef:
Yes, and I've noticed there's a big problem with the linux community
at large. People that know and understand linux have a lot of the
times not helped the open source intiative, in that they like
things to be difficult,
Although this is not strictly true I don't *like* things to be
difficult, /per se/ but I do tend to do things the hard way rather
than the easy way
because it makes them somehow seem smarter. In all reality, it
doesn't take a genius to use linux, just someone who likes to read a
whole lot.
I do like to read a whole lot (always have), and I don't so much care
how smart anyone thinks I am, but if I am in any way smart, I do want
that to be recognized, which is a different thing.
But if you leave out the rather insulting insinuation that such users
are not in fact smart, but ego-trippers who just have nothing to do but
read dry technical texts that no normal person would ever bother with,
I'll cop to the charge.
The thing is, I prefer things to be slightly more difficult because I
believe that people using advanced tools should have a clue about how
they work and how to use them properly.
As I have said before, and will likely say again in the future, I
believe that a policy of providing advanced technology, dumbed-down so
that it Just Works to the unwashed masses (let us
Re: [gentoo-user] package conflict on update
On Saturday 07 January 2006 22:00, Trenton Adams wrote: I'm just of the mind that we really should encourage it's use, while encouraging people to also understand what's happening under the hood. ...and how do you suggest that should be done? There is tons of documentation available for user to read and know what is happening under the hood but no one wants to RTFM. Even this problem that you faced has been clearly explained along with its solution in man emerge. How should Gentoo force a user to read the documentation and the man pages? I like both that my car just works, and I don't have to know how the pistons go up and down, but that I can also look under the hood if I so desire. Thinking on the wrong lines again and what you want can never happen, at least with Gentoo; because Gentoo does not give you a working car at all. It just gives you spare parts (ebuilds packages), books to read (documentation) and a tool box (portage). Then it tells you to go ahead and make your own car. It totally depends on you whether you want to make it a blazing fast Ferrari or a classy Limo. To achieve anything of that sorts you *HAVE TO* know how the pistons go up and down. If you don't read and just put together the pieces in a random order then you might make a moving car but it will not be a working one. Moral of the story? To have full control, you gotta know how things work inside the engine :) Regards, Abhay pgplgtdTD2sIl.pgp Description: PGP signature
Re: [gentoo-user] package conflict on update
Trenton Adams schreef: Interesting points, but On 1/7/06, Abhay Kedia [EMAIL PROTECTED] wrote: On Saturday 07 January 2006 22:00, Trenton Adams wrote: I like both that my car just works, and I don't have to know how the pistons go up and down, but that I can also look under the hood if I so desire. Thinking on the wrong lines again and what you want can never happen, at least with Gentoo; because Gentoo does not give you a working car at all. It just gives you spare parts (ebuilds packages), books to read (documentation) and a tool box (portage). Then it tells you to go ahead and make your own car. It totally depends on you whether you want to make it a blazing fast Ferrari or a classy Limo. To achieve anything of that sorts you *HAVE TO* know how the pistons go up and down. If you don't read and just put together the pieces in a random order then you might make a moving car but it will not be a working one. Moral of the story? To have full control, you gotta know how things work inside the engine :) Well actually, it could happen. If I had a menu of packages to be installed during some sort of automated install process, then I'm still customizing my system the way I want. So once again, you absolutely *CAN* have gentoo flexibility with easy of install Just a quick question: Isn't creating a menu of packages to be installed part of the install process? If not, because you did not create this menu yourself, then you are not customizing your system the way you want, but rather choosing the most suitable for you amongst a list of pre-defined-- thus, by definition, limiting-- options. If you did create the menu of packages yourself, and it then is (as it must be) considered part of the installation process, then isn't the installation process no longer easy, by your definition of easy? Not quite following the logic here. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
First off all, the install process is only a portion of making gentoo *easier*. At it is kind of a tangent to the original discussion. But, none the less, it is a good discussion. On 1/7/06, Holly Bostick [EMAIL PROTECTED] wrote: Trenton Adams schreef: Interesting points, but On 1/7/06, Abhay Kedia [EMAIL PROTECTED] wrote: On Saturday 07 January 2006 22:00, Trenton Adams wrote: I like both that my car just works, and I don't have to know how the pistons go up and down, but that I can also look under the hood if I so desire. Thinking on the wrong lines again and what you want can never happen, at least with Gentoo; because Gentoo does not give you a working car at all. It just gives you spare parts (ebuilds packages), books to read (documentation) and a tool box (portage). Then it tells you to go ahead and make your own car. It totally depends on you whether you want to make it a blazing fast Ferrari or a classy Limo. To achieve anything of that sorts you *HAVE TO* know how the pistons go up and down. If you don't read and just put together the pieces in a random order then you might make a moving car but it will not be a working one. Moral of the story? To have full control, you gotta know how things work inside the engine :) Well actually, it could happen. If I had a menu of packages to be installed during some sort of automated install process, then I'm still customizing my system the way I want. So once again, you absolutely *CAN* have gentoo flexibility with easy of install Just a quick question: Isn't creating a menu of packages to be installed part of the install process? If not, because you did not create this menu yourself, then you are not customizing your system the way you want, but rather choosing the most suitable for you amongst a list of pre-defined-- thus, by definition, limiting-- options. Here we go again, who says that you have to limit it to a menu? Give a menu, but allow a graphical shell during install for those that want to do extra packages, or whatever. Or, even provide a dynamically extendable menu that can grab packages lists from other places, from another CD, floppy, Internet, etc. So, to not provide a menu would be *limiting* as well. But I do agree with you Holly, that providing *only* a *predefined* graphical menu for package installation would be limiting. Now, I'm just brain storming here... Wouldn't it be beneficial to provide automated graphical installs for gentoo, but provide the option to open a graphical shell at *all* stages of the installation process? Wouldn't that be ultimate flexibility? I read about the new graphical install for gentoo, and perhaps it already does this!?!? If you did create the menu of packages yourself, and it then is (as it must be) considered part of the installation process, then isn't the installation process no longer easy, by your definition of easy? Well, this is a side tangent, given my reply just above. None the less, all of *my* installs from the point after I created my *own* menu would be easy. Not quite following the logic here. Holly -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
Sorry, I shouldn't have said, Here we go again, as that can be antogonizing, which doesn't help anything. :( On 1/7/06, Trenton Adams [EMAIL PROTECTED] wrote: First off all, the install process is only a portion of making gentoo *easier*. At it is kind of a tangent to the original discussion. But, none the less, it is a good discussion. On 1/7/06, Holly Bostick [EMAIL PROTECTED] wrote: Trenton Adams schreef: Interesting points, but On 1/7/06, Abhay Kedia [EMAIL PROTECTED] wrote: On Saturday 07 January 2006 22:00, Trenton Adams wrote: I like both that my car just works, and I don't have to know how the pistons go up and down, but that I can also look under the hood if I so desire. Thinking on the wrong lines again and what you want can never happen, at least with Gentoo; because Gentoo does not give you a working car at all. It just gives you spare parts (ebuilds packages), books to read (documentation) and a tool box (portage). Then it tells you to go ahead and make your own car. It totally depends on you whether you want to make it a blazing fast Ferrari or a classy Limo. To achieve anything of that sorts you *HAVE TO* know how the pistons go up and down. If you don't read and just put together the pieces in a random order then you might make a moving car but it will not be a working one. Moral of the story? To have full control, you gotta know how things work inside the engine :) Well actually, it could happen. If I had a menu of packages to be installed during some sort of automated install process, then I'm still customizing my system the way I want. So once again, you absolutely *CAN* have gentoo flexibility with easy of install Just a quick question: Isn't creating a menu of packages to be installed part of the install process? If not, because you did not create this menu yourself, then you are not customizing your system the way you want, but rather choosing the most suitable for you amongst a list of pre-defined-- thus, by definition, limiting-- options. Here we go again, who says that you have to limit it to a menu? Give a menu, but allow a graphical shell during install for those that want to do extra packages, or whatever. Or, even provide a dynamically extendable menu that can grab packages lists from other places, from another CD, floppy, Internet, etc. So, to not provide a menu would be *limiting* as well. But I do agree with you Holly, that providing *only* a *predefined* graphical menu for package installation would be limiting. Now, I'm just brain storming here... Wouldn't it be beneficial to provide automated graphical installs for gentoo, but provide the option to open a graphical shell at *all* stages of the installation process? Wouldn't that be ultimate flexibility? I read about the new graphical install for gentoo, and perhaps it already does this!?!? If you did create the menu of packages yourself, and it then is (as it must be) considered part of the installation process, then isn't the installation process no longer easy, by your definition of easy? Well, this is a side tangent, given my reply just above. None the less, all of *my* installs from the point after I created my *own* menu would be easy. Not quite following the logic here. Holly -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
On Fri, 6 Jan 2006 12:57:07 +0530, Abhay Kedia wrote: version _after_ the new version has been merged into place. One possible solution would be to have a special feature that, when enabled, allows portage to automatically unmerge an old version _before_ the new one is installed (with protection against unmerging system packages of course). That is no solution AT ALL!!! What if portage unmerges the package and while compiling the new package it gets into an error? You are left with no installed packages. Portage could remove the old package after compilation ebuild package-new.ebuild compile ebuild package-old.ebuild unmerge ebuild package-new.ebuild install This would reduce the chances of something bad happening, but not remove it altogether. So it would have to package up the old files first and re-install them if the new install failed, more than a little messy IMO. -- Neil Bothwick Borg -- James Borg -- licensed to assimilate. signature.asc Description: PGP signature
Re: [gentoo-user] package conflict on update
On Thu, 05 Jan 2006 17:14:36 -0800, Zac Medico wrote:
| if_blocked_by('openmotif')
| ewarn You must unmerge openmotif before proceeding
|
It would be icky to have to specify blocker logic/messages like that.
Not in the sort of cases that come up most often, where functionality has
been moved from a package into another. In this case the block is
entirely predictable. If, for example, you are updating xpdf from version
=X to version X, it will both require and block poppler. The dev has
already modified the ebuild to handle the new dependency, so he will know
about the block.
--
Neil Bothwick
Windows booting: insert CD-ROM 2.
signature.asc
Description: PGP signature
Re: [gentoo-user] package conflict on update
On 1/5/06, Neil Bothwick [EMAIL PROTECTED] wrote:
On Thu, 5 Jan 2006 16:32:20 -0700, Trenton Adams wrote:
something like
if_blocked_by('openmotif')
ewarn You must unmerge openmotif before proceeding
Yes, or as follows...
if_blocked_by('openmotif')
auto_unmerge('openmotif')
# continue with merge which should automatically be merging openmotif
anyhow.
Absolutely not! I don't want portage removing something I may be using at
the time without my saying so.
Good point. Perhaps it should ask then?
--
Neil Bothwick
I am in total control, but don't tell my wife.
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
On 1/6/06, Holly Bostick [EMAIL PROTECTED] wrote:
Trenton Adams schreef:
On 1/5/06, Neil Bothwick [EMAIL PROTECTED] wrote:
On Thu, 5 Jan 2006 16:32:20 -0700, Trenton Adams wrote:
something like
if_blocked_by('openmotif')
ewarn You must unmerge openmotif before proceeding
Yes, or as follows...
if_blocked_by('openmotif')
auto_unmerge('openmotif')
# continue with merge which should automatically be merging openmotif
anyhow.
Absolutely not! I don't want portage removing something I may be using at
the time without my saying so.
Good point. Perhaps it should ask then?
Well, it does, by stopping and waiting for you to perform an action and
either restart the stopped process (if the action you took was to
unmerge the blocking package), or to forego the stopped process
entirely, if you choose not to remove the blocked package because you
want to keep it for whatever reason (it could happen).
You're assuming that unmerging the blocking package is *always* the
right solution for everyone at all times (in this case, it's not really
relevant, since motif-config will itself re-install openmotif), but the
point of Gentoo is that you are in control. If I am in control, then I
have to decide what I want done in each particular situation that
occurs, which is exactly what I have to do with the current setup-- very
obviously, since Portage will stop until I make a decision and act on
it. So fine, your new updated Portage informs me there's a block, and
says, I could do this to solve it, shall I? I myself am going to say
no, because I want to know the nature of the block, and how Portage's
proposed action is going to affect the system that I have carefully
customized to my individual needs.
So I'm right in the same position as I was anyway; the emerge is stopped
(because I said, no don't go on with whatever you plan), and I'm off
reading ChangeLogs and the like to see what's going on in the
environment I'm suddenly dealing with. I suppose that it's all very nice
to have some extra dialog as if Portage was communicating with me more
humanely, but it's just cosmetic, in actual fact.
Of course, that may be because I take time to read some of the
comprehensive documentation that so many have taken the time to write,
so I know what a Blocked Package is, so it doesn't freak me out when I
come across one. So sue me and call me names... oh wait, you had your
rant already. We'll mark that item Done, then.
I don't think anyone wants to call you names. At least not anyone
sensible. But, I see I struck a nerve on one of my previous posts.
That's good though, as we *all* need to be provoked to think a little.
That way we become *wise* rather than *smart*. And wise is better
than smart. :D
Ultimately, I'm sure such an extra dialog would be a nice thing, but I
don't so much see it as something to get all riled up about. Maybe it's
just me.
Holly
--
gentoo-user@gentoo.org mailing list
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
On 1/6/06, Neil Bothwick [EMAIL PROTECTED] wrote:
On Thu, 05 Jan 2006 17:14:36 -0800, Zac Medico wrote:
| if_blocked_by('openmotif')
| ewarn You must unmerge openmotif before proceeding
|
It would be icky to have to specify blocker logic/messages like that.
Not in the sort of cases that come up most often, where functionality has
been moved from a package into another. In this case the block is
entirely predictable. If, for example, you are updating xpdf from version
=X to version X, it will both require and block poppler. The dev has
already modified the ebuild to handle the new dependency, so he will know
about the block.
EXACTLY Neil! :)
--
Neil Bothwick
Windows booting: insert CD-ROM 2.
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
Oops, forgot to reply to everything.
On 1/6/06, Holly Bostick [EMAIL PROTECTED] wrote:
Trenton Adams schreef:
On 1/5/06, Neil Bothwick [EMAIL PROTECTED] wrote:
On Thu, 5 Jan 2006 16:32:20 -0700, Trenton Adams wrote:
something like
if_blocked_by('openmotif')
ewarn You must unmerge openmotif before proceeding
Yes, or as follows...
if_blocked_by('openmotif')
auto_unmerge('openmotif')
# continue with merge which should automatically be merging openmotif
anyhow.
Absolutely not! I don't want portage removing something I may be using at
the time without my saying so.
Good point. Perhaps it should ask then?
Well, it does, by stopping and waiting for you to perform an action and
either restart the stopped process (if the action you took was to
unmerge the blocking package), or to forego the stopped process
entirely, if you choose not to remove the blocked package because you
want to keep it for whatever reason (it could happen).
You're assuming that unmerging the blocking package is *always* the
right solution for everyone at all times (in this case, it's not really
relevant, since motif-config will itself re-install openmotif), but the
point of Gentoo is that you are in control. If I am in control, then I
have to decide what I want done in each particular situation that
occurs, which is exactly what I have to do with the current setup-- very
obviously, since Portage will stop until I make a decision and act on
it. So fine, your new updated Portage informs me there's a block, and
says, I could do this to solve it, shall I? I myself am going to say
no, because I want to know the nature of the block, and how Portage's
proposed action is going to affect the system that I have carefully
customized to my individual needs.
Yes, flexibility is GREAT. That's one reason I really like gentoo,
and linux in general. However, I also like simplicity, or should I
say, I like to have the choice. So, one could easily make gentoo have
auto-detect and handle features, while allowing configuration changes
that disable automatic behaviour. You could have individual
enable/disable options for each feature, as well as one global feature
than enables/disables all auto-detect features. Then you could have
include/excludes for each feature so that the global would not
override them.
So, the bottom line is this, one person says that things are difficult
because they need to be, in order to be flexible. But I say that if
things are truly flexible, then it should also be possible to make
them automatic, or simple. That's what I call ULTIMATE flexiblity,
which is what I mentioned in another post that I made. When I
originally started with gentoo linux, I read the part about why gentoo
linux came about. Basically it was all about doing things the way you
want. Well, I like the flexiblity, but I also want the simplicity. :)
Let us have the simplicity of RedHat, and RPMs (waiting for flames),
but with flexibility as well.
I understand that gentoo is a work in progress, and will probably
remain that way forever (I HOPE). So, any ideas should at least be
analyzed, and thought out, and not just discarded.
So I'm right in the same position as I was anyway; the emerge is stopped
(because I said, no don't go on with whatever you plan), and I'm off
reading ChangeLogs and the like to see what's going on in the
environment I'm suddenly dealing with. I suppose that it's all very nice
to have some extra dialog as if Portage was communicating with me more
humanely, but it's just cosmetic, in actual fact.
Of course, that may be because I take time to read some of the
comprehensive documentation that so many have taken the time to write,
so I know what a Blocked Package is, so it doesn't freak me out when I
come across one. So sue me and call me names... oh wait, you had your
rant already. We'll mark that item Done, then.
Ultimately, I'm sure such an extra dialog would be a nice thing, but I
don't so much see it as something to get all riled up about. Maybe it's
just me.
Holly
--
gentoo-user@gentoo.org mailing list
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
On Thu, 5 Jan 2006 00:29:57 -0700 Trenton Adams [EMAIL PROTECTED] wrote: Ok, so I get the output below when trying to merge after a sync today. My guess is that the openmotif package was made into two separate packages, correct? To the portage developers, how could this be handled? Perhaps emerge could somehow figure out the reason for such a conflict, and then automatically unmerge the original package? Not really a question to the portage developers -- just unmerge openmotif (the blocker) and continue as normal. -- Tom Martin, http://dev.gentoo.org/~slarti AMD64, net-mail, shell-tools, vim, recruiters Gentoo Linux signature.asc Description: PGP signature
Re: [gentoo-user] package conflict on update
On 1/5/06, Tom Martin [EMAIL PROTECTED] wrote: On Thu, 5 Jan 2006 00:29:57 -0700 Trenton Adams [EMAIL PROTECTED] wrote: Ok, so I get the output below when trying to merge after a sync today. My guess is that the openmotif package was made into two separate packages, correct? To the portage developers, how could this be handled? Perhaps emerge could somehow figure out the reason for such a conflict, and then automatically unmerge the original package? Not really a question to the portage developers -- just unmerge openmotif (the blocker) and continue as normal. So what happens to the unknowing user that doesn't figure out that the package was split into multiple packages? Especially if it's a critical system package. They may not like the idea of unmerging the package, and re-merging. -- Tom Martin, http://dev.gentoo.org/~slarti AMD64, net-mail, shell-tools, vim, recruiters Gentoo Linux -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
On Thu, 5 Jan 2006 11:10:38 +, Tom Martin wrote:
To the portage developers, how could this be handled? Perhaps emerge
could somehow figure out the reason for such a conflict, and then
automatically unmerge the original package?
Not really a question to the portage developers -- just unmerge
openmotif (the blocker) and continue as normal.
If would be nice is portage had a means for developers to handle these
types of conflicts in the ebuild. A similar thing happened recently with
xpdf/poppler, it happened with some FTP servers and the ftp-base package
not long ago. I realise it is not possible to handle all conflicts, but
with some instances, like this one, the conflict is expected. even if
there were just a means to print a message if a package hits a block,
something like
if_blocked_by('openmotif')
ewarn You must unmerge openmotif before proceeding
--
Neil Bothwick
I am Tagline of Borg. Prepare to assimilate me.
signature.asc
Description: PGP signature
Re: [gentoo-user] package conflict on update
I ran into this a few days ago. Ah ha, I thought, I just need to update openmotif.Nope, openmotif depended on openmotif-config which was blocked by openmotif.I tried unmasking one, the other, then both all to noavail.
Finally, in frustation I did emerge unmerge openmotif, emerge openmotifand it just worked (pulling in openmotif-config in the process)I for one would like to see portage be a bit smarter about this. It already calculates a dependancy list.
Would it be possible to detect the case where the blocker is part of the dependancy list (ie, will be installed anyway) and automatically offer to unmerge the conflicting package?Or, is this a situation that should be handled with slots? Eg, slot 1 hols openmotif, slot 2 holds openmotif-config newer openmotif.
I can't wait to see the hoop jumping xorg-x11-7.0 will require.-dcm-On 1/5/06, Neil Bothwick
[EMAIL PROTECTED] wrote:On Thu, 5 Jan 2006 11:10:38 +, Tom Martin wrote:
To the portage developers, how could this be handled?Perhaps emerge could somehow figure out the reason for such a conflict, and then automatically unmerge the original package?
Not really a question to the portage developers -- just unmerge openmotif (the blocker) and continue as normal.I realise it is not possible to handle all conflicts, butwith some instances, like this one, the conflict is expected. even if
there were just a means to print a message if a package hits a block,something likeif_blocked_by('openmotif')ewarn You must unmerge openmotif before proceeding--Neil Bothwick
I am Tagline of Borg. Prepare to assimilate me.
Re: [gentoo-user] package conflict on update
On Thu, 5 Jan 2006 11:41:22 +
Neil Bothwick [EMAIL PROTECTED] wrote:
If would be nice is portage had a means for developers to handle these
types of conflicts in the ebuild. A similar thing happened recently
with xpdf/poppler, it happened with some FTP servers and the ftp-base
package not long ago. I realise it is not possible to handle all
conflicts, but with some instances, like this one, the conflict is
expected. even if there were just a means to print a message if a
package hits a block, something like
if_blocked_by('openmotif')
ewarn You must unmerge openmotif before proceeding
An error message like that doesn't really tell the user anything that he
doesn't already know.
It would be more useful if some information was provided:
if blocked_by =x11-libs/openmotif-1.2.3 ; then
eblockinfo Due to changes with blah, it is recommended that
eblockinfo you foobar. See http://bugs.gentoo.org/123456.;
fi
But then, at what point would this information be echoed to the user?
It would have to be during the same pre-merge phase that the blocking
errors appear. Then again, I don't really see any gaping problems with
the current system; once someone has encountered their first pair of
blocking packages, they then understand how to fix blockers in future.
I doubt it's worth the effort.
/shrug
--
Tom Martin, http://dev.gentoo.org/~slarti
AMD64, net-mail, shell-tools, vim, recruiters
Gentoo Linux
signature.asc
Description: PGP signature
Re: [gentoo-user] package conflict on update
On 1/5/06, Tom Martin [EMAIL PROTECTED] wrote: It would be more useful if some information was provided: if blocked_by =x11-libs/openmotif-1.2.3 ; then eblockinfo Due to changes with blah, it is recommended that eblockinfo you foobar. See http://bugs.gentoo.org/123456.; fi Sounds more like information that should be available in the coming emerge --news system. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
On Thu, 5 Jan 2006 16:08:04 +, Tom Martin wrote:
if_blocked_by('openmotif')
ewarn You must unmerge openmotif before proceeding
An error message like that doesn't really tell the user anything that he
doesn't already know.
It may not say anything you or I don't know, but from the number of posts
to this list about blockers, it would clearly help some people.
It would be more useful if some information was provided:
if blocked_by =x11-libs/openmotif-1.2.3 ; then
eblockinfo Due to changes with blah, it is recommended that
eblockinfo you foobar. See http://bugs.gentoo.org/123456.;
fi
But then, at what point would this information be echoed to the user?
It would have to be during the same pre-merge phase that the blocking
errors appear.
Yes, so instead of rushing to this list or the forums, they can do what
the message tells them and be on their way. The current messages are only
useful if you already understand how and why blocks happen, and how to
deal with them.
--
Neil Bothwick
If you got the words it does not mean you got the knowledge.
signature.asc
Description: PGP signature
Re: [gentoo-user] package conflict on update
On 1/5/06, Neil Bothwick [EMAIL PROTECTED] wrote:
On Thu, 5 Jan 2006 11:10:38 +, Tom Martin wrote:
To the portage developers, how could this be handled? Perhaps emerge
could somehow figure out the reason for such a conflict, and then
automatically unmerge the original package?
Not really a question to the portage developers -- just unmerge
openmotif (the blocker) and continue as normal.
If would be nice is portage had a means for developers to handle these
types of conflicts in the ebuild. A similar thing happened recently with
xpdf/poppler, it happened with some FTP servers and the ftp-base package
not long ago. I realise it is not possible to handle all conflicts, but
with some instances, like this one, the conflict is expected. even if
there were just a means to print a message if a package hits a block,
something like
if_blocked_by('openmotif')
ewarn You must unmerge openmotif before proceeding
Yes, or as follows...
if_blocked_by('openmotif')
auto_unmerge('openmotif')
# continue with merge which should automatically be merging openmotif anyhow.
--
Neil Bothwick
I am Tagline of Borg. Prepare to assimilate me.
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
On 1/5/06, Neil Bothwick [EMAIL PROTECTED] wrote:
On Thu, 5 Jan 2006 16:08:04 +, Tom Martin wrote:
if_blocked_by('openmotif')
ewarn You must unmerge openmotif before proceeding
An error message like that doesn't really tell the user anything that he
doesn't already know.
It may not say anything you or I don't know, but from the number of posts
to this list about blockers, it would clearly help some people.
Yes, and I've noticed there's a big problem with the linux community
at large. People that know and understand linux have a lot of the
times not helped the open source intiative, in that they like things
to be difficult, because it makes them somehow seem smarter. In all
reality, it doesn't take a genius to use linux, just someone who likes
to read a whole lot.
Now i'm not saying this is a problem with the people working on
gentoo, so please don't think that I am. But, if you do feel that
way, perhaps you should think twice, and actually support users. I've
always felt that Linux in general could easily surpass windows in
usage, *IF* the linux community would make things more user friendly.
For example, if I didn't have to read the documentation to get
something basic to work, then it's user friendly. That doesn't mean
you have to remove flexibility either. I've seen gui utilities in
windows that had full command line support. If you provide command
line options, the GUI doesn't start. So, one can have user friendly
applications without sacrificing flexibility.
When I first started with gentoo, I was ready to give up. Not because
I didn't know what I was doing with linux, but because I don't really
have the time to read a whole whack of documentation, and the
documntation is not in a nice point form format for those that do know
what they are doing anyhow. Take the gentoo quick install version of
the gentoo hand book. It no longer tells you what commands to
actually run. It just describes what to do, which is of VERY little
value. Luckily I kept a printed copy of the old quick install around,
becuse I have no use for the new version. Why someone would remove
all that useful information from a quick install guide, only to make a
lot less useful, I don't know.
It would be more useful if some information was provided:
if blocked_by =x11-libs/openmotif-1.2.3 ; then
eblockinfo Due to changes with blah, it is recommended that
eblockinfo you foobar. See http://bugs.gentoo.org/123456.;
fi
But then, at what point would this information be echoed to the user?
It would have to be during the same pre-merge phase that the blocking
errors appear.
Yes, so instead of rushing to this list or the forums, they can do what
the message tells them and be on their way. The current messages are only
useful if you already understand how and why blocks happen, and how to
deal with them.
EXACTLY.
--
Neil Bothwick
If you got the words it does not mean you got the knowledge.
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
Oh, and one other thing. This should also be done for packages that
get moved to different categories, because I've been getting errors
like the following lately...
Calculating world dependencies |
emerge: there are no ebuilds to satisfy =dev-perl/PodParser-1.22.
(dependency required by mail-filter/spamassassin-3.1.0 [binary])
In this case, this simply means that dev-perl/PodParser has moved to a
different category, and the old spamassassin binary package couldn't
find it anymore, because it only knows about the PodParser in the old
category, not the new category. I checked the xorg-x11 ebuild, and it
was fine. It was the binary that still had problems, so I had to
re-merge it without --usepkg. If I recall correctly, I also would
have had to remove the file /var/cache/edb/remote_metadata.pickle,
but I started using NFS for my portage instead. That file has
information about packages, and their dependencies, so I looked in it,
and it had the wrong information. It had the dev-perl/PodParser
info, instead of the perl-core/PodParser info.
On 1/5/06, Neil Bothwick [EMAIL PROTECTED] wrote:
On Thu, 5 Jan 2006 16:08:04 +, Tom Martin wrote:
if_blocked_by('openmotif')
ewarn You must unmerge openmotif before proceeding
An error message like that doesn't really tell the user anything that he
doesn't already know.
It may not say anything you or I don't know, but from the number of posts
to this list about blockers, it would clearly help some people.
It would be more useful if some information was provided:
if blocked_by =x11-libs/openmotif-1.2.3 ; then
eblockinfo Due to changes with blah, it is recommended that
eblockinfo you foobar. See http://bugs.gentoo.org/123456.;
fi
But then, at what point would this information be echoed to the user?
It would have to be during the same pre-merge phase that the blocking
errors appear.
Yes, so instead of rushing to this list or the forums, they can do what
the message tells them and be on their way. The current messages are only
useful if you already understand how and why blocks happen, and how to
deal with them.
--
Neil Bothwick
If you got the words it does not mean you got the knowledge.
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
On 1/5/06, Trenton Adams [EMAIL PROTECTED] wrote: Calculating world dependencies | emerge: there are no ebuilds to satisfy =dev-perl/PodParser-1.22. (dependency required by mail-filter/spamassassin-3.1.0 [binary]) This is something that sometimes occurs when you get an out-of-sync portage tree (you are syncing at the same time as the mirror is updating). The fix is to just emerge --sync again. It can also happen if you use NFS for portage but do not keep the cache up-to-date. re-merge it without --usepkg. If I recall correctly, I also would have had to remove the file /var/cache/edb/remote_metadata.pickle, The portage cache should be updated automatically at the end of every sync. So no, removing this file would not be necessary. but I started using NFS for my portage instead. That file has information about packages, and their dependencies, so I looked in it, and it had the wrong information. Are you also using NFS for /var/cache/edb? If not, then you need to run emerge --metadata. -Richard PS: Please avoid top-posting here. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Neil Bothwick wrote:
| On Thu, 5 Jan 2006 11:10:38 +, Tom Martin wrote:
|
| To the portage developers, how could this be handled? Perhaps emerge
| could somehow figure out the reason for such a conflict, and then
| automatically unmerge the original package?
|
| Not really a question to the portage developers -- just unmerge
| openmotif (the blocker) and continue as normal.
|
| If would be nice is portage had a means for developers to handle these
| types of conflicts in the ebuild. A similar thing happened recently with
| xpdf/poppler, it happened with some FTP servers and the ftp-base package
| not long ago. I realise it is not possible to handle all conflicts, but
| with some instances, like this one, the conflict is expected. even if
| there were just a means to print a message if a package hits a block,
| something like
|
| if_blocked_by('openmotif')
| ewarn You must unmerge openmotif before proceeding
|
It would be icky to have to specify blocker logic/messages like that. There's
actually an open bug specifically about this issue:
http://bugs.gentoo.org/show_bug.cgi?id=79606
Basically, the problem lies in the fact that portage unmerges the previous
version _after_ the new version has been merged into place. One possible
solution would be to have a special feature that, when enabled, allows portage
to automatically unmerge an old version _before_ the new one is installed (with
protection against unmerging system packages of course).
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDvcR8/ejvha5XGaMRAnICAKDyA6xKtGb6mZXxS/mciU91Xvsz8QCeKidL
WRXlWMkvZ7plI2fNPlxO0TA=
=VAP2
-END PGP SIGNATURE-
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] package conflict on update
On Thu, 5 Jan 2006 16:32:20 -0700, Trenton Adams wrote:
something like
if_blocked_by('openmotif')
ewarn You must unmerge openmotif before proceeding
Yes, or as follows...
if_blocked_by('openmotif')
auto_unmerge('openmotif')
# continue with merge which should automatically be merging openmotif
anyhow.
Absolutely not! I don't want portage removing something I may be using at
the time without my saying so.
--
Neil Bothwick
I am in total control, but don't tell my wife.
signature.asc
Description: PGP signature
Re: [gentoo-user] package conflict on update
On 1/5/06, Richard Fish [EMAIL PROTECTED] wrote: On 1/5/06, Trenton Adams [EMAIL PROTECTED] wrote: Calculating world dependencies | emerge: there are no ebuilds to satisfy =dev-perl/PodParser-1.22. (dependency required by mail-filter/spamassassin-3.1.0 [binary]) This is something that sometimes occurs when you get an out-of-sync portage tree (you are syncing at the same time as the mirror is updating). The information in /usr/portage showed the new information, so I don't *think* that was the case here. The fix is to just emerge --sync again. It can also happen if you use NFS for portage but do not keep the cache up-to-date. re-merge it without --usepkg. If I recall correctly, I also would have had to remove the file /var/cache/edb/remote_metadata.pickle, The portage cache should be updated automatically at the end of every sync. So no, removing this file would not be necessary. Well for some reason it wasn't. Hmm, very odd. but I started using NFS for my portage instead. That file has information about packages, and their dependencies, so I looked in it, and it had the wrong information. Are you also using NFS for /var/cache/edb? If not, then you need to run emerge --metadata. No, but thanks for pointing that out though. I'll be sure to update the metadata next time. -Richard PS: Please avoid top-posting here. -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
