subject:"\[gentoo\-user\] Re\: depclean"

Grant Edwards  wrote:
> On 2021-07-29, Martin Vaeth  wrote:
>
>> The handbook contains the instruction how to do this: Put the packages
>> you need into the @world file.
> [...]
>
> Is this documented somewhere in the handbook?

I always supposed that it is documented in the handbook that you should
put the packages you need into the @world file.

But I haven't looked into the handbook since years, and might have learnt
this from somewhere else.

If it is not there, this is IMHO a bug in the handbook, and it would be
more than correct to open a corresponding bug against it.

[gentoo-user] Re: --depclean wants to remove openrc. Yikes!

Rich Freeman  wrote:
>
> First, it doesn't sound like qmail actually requires daemontools, but
> simply happens to include a daemontools service config.

My understanding is that qmali contains a "daemon" which does not
daemonize itself. To my knowledge, you can start such a thing
only with daemontools and systemd; probably the start-daemon of
openrc is not powerful enough for this.
But you are right that even in this case an || dependency on
daemontools and systemd is questionable.

(However, this does not solve the OPs problem, because unless
you are an expert and write a systemd-script you will then
*want* to install daemontools and actually put it into your
world file.)

> Second, it sounds like daemontools requires openrc to run.

No. As I mentioned in another post, systems can run even without
any init-system, and there are two frequent use cases for this:
dedicated servers and embedded systems, e.g. used for fileserving,
firewalling, as log servers, or whatever.
On such systems, you might want just a shell script which starts
the serving daemons (e.g. using daemontools), and nothing more.
Perhaps you actually want a dedicated mail server which runs
only qmail and daemontools...

Moreover, even if you want an additional init-system, this need
not necessarily be openrc, but might also be runit or some other
system not in portage (I cannot recall the names, currently).

By the same argument you have given above, a dependency of
daemontools on some other init system (even a || dependency)
is questionable.

[gentoo-user] Re: --depclean wants to remove openrc. Yikes!

2021-07-29 Thread Grant Edwards

On 2021-07-29, Martin Vaeth  wrote:

> Indeed, and it won't delete anything crucial for your system, and even
> more, it won't delete anything what you need. But you have to tell
> portage *what* you need and *what* is crucial for your system.
> The handbook contains the instruction how to do this: Put the packages
> you need into the @world file.

I've been using Gentoo for 20 years, and this is the first time I've
heard about the user being required to add the default init system
(e.g. openrc) to the world file to prevent it from being
"accidentally" removed by emerge --depclean.

Is this documented somewhere in the handbook?

-- 
Grant Edwards   grant.b.edwardsYow! Mary Tyler Moore's
  at   SEVENTH HUSBAND is wearing
  gmail.commy DACRON TANK TOP in a
   cheap hotel in HONOLULU!

[gentoo-user] Re: --depclean wants to remove openrc. Yikes!

Alan Mackenzie  wrote:
>
>> > Less clever people like me follow the handbook, and assume that
>> > packages in @system are protected.
>
>> And they are right to do so. And openrc is not in @system (at least not
>> in the profile which you have chosen), and certainly the handbook does
>> not claim the contrary.
>
> Now you're getting legalistic.

Yes, because gentoo follows simple rules, fortunately. One of the basic
rules it: Put the packages which you want to use into your world file.
You are ignoring these rules and complain.

> By @system I meant "the operating
> system", not what some legal text defines it to be.  That "the handbook
> does not claim the contrary" is poor reasoning.

No, it is not. You are making the wrong assumption that for some packages
the rules (to put into @world everything which you want to use) do not
apply. And you make this assumption on no basis from the handbook or
anything else. Just on a gut feeling what should be "the operating system",
completely ignoring that "the operating system" depends on what you
configure it to be.

>> No. Putting the packages which *you* want to use into world is
>> the most natural thing to do.
>
> It is unnatural to regard the operating system as a package.

The operating system is not the init system. The init system is clearly
a package, because you can have many alternatives for it. It fact,
depending on what you need your machine for, it might be fine to have no
init system at all.

> It is natural to assume the OS won't delete itself.

Indeed, and it won't delete anything crucial for your system, and even
more, it won't delete anything what you need. But you have to tell
portage *what* you need and *what* is crucial for your system.
The handbook contains the instruction how to do this: Put the packages
you need into the @world file.

>> You did. You would have done the same mistake if you would have
>> emerged systemd with the same profile without putting it into world,
>> and have configured your boot-loader to always load systemd [...]
>
> Now you're trying to win an argument because you know portage etc.,
> better than me.  And you're being pedantic and legalistic.

Yes, a computer program has to be pedantic and legalistic, because
it has to follow the rules. You are instead working with an
intentionally undefined notion of a "system" which you expect portage
to magically protect, although you intentionally leave it completely
unclear how portage should know what this system is.
There are two ways how a computer program can know this:

1. You tell it to the program.
2. The program tries to smart-ass you by analyzing your configuration
   and boot-up files and makig some guesses about it.

The solution 1 is the one chosen by gentoo. If you want 2, please use
some of many other available distributions - and then learn how to
workaround the problems if the program does the wrong guess in your
case.

> Quite simply
> I expect that an OS, including Gentoo, will not delete itself unless
> specifically asked by the user.  I'm not getting involved in arguments
> about details.

THat's exactly your mistake: You cannot expect a program to do some
vague unspecified things. (Except - see 2 above.)

> Gentoo is not perfect.

Nope. But the thing you complain about - the choice given to the user -
is an *advantage* of gentoo.

>> Oh, come on: You have misconfigured your system by making wrong
>> assumptions, and now you call yourself the victim.
>
> I did not misconfigure my system.  I followed the handbook

No, you did not follow the handbook. The handbook says to put the
packages you use into @world. Obviously, you did not.

> I'm glad you're not the person responsible for safety in the place I
> work.  There, specific steps are taken to avoid injury to people who make
> mistakes.  For example, there are bars to prevent people from falling out
> of windows, there are non-slip floor surfaces, and so on.

Unix is nothing for you. It has no safety belts, and never can have
without becoming something completely different.

>> Probably everybody should know that practically *every* package
>> can be a critical system file - it all depends on your setup.
>
> Please don't be like that.  You know damn well that only a few packages
> are critical

Yes. But *which* ones are depends on your setup.
Again, there are only the two possibilities:

1. You are responsible for your system - and in particular tell portage
   what your system actually is.
2. Portage is responsible for your system - then you have to be taken
   away any important choice about your main system, or portage tries to
   smart-ass you.

Again, if you want 2, go to another distribution. For gentoo, 2 would
be the death.

> The init system is absolutely needed for *every* system.  That there are
> alternatives is no excuse for Gentoo to delete it.

But not *all* installed init systems are absolutely needed for *every* system.
There is no excuse for a "cleanup" command to not remove most of

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

2021-07-29 Thread Rich Freeman

On Thu, Jul 29, 2021 at 4:24 PM Martin Vaeth  wrote:
>
> Rich Freeman  wrote:
> > The more I heard on this the more I tend to think that maybe it
> > should either not be in that virtual or that it should itself depend
> > on openrc/etc, or that qmail shouldn't depend on it.
>
> I strongly disagree. You have the same problem if you have any other
> init system installed, even if just for trying. Portage *cannot* know
> which init system you want to use, and, more general, which programs
> you want to use. You must tell portage. The way to do this is to put
> it into the world file.

You completely misunderstood my message then, because I completely
agree with everything you said and still maintain what I said.  It has
nothing to do with --depclean but with having correct dependencies.

First, it doesn't sound like qmail actually requires daemontools, but
simply happens to include a daemontools service config.  A package
shouldn't contain dependencies on a service manager unless it REALLY
only works with that one service manager (and that doesn't just mean
that nobody has bothered to set it up otherwise).  We don't stick
openrc dependencies in things simply because they weren't packaged
with systemd units, and so on.

Second, it sounds like daemontools requires openrc to run. So, if you
ARE using daemontools as your service manager, and portage uninstalls
openrc, then your system will break, because daemontools sounds like
it actually requires openrc.  That would make it a runtime dependency
(if true).

It isn't about portage trying to figure out which service manager
you're using.  It is about packages having the wrong dependencies.

-- 
Rich

[gentoo-user] Re: --depclean wants to remove openrc. Yikes!

Rich Freeman  wrote:
> The more I heard on this the more I tend to think that maybe it
> should either not be in that virtual or that it should itself depend
> on openrc/etc, or that qmail shouldn't depend on it.

I strongly disagree. You have the same problem if you have any other
init system installed, even if just for trying. Portage *cannot* know
which init system you want to use, and, more general, which programs
you want to use. You must tell portage. The way to do this is to put
it into the world file.

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

2021-07-27 Thread Michael Orlitzky

On Tue, 2021-07-27 at 21:58 +0100, Neil Bothwick wrote:
> 
> I was thinking more along the lines of a USE flag, as suggested first by
> Rich. Add a system-init flag to daemontools, defaulting to off, and have
> the virtual depend on daemontools[system-init] and the problem goes away
> with the only cost being the unnecessary requirement to rebuild
> daemontools.
> 

True, or it could be dropped from the virtual entirely by the same
reasoning: no one is using daemontools on purpose in 2021 (the last
release was in 2001).

Thinking about it, we should probably just mask all of the DJB packages
with a warning that "you are about to waste your time." The few
remaining users could package.unmask them. I've been meaning to replace
tinydns for a decade but the stupid servers just keep running
effortlessly.

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

2021-07-27 Thread Neil Bothwick

On Tue, 27 Jul 2021 16:32:04 -0400, Michael Orlitzky wrote:

> > Instead of continually beating on portage on this list, which will
> > achieve nothing more than a minor waste of electrons, you should be
> > focussing on getting the ebuilds fixed so that portage is no longer
> > given conflicting or incorrect information.  
> 
> In most cases this is good advice. The problem with djbdns/qmail is
> that they are abandoned upstream, and kept alive in Gentoo only by a
> patchwork of... well, patches.

I was thinking more along the lines of a USE flag, as suggested first by
Rich. Add a system-init flag to daemontools, defaulting to off, and have
the virtual depend on daemontools[system-init] and the problem goes away
with the only cost being the unnecessary requirement to rebuild
daemontools.

-- 
Neil Bothwick

The word 'Windows' is a word out of an old dialect of the Apaches.
It means: 'White man staring through glass-screen onto an hourglass...')

pgpahRBbccqv9.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

2021-07-27 Thread Michael Orlitzky

On Tue, 2021-07-27 at 21:18 +0100, Neil Bothwick wrote:
> 
> Instead of continually beating on portage on this list, which will
> achieve nothing more than a minor waste of electrons, you should be
> focussing on getting the ebuilds fixed so that portage is no longer given
> conflicting or incorrect information.

In most cases this is good advice. The problem with djbdns/qmail is
that they are abandoned upstream, and kept alive in Gentoo only by a
patchwork of... well, patches.

It would not -- independently -- be too much work to fix either package
to work without daemontools. But, since they are abandoned, there is
nowhere to send the fixes. That would add yet another patch to both
packages. Qmail is similar, but I know more about djbdns, so: for
example, net-dns/djbdns already applies SEVENTEEN PATCHES. And many of
them are quite large.

When a new security issue is found and a new patch is created or an
existing one changes, then all of a sudden we get conflicts. If we
apply the new one first, then (say) patches two through five might
apply cleanly, but patches six through eighteen will fail. Now we have
to manually rebase thirteen patches? That just will not happen, which
is why no one has fixed these two packages to work without daemontools
yet. The cost of additional patching is too high.

You should really just avoid both of them. This is an obscure problem
because no one chooses either djbdns or qmail since 2005.

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

2021-07-27 Thread Neil Bothwick

On Tue, 27 Jul 2021 20:02:07 +, Alan Mackenzie wrote:

> I know I'm repeating myself, but I don't think an OS should ever delete
> critical parts of itself unless explicitly requested by the user.
> Perhaps not even then, but I wouldn't go that far.  The fact that
> portage does this means IMHO that something has gone wrong.

Yes it has, but it is not portage. Portage is only doing what you have
told it, remove superfluous packages. By including daemontools in @world
you have told it, albeit unintentionally, that you want that init system,
making openrc superfluous.

What has gone wrong is that daemontools is considered an init system when
you have not installed it as such, so the issue is with either the
daemontools or the virtual.

Since you like quotes, here's another - "computers do what you tell them
to do, not what you ant them to do". This is a classic example of that,
portage is simply demonstrating the principle of GIGO.

Instead of continually beating on portage on this list, which will
achieve nothing more than a minor waste of electrons, you should be
focussing on getting the ebuilds fixed so that portage is no longer given
conflicting or incorrect information.

You shouldn't give computers conflicting instructions, looked what
happened when they did that with the HAL 9000 :-/

-- 
Neil Bothwick

"I heard Tasha Yar is the Enterprise's expert on Data entry."

pgpJJPsxBKGry.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

2021-07-27 Thread Alan Mackenzie

Hello, Rainer.

On Tue, Jul 27, 2021 at 11:28:05 +0200, Dr Rainer Woitok wrote:
> Alan,

> On Monday, 2021-07-26 19:01:21 +, you wrote:

> > ...
> > The warning was not very explicit.  An explicit warning would have said
> > "--depclean is capable of removing critical system packages".  As it
> > happened I didn't ignore the warning.  But some people might.

> > You seem to see nothing wrong with an OS being one keypress away from
> > destroying itself.  I do.

> You mentioned in an earlier post that you not  only got this warning for
> "openrc" but also for "nano".  I remember that after my first Gentoo in-
> stall ever,  I explicitly emerged  the packages  "vim"  (as an emergency
> fallback) and  -- more importantly --  "XEmacs" which were thus added to
> "@world".

Just as a matter of interest (I am an Emacs maintainer), are you still
using XEmacs?

> I then ran my very first  "emerge --ask --depclean"  and got that
> warning about "nano".  I do not remember the exact wording,  but --
> honestly -- I was startled.  Not very explicit?   When "emerge" is
> tell- ing me that removing "nano" might result in my system becoming
> unusable?  Or something to that effect?   Being a Gentoo novice then,
> I immediately replied "n", researched the webs, and then with a bit
> more knowledge and conscience I rerun "emerge --ask --depclean" and
> bravely typed "y".

> You were startled, too,  when reading that warning,  so where exactly is
> the problem?   Had I wanted a third editor  I'd have stuffed "nano" into
> "@world", but I didn't.  Since you want "openrc", you should.

The problem is that the documentation doesn't warn about the potential
loss of critical packages.  Only runtime messages which could easily
have scrolled off the screen.  Heck, when I first ran --depclean, there
were something like 220 packages to be removed.  It would be very easy
to have missed openrc.  (Shameless plug) only my kernel patch which
restores soft scroll enabled me to scroll back and see the warning.

The other problem is that, as (I think) Scott Adams, the creator of
Dilbert, has said, everybody is an idiot.  Just not 24 hours a day.  The
very fact that --depclean can remove the active init system means it
will catch somebody at a time when he is being an idiot.

I know I'm repeating myself, but I don't think an OS should ever delete
critical parts of itself unless explicitly requested by the user.
Perhaps not even then, but I wouldn't go that far.  The fact that
portage does this means IMHO that something has gone wrong.  Maybe
portage is too complicated, and people aren't aware of the lack of
safety catches.

> And yes,  some people tend to ignore warnings.   In particular, if there
> are just too many of them.

Yes.  I wonder just how many people really do read the "Waschzettel"
which accompanies all pharmaceuticals in Germany?  It takes some
commitment and patience to do so, but might be very important.

> I remember when back in the old days plenty of sources suggested to
> put  "alias rm='rm -i'"  into one's profile.   I always objected to
> this,  because you'd get so used to typing "y" to the plethora of
> questions  that you'd have  an excellent chance  to miss the one file
> which would have been worth retaining.

> So the most important rule  when working  with computers  still is "Read
> carefully, think carefully, then type carefully".  More warnings, bigger
> fonts or red colour simply don't cut it.  Or are you skimming your "gcc"
> compilation logs  after doing your weekly Gentoo upgrade for every warn-
> ing in order  to then check  the source code  to see whether  or not you
> should do anything about it?  I don't.

OK.  Respectfully, I think I disagree with you here.  Who'd have thought
it?  Two Gentoo users disagreeing about something.  ;-)

> My two cents ...

Much appreciated, thanks.

> Sincerely,
>   Rainer

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

2021-07-27 Thread Dr Rainer Woitok

Alan,

On Monday, 2021-07-26 19:01:21 +, you wrote:

> ...
> The warning was not very explicit.  An explicit warning would have said
> "--depclean is capable of removing critical system packages".  As it
> happened I didn't ignore the warning.  But some people might.
> 
> You seem to see nothing wrong with an OS being one keypress away from
> destroying itself.  I do.

You mentioned in an earlier post that you not  only got this warning for
"openrc" but also for "nano".  I remember that after my first Gentoo in-
stall ever,  I explicitly emerged  the packages  "vim"  (as an emergency
fallback) and  -- more importantly --  "XEmacs" which were thus added to
"@world".   I then ran my very first  "emerge --ask --depclean"  and got
that warning about "nano".  I do not remember the exact wording,  but --
honestly -- I was startled.  Not very explicit?   When "emerge" is tell-
ing me that removing "nano" might result in my system becoming unusable?
Or something to that effect?   Being a Gentoo novice then, I immediately
replied "n", researched the webs, and then with a bit more knowledge and
conscience I rerun "emerge --ask --depclean" and bravely typed "y".

You were startled, too,  when reading that warning,  so where exactly is
the problem?   Had I wanted a third editor  I'd have stuffed "nano" into
"@world", but I didn't.  Since you want "openrc", you should.

And yes,  some people tend to ignore warnings.   In particular, if there
are just too many of them.   I remember when back in the old days plenty
of sources suggested to put  "alias rm='rm -i'"  into one's profile.   I
always objected to this,  because you'd get so used to typing "y" to the
plethora of questions  that you'd have  an excellent chance  to miss the
one file which would have been worth retaining.

So the most important rule  when working  with computers  still is "Read
carefully, think carefully, then type carefully".  More warnings, bigger
fonts or red colour simply don't cut it.  Or are you skimming your "gcc"
compilation logs  after doing your weekly Gentoo upgrade for every warn-
ing in order  to then check  the source code  to see whether  or not you
should do anything about it?  I don't.

My two cents ...

Sincerely,
  Rainer

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

2021-07-26 Thread Rich Freeman

On Mon, Jul 26, 2021 at 3:19 PM Alan Mackenzie  wrote:
>
> How would I track down the Gentoo maintainer?
>

So, first thing to do is look in the repository at the metadata.xml
file in the package directory.

In this case it only lists the base-system project and doesn't list
any individual maintainers.  You could try looking up the project on
the wiki:
https://wiki.gentoo.org/wiki/Project:Base

However, you're going to find a lot of people.  You could email the
email address on the wiki page, or try asking in that project IRC
channel.

If that doesn't get you far (these sorts of projects often are a
little disorganized since there are so many packages in them), then
I'd look at the commit history:
https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-process/daemontools

(or you can run git whatchanged . from inside that directory in a git clone)

My first guess of an individual to talk to would be sam@g.o, since he
has done commits related to the actual package itself looking at the
log.  Things like stabilization commits or people touching a package
because they were working on something somewhat related aren't ideal
contacts, since they probably aren't directly involved with the
package.

If you're on IRC I'd check out #base-system there though, and maybe
ask in general or ping sam if he's around.

I realize this is a bit roundabout, but one thing I do want to do is
teach you to fish, and also make you not too afraid to talk to a
package maintainer.  The trick is to find the person who is most
likely to care about the issue because they're most likely to identify
the right sort of fix.

If you get really stuck please do let me know and I can try to help a
bit.  The more I heard on this the more I tend to think that maybe it
should either not be in that virtual or that it should itself depend
on openrc/etc, or that qmail shouldn't depend on it.  However, I am
not directly involved in those packages and there could be more to the
story.  That is why it is good to talk to those directly involved.

-- 
Rich

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

2021-07-26 Thread Alan Mackenzie

Hello, Rich.

On Sun, Jul 25, 2021 at 15:54:25 -0400, Rich Freeman wrote:
> On Sun, Jul 25, 2021 at 2:05 PM Alan Mackenzie  wrote:

> > OK, so you're clever and you know this.  You know to do the
> > couter-intuitive thing of putting @system packages into @world.  Less
> > clever people like me follow the handbook, and assume that packages in
> > @system are protected.  Putting init-systems into @world is an unnatural
> > thing to do, and must be construed as a workaround for deficiencies in
> > portage.

> I think you're really conflating the package manager with how some
> virtuals/ebuilds are configured.  Portage shouldn't have
> service-manager-specific functionality.  Nor should it do things like
> never uninstall things that packages say aren't needed just in case
> you might still be using them, when you run it with --depclean which
> basically is supposed to have it remove the stuff that isn't needed.

I don't think portage should ever uninstall the active init system, or
other crucial parts of the system, unless explicitly requested by the
user.  I think that would be poor design if it were deliberate.  People
make mistakes, and systems should take that into account.

> All protage does is follow the dependencies.

> I think there is room for discussing whether daemontools should be
> treated as a service manager by default.  I've never used it and can't
> speak to how it is typically used.  You might want to talk to the
> maintainers of it to get their thoughts.

How would I track down the Gentoo maintainer?

> > No, I did not make that mistake.  I simply assumed, not entirely
> > consciously, that Gentoo would not destroy my system without me
> > specifically asking it to.

> It isn't like uninstalling openrc is going to "destroy your system".
> Worst case you could always just pass init=/bin/bash or whatever to
> the kernel and just reinstall it.  Granted, it wouldn't really be
> welcome behavior.

> > It would be saner still to be kept in the system file (whatever that
> > might be).

> I suppose you might not care to hear that I've advocated a few times
> that the "system file" should disappear entirely and no packages
> should get special treatment.  :)  Granted, that has more to do with
> how assumed dependencies work in the repository.  I don't really have
> a problem with confirmation before removing certain packages because
> reinstalling them can be quite painful.  The service manager actually
> is one of the easier ones to fix.  If you break the ability to
> bootstrap gcc/etc that can be a real bugger to fix.

:-)  I suppose I'd be in favour of some sort of "are you really sure?"
protections for things like gcc and python, too.

> Really though posting on this list and successfully winning every
> argument with everybody who replies 

It's clear that that's not going to happen.  ;-)

>  is going to do zero to change this behavior, because it is
> unlikely that anybody involved in this particular issue reads this
> list.  It would make more sense to chat with the daemontools
> maintainer and get their thoughts on how the virtual ought to be
> configured as a starting point.  You could always try for a second
> opinion/etc if that doesn't work.  Plus the conversation would
> probably help you understand what their thinking was.

That's an excellent idea.  This feature is not going to hurt me any
more, because I know about it now.  I'm concerned it could hurt other
people in the future.

> -- 
> Rich

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

2021-07-26 Thread Alan Mackenzie

Hello, Martin.

On Sun, Jul 25, 2021 at 22:32:10 -, Martin Vaeth wrote:
> Alan Mackenzie  wrote:

> > On Sun, Jul 25, 2021 at 16:18:25 -, Martin Vaeth wrote:

> >> Portage *cannot* know unless you tell it. The way to tell portage that
> >> a package is crucial for *you* is to put it into the world file (or
> >> into some set which is in your world file).

> > OK, so you're clever and you know this. You know to do the
> > couter-intuitive thing of putting @system packages into @world.

> No, I am doing the intuitive thing, and put *that particular*
> service-manager(s) which is crucial for my system in world.

You're being clever again and, perhaps unconsciously, being disdainful of
the less clever or experienced.  It's a reasonable expectation that an
operating system won't delete itself.  Gentoo doesn't always meet that
expectation.  You don't seem to see anything wrong with that.  

> > Less clever people like me follow the handbook, and assume that
> > packages in @system are protected.

> And they are right to do so. And openrc is not in @system (at least not
> in the profile which you have chosen), and certainly the handbook does
> not claim the contrary.

Now you're getting legalistic.  By @system I meant "the operating
system", not what some legal text defines it to be.  That "the handbook
does not claim the contrary" is poor reasoning.  If anything surprising
and painful is liable to happen, the handbook should explicitly point it
out.

> Your assumption that all packages which are in stage3 are also in
> @system is just plain wrong. It would actually be horrible if that
> would be the case.

> > Putting init-systems into @world is an unnatural thing to do

> No. Putting the packages which *you* want to use into world is
> the most natural thing to do.

It is unnatural to regard the operating system as a package.  It is
natural to assume the OS won't delete itself.  I'm unaware of any other
non-joke OS's which delete themselves without being asked.

[  ]

> > No, I did not make that mistake.

> You did. You would have done the same mistake if you would have
> emerged systemd with the same profile without putting it into world,
> and have configured your boot-loader to always load systemd:
> In that case, systemd would be critical to your system and openrc is
> completely superfluous.

> Why should you expect that systemd will not get removed in the above
> situation if you have not put it into world?
> And if you do not expect that: Why should you expect that this is
> different for openrc?
> Well, you do, because you obviously falsely assumed that you are
> using an openrc profile or something similar which let openrc
> magically make a "special" package for you in contrast to systemd.

Now you're trying to win an argument because you know portage etc.,
better than me.  And you're being pedantic and legalistic.  Quite simply
I expect that an OS, including Gentoo, will not delete itself unless
specifically asked by the user.  I'm not getting involved in arguments
about details.

Gentoo is not perfect.

[  ]

> > Fine for a very clever person, not so much for the rest of us.  I
> > installed my Gentoo in accordance with the handbook (as of 2017), and
> > I don't recall any suggestion of putting critical system packages
> > into the world file.

> I am sure that there is written something that you should put all
> packages which you want to use into the world file. And BTW, I am also
> sure that there is nothing written like "do not do this for @system
> packges".

No reasonable user is going to assume the OS will delete itself.  Very
many will regard the OS as something into which one installs packages,
not as a package itself.  There was nothing in the handbook to contradict
this natural view.

[  ]

> >> Except for the warning that you should read *very carefully* through
> >> the list of packages which are going to be removed.

> > That looks more like a "cover your backside" warning than a real
> > warning

> This is gentoo - a distribution which explicitly never hinders you to
> shoot yourself in the foot. And you really think that if there is even
> an explicit warning you should ignore it?

The warning was not very explicit.  An explicit warning would have said
"--depclean is capable of removing critical system packages".  As it
happened I didn't ignore the warning.  But some people might.

You seem to see nothing wrong with an OS being one keypress away from
destroying itself.  I do.  So our discussion is bound to be somewhat at
cross purposes.

> > - one that transfers the responsibility from the perpetrators of an
> > unsafe system to the victims.

> Oh, come on: You have misconfigured your system by making wrong
> assumptions, and now you call yourself the victim.

I did not misconfigure my system.  I followed the handbook, which did
nothing to correct what you call "wrong assumptions".  I am not a victim,
thankfully, but might easily have become one.  I have taken

[gentoo-user] Re: --depclean wants to remove openrc. Yikes!

2021-07-25 Thread Martin Vaeth

Alan Mackenzie  wrote:
>
> On Sun, Jul 25, 2021 at 16:18:25 -, Martin Vaeth wrote:
>
>> Portage *cannot* know unless you tell it. The way to tell portage that
>> a package is crucial for *you* is to put it into the world file (or
>> into some set which is in your world file).
>
> OK, so you're clever and you know this. You know to do the
> couter-intuitive thing of putting @system packages into @world.

No, I am doing the intuitive thing, and put *that particular*
service-manager(s) which is crucial for my system in world.

> Less clever people like me follow the handbook, and assume that packages in
> @system are protected.

And they are right to do so. And openrc is not in @system (at least not
in the profile which you have chosen), and certainly the handbook does
not claim the contrary.
Your assumption that all packages which are in stage3 are also in
@system is just plain wrong. It would actually be horrible if that
would be the case.

> Putting init-systems into @world is an unnatural thing to do

No. Putting the packages which *you* want to use into world is
the most natural thing to do. If I would like to run a pure systemd
system or a pure runit system, I would be very unhappy, if I would
be forced to keep openrc, only because some guy decided that the
package manager has to know better what I want than me.

>> The mistake you made is to assume that the profile
>> profiles/default/linux/amd64/17.1/desktop (or whichever profile you
>> use) is an openrc-specific profile. [...]
>
> No, I did not make that mistake.

You did. You would have done the same mistake if you would have
emerged systemd with the same profile without putting it into world,
and have configured your boot-loader to always load systemd:
In that case, systemd would be critical to your system and openrc is
completely superfluous.

Why should you expect that systemd will not get removed in the above
situation if you have not put it into world?
And if you do not expect that: Why should you expect that this is
different for openrc?
Well, you do, because you obviously falsely assumed that you are
using an openrc profile or something similar which let openrc
magically make a "special" package for you in contrast to systemd.

> I simply assumed, not entirely consciously, that Gentoo would not
> destroy my system without me specifically asking it to.

With that logic, portage must *never* unmerge *any* package, as the
systemd example given above shows: After unmerging systemd, the system
gets broken.
Portage is not here to hold your hand. If you make some wrong assumptions
what is in @system, this is *your* problem.

>> One could make also openrc, runit, daemontool profiles, but this
>> would lead to an explosion of the number of profiles (for various
>> architectures and other variants like desktop, hardened, ...),
>> and probably the only thing these profiles would do would be to
>> pull in the init system itself. It is much saner to keep this in
>> the world file.
>
> It would be saner still to be kept in the system file (whatever that
> might be).

Yes, for an openrc profile if it existed. No, for the systemd profile.
And *certainly no* for a more generic profile.

> Fine for a very clever person, not so much for the rest of us.  I
> installed my Gentoo in accordance with the handbook (as of 2017), and I
> don't recall any suggestion of putting critical system packages into the
> world file.

I am sure that there is written something that you should put all
packages which you want to use into the world file. And BTW, I am also
sure that there is nothing written like "do not do this for @system packges".
In fact, the @system set can change and already has changed in the past,
and it is essentially only driven by the needs for a live cd and to
simplify the life of ebuild authors slightly.

> Why not just put ALL system packages into the world file?

The world file is completely your responsibility.
And again, openrc is not a system package (for your profile).
And that the package is critical for *your* setup means nothing.
For other setups the presence of ssh or of some special driver is
crucial. If all these would have to be put into @system, we would
have a very large @system set.
In fact, the aim of @system is to be as small as possible, and its
main intention is that ebuilds need not DEPEND on system packages.
That there are ebuilds which depend on openrc should have given
you a hint already, that openrc is a bad candidate for a @system
package.

>> Except for the warning that you should read *very carefully* through
>> the list of packages which are going to be removed.
>
> That looks more like a "cover your backside" warning than a real warning

This is gentoo - a distribution which explicitly never hinders you to
shoot yourself in the foot. And you really think that if there is even
an explicit warning you should ignore it?

> - one that transfers the responsibility from the perpetrators of an
> unsafe system to the victims.

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

2021-07-25 Thread Rich Freeman

On Sun, Jul 25, 2021 at 2:05 PM Alan Mackenzie  wrote:
>
> OK, so you're clever and you know this.  You know to do the
> couter-intuitive thing of putting @system packages into @world.  Less
> clever people like me follow the handbook, and assume that packages in
> @system are protected.  Putting init-systems into @world is an unnatural
> thing to do, and must be construed as a workaround for deficiencies in
> portage.

I think you're really conflating the package manager with how some
virtuals/ebuilds are configured.  Portage shouldn't have
service-manager-specific functionality.  Nor should it do things like
never uninstall things that packages say aren't needed just in case
you might still be using them, when you run it with --depclean which
basically is supposed to have it remove the stuff that isn't needed.

All protage does is follow the dependencies.

I think there is room for discussing whether daemontools should be
treated as a service manager by default.  I've never used it and can't
speak to how it is typically used.  You might want to talk to the
maintainers of it to get their thoughts.

> No, I did not make that mistake.  I simply assumed, not entirely
> consciously, that Gentoo would not destroy my system without me
> specifically asking it to.

It isn't like uninstalling openrc is going to "destroy your system".
Worst case you could always just pass init=/bin/bash or whatever to
the kernel and just reinstall it.  Granted, it wouldn't really be
welcome behavior.

> It would be saner still to be kept in the system file (whatever that
> might be).

I suppose you might not care to hear that I've advocated a few times
that the "system file" should disappear entirely and no packages
should get special treatment.  :)  Granted, that has more to do with
how assumed dependencies work in the repository.  I don't really have
a problem with confirmation before removing certain packages because
reinstalling them can be quite painful.  The service manager actually
is one of the easier ones to fix.  If you break the ability to
bootstrap gcc/etc that can be a real bugger to fix.

Really though posting on this list and successfully winning every
argument with everybody who replies is going to do zero to change this
behavior, because it is unlikely that anybody involved in this
particular issue reads this list.  It would make more sense to chat
with the daemontools maintainer and get their thoughts on how the
virtual ought to be configured as a starting point.  You could always
try for a second opinion/etc if that doesn't work.  Plus the
conversation would probably help you understand what their thinking
was.

-- 
Rich

Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!

2021-07-25 Thread Alan Mackenzie

Hello, Martin.

On Sun, Jul 25, 2021 at 16:18:25 -, Martin Vaeth wrote:
> Alan Mackenzie  wrote:
> > On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote:

> >> Well, it's not installed on my new system. I doubt it's installed on any
> >> new-ish gentoo-gnome systems. So openrc itself can't be critical.

> > Must you be so objectionably pedantic?  It is surely clear that I was
> > using "openrc" as a metasyntactic variable for "the current init
> > system".  If it wasn't, apologies.

[  ]

> Portage *cannot* know unless you tell it. The way to tell portage that
> a package is crucial for *you* is to put it into the world file (or
> into some set which is in your world file).

OK, so you're clever and you know this.  You know to do the
couter-intuitive thing of putting @system packages into @world.  Less
clever people like me follow the handbook, and assume that packages in
@system are protected.  Putting init-systems into @world is an unnatural
thing to do, and must be construed as a workaround for deficiencies in
portage.

> The mistake you made is to assume that the profile
> profiles/default/linux/amd64/17.1/desktop (or whichever profile you
> use) is an openrc-specific profile.  It is not: It is the generic
> profile for any init system. And it is a *good* thing that the basic
> profiles do not force an init-system upon you which you do not want to
> use.

No, I did not make that mistake.  I simply assumed, not entirely
consciously, that Gentoo would not destroy my system without me
specifically asking it to.

> The systemd init system has its own profile, but only because systemd
> is not only an init system, and it is therefore natural to have more
> things in that profile than just the init system itself.

> One could make also openrc, runit, daemontool profiles, but this
> would lead to an explosion of the number of profiles (for various
> architectures and other variants like desktop, hardened, ...),
> and probably the only thing these profiles would do would be to
> pull in the init system itself. It is much saner to keep this in
> the world file.

It would be saner still to be kept in the system file (whatever that
might be).

> (Once it has become standard to "combine" profiles from several
> smaller profiles, I would suggest to have such openrc, ... profiles
> as well, but although this is technically possible, already, it is
> hardly documented and certainly cannot be considered at standard.)

> >> It may be critical for *your* system ... :-)

> > Just as systemd is for your system.

> And for that reason, I have systemd in my world file. (Together with
> openrc, BTW, because I want to be able to toggle between init systems
> for the case that one is not running for whatever reason.)

Fine for a very clever person, not so much for the rest of us.  I
installed my Gentoo in accordance with the handbook (as of 2017), and I
don't recall any suggestion of putting critical system packages into the
world file.  Why not just put ALL system packages into the world file?

> > If you'd installed daemontools you would also have come within
> > a keystroke of destroying your system

> Nope.

> > as I did, on attempting emerge --depclean.  You would have received no
> > warning of any kind on installing the package, and there would be no
> > documentation brought to your attention about the potential catastrophe.

> Except for the warning that you should read *very carefully* through
> the list of packages which are going to be removed.

That looks more like a "cover your backside" warning than a real warning
- one that transfers the responsibility from the perpetrators of an
unsafe system to the victims.  There is no specific warning that
--depclean can remove critical system files.  Probably there should be.

> Surprises in misconfigured systems can occur. But the problem is
> not the system but the misconfiguration - in your case the missing
> world entry.

Not a bit of it.  The problem is the lack of documentation in the
handbook to perform this counter-intuitive step.

> > No, my problem is caused by Gentoo allowing its package system, without
> > me doing anything strange

> Relying on openrc as a critical part of the system and not telling
> portage about it *is* something strange.

Oh, come on!  Relying on Gentoo not to commit suicide by deleting
critical system packages is strange?  Even you probably started out doing
this when you first installed Gentoo.  There is nothing in the handbook
to say to do this.

> > Nobody here has made any suggestions as to how this situation might be
> > prevented in the future

> The correct suggestion is to inform portage about your intention.
> Maybe add a paragraph to the handbook about doing so (as perhaps
> new users do no even know that they are probably using openrc).
> Gentoo relies on informed users, not on "fixing" things over the
> head of users.

Any system that comes within one keypress of destruction, when the user
hasn't specifically

[gentoo-user] Re: --depclean wants to remove openrc. Yikes!

2021-07-25 Thread Martin Vaeth

Neil Bothwick  wrote:
>
> It seems that Rich's suggestion has the most merit, add a USE flag to
> daemontools to indicate that it is intended to be your service manager,
> and have the virtual require that flag.

If you want to solve it by a USE-flag, add this flag to
virtual/service-manager. One could even make it an expand-USE flag,
containing the service manager(s) you want to use. (And have a
restriction that at least one use flag must be selected.)

This has not only the advantage that a re-emerge of a virtual costs
practically no time when you want to change it, you can also say
that you consider more than one service manager crucial for your system.

Actually, not only here but in many || cases some USE-flags would not
hurt.

That being said, the world file has actually exactly the purpose of
informing portage about the packages you want to keep, so doing this
in a virtual is overkill, and actually there is nothing wrong with
the current setup. Maybe more user information in the handbook would
be a good thing. Gentoo relies on informed users.

[gentoo-user] Re: --depclean wants to remove openrc. Yikes!

2021-07-25 Thread Martin Vaeth

Alan Mackenzie  wrote:
> On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote:
>
>> Well, it's not installed on my new system. I doubt it's installed on any
>> new-ish gentoo-gnome systems. So openrc itself can't be critical.
>
> Must you be so objectionably pedantic?  It is surely clear that I was
> using "openrc" as a metasyntactic variable for "the current init
> system".  If it wasn't, apologies.

It is the variable for *your* current init system. Like others have
systemd, runit, or daemontools as *their* current init system.
Portage *cannot* know unless you tell it. The way to tell portage that
a package is crucial for *you* is to put it into the world file
(or into some set which is in your world file).

The mistake you made is to assume that the profile
profiles/default/linux/amd64/17.1/desktop
(or whichever profile you use) is an openrc-specific profile.
It is not: It is the generic profile for any init system. And it is
a *good* thing that the basic profiles do not force an init-system
upon you which you do not want to use.

The systemd init system has its own profile, but only because systemd
is not only an init system, and it is therefore natural to have more
things in that profile than just the init system itself.

One could make also openrc, runit, daemontool profiles, but this
would lead to an explosion of the number of profiles (for various
architectures and other variants like desktop, hardened, ...),
and probably the only thing these profiles would do would be to
pull in the init system itself. It is much saner to keep this in
the world file.

(Once it has become standard to "combine" profiles from several
smaller profiles, I would suggest to have such openrc, ... profiles
as well, but although this is technically possible, already, it is
hardly documented and certainly cannot be considered at standard.)

>> It may be critical for *your* system ... :-)
>
> Just as systemd is for your system.

And for that reason, I have systemd in my world file. (Together with
openrc, BTW, because I want to be able to toggle between init systems
for the case that one is not running for whatever reason.)

> If you'd installed daemontools you would also have come within
> a keystroke of destroying your system

Nope.

> as I did, on attempting emerge --depclean.  You would have received no
> warning of any kind on installing the package, and there would be no
> documentation brought to your attention about the potential catastrophe.

Except for the warning that you should read *very carefully* through
the list of packages which are going to be removed.

Surprises in misconfigured systems can occur. But the problem is
not the system but the misconfiguration - in your case the missing
world entry.

> No, my problem is caused by Gentoo allowing its package system, without
> me doing anything strange

Relying on openrc as a critical part of the system and not telling
portage about it *is* something strange.

> Nobody here has made any suggestions as to how this situation might be
> prevented in the future

The correct suggestion is to inform portage about your intention.
Maybe add a paragraph to the handbook about doing so (as perhaps
new users do no even know that they are probably using openrc).
Gentoo relies on informed users, not on "fixing" things over the
head of users.

Your suggestion would go into the wrong direction: It means that if
a user install a package which depends on daemontools, and eventually
this dependency gets dropped, or the user removes the package again,
portage would refuse to depclean daemontools, only because it is an
alternative package satisfying a system dependency, and therefore -
according to your suggestion - portage "thinks" that you *might* rely
critically on it without telling portage explicitly that you do so.
It is one of the big advantages of gentoo that it does not have the
"system knows better than the user"-attitude. (Unfortunately, for some
other packages this is not true, but let us not discuss that here.)

Re: [gentoo-user] Re: --depclean and sys-devel/gcc

2018-08-10 Thread allan gottlieb

On Fri, Aug 10 2018, Nikos Chantziaras wrote:

> On 10/08/18 17:01, allan gottlieb wrote:
>> If I now upgrade with
>>
>>  gcc-config x86_64-pc-linux-gnu-7.3.0
>>  env-update && source /etc/profile
>>  emerge --ask --oneshot sys-devel/libtool
>>
>> must I do a world update --emptytree as when converting to the 13.0
>> profile.
>
> It's recommended, but not something you have to do immediately. It's
> best to do it when you don't need the machine (like overnight), but if
> you happen to be using it while the world rebuild is going on, use
> these in your make.conf:
>
> PORTAGE_NICENESS=19
> PORTAGE_IONICE_COMMAND="sh -c \"schedtool -D \${PID}; ionice -c 3 -p 
> \${PID}\""
>
> (Make sure sys-process/schedtool is installed.)
>
> This makes sure the emerge process does not slow down your normal use
> of the machine.

Thank you.  I started my backup machine on the world update.
Will do the main machine afterward.
allan

[gentoo-user] Re: --depclean and sys-devel/gcc

2018-08-10 Thread Nikos Chantziaras


On 10/08/18 17:01, allan gottlieb wrote:

If I now upgrade with

 gcc-config x86_64-pc-linux-gnu-7.3.0
 env-update && source /etc/profile
 emerge --ask --oneshot sys-devel/libtool

must I do a world update --emptytree as when converting to the 13.0
profile.


It's recommended, but not something you have to do immediately. It's 
best to do it when you don't need the machine (like overnight), but if 
you happen to be using it while the world rebuild is going on, use these 
in your make.conf:


PORTAGE_NICENESS=19
PORTAGE_IONICE_COMMAND="sh -c \"schedtool -D \${PID}; ionice -c 3 -p 
\${PID}\""


(Make sure sys-process/schedtool is installed.)

This makes sure the emerge process does not slow down your normal use of 
the machine.

[gentoo-user] Re: depclean confusion

2017-12-29 Thread Kai Krakow

Am Tue, 19 Dec 2017 23:43:35 +0200 schrieb Nikos Chantziaras:

> On 19/12/17 23:18, Walter Dnes wrote:
>>Finishing off an install, and running "emerge --depclean"
>> 
>> =
> Assigning files to packages...
>>   * In order to avoid breakage of link level dependencies, one or more
>>   * packages will not be removed. This can be solved by rebuilding the
>>   * packages that pulled them in.
>>   *
>>   *   sys-libs/db-5.3.28-r2 pulled in by:
>>   * sys-apps/iproute2-4.14.1-r1 needs libdb-5.3.so *
> Adding lib providers to graph...
>> =
>> 
>> 1) I've rebuilt iproute2
>> 
>> [ebuild   R] sys-apps/iproute2-4.14.1-r1::gentoo  USE="-atm -berkdb
>> -iptables -ipv6 -minimal (-selinux)" 0 KiB
> 
> Unmerge it anyway and then rebuild iproute2. It seems like an automagic
> dep. It should not be using db when the berkdb USE flag is not set.
> Since it does, it's a bug.

This is most of the times caused by configure scripts auto-detecting the 
presence of certain libs. Such behavior should be disabled and indicates 
a missing explicit disable/enable in the ebuild. You should report it.


> However, rebuilding it after unmerging db should fix it.
> 
> With that being said, do a "quickpkg sys-libs/db" first to get a tarball
> backup, just to be safe if you need to restore it.


-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: depclean confusion

2017-12-19 Thread Walter Dnes

On Tue, Dec 19, 2017 at 11:43:35PM +0200, Nikos Chantziaras wrote

> Unmerge it anyway and then rebuild iproute2. It seems like an automagic 
> dep. It should not be using db when the berkdb USE flag is not set. 
> Since it does, it's a bug.
> 
> However, rebuilding it after unmerging db should fix it.
> 
> With that being said, do a "quickpkg sys-libs/db" first to get a tarball 
> backup, just to be safe if you need to restore it.

  Thanks.  I unmerged iproute2 (notwithstanding the dire warning),
depcleaned, then "emerge -1 iproute2", followed by revdep-rebuild which
shows all-clear.  I've successfully rebooted stand-alone, and am now
finishing off the install.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

[gentoo-user] Re: depclean confusion

2017-12-19 Thread Nikos Chantziaras


On 19/12/17 23:18, Walter Dnes wrote:

   Finishing off an install, and running "emerge --depclean"

=

Assigning files to packages...

  * In order to avoid breakage of link level dependencies, one or more
  * packages will not be removed. This can be solved by rebuilding the
  * packages that pulled them in.
  *
  *   sys-libs/db-5.3.28-r2 pulled in by:
  * sys-apps/iproute2-4.14.1-r1 needs libdb-5.3.so
  *

Adding lib providers to graph...

=

1) I've rebuilt iproute2

[ebuild   R] sys-apps/iproute2-4.14.1-r1::gentoo  USE="-atm -berkdb -iptables 
-ipv6 -minimal (-selinux)" 0 KiB


Unmerge it anyway and then rebuild iproute2. It seems like an automagic 
dep. It should not be using db when the berkdb USE flag is not set. 
Since it does, it's a bug.


However, rebuilding it after unmerging db should fix it.

With that being said, do a "quickpkg sys-libs/db" first to get a tarball 
backup, just to be safe if you need to restore it.

[gentoo-user] Re: depclean portect a class of ebuilds ?

2015-03-17 Thread James

Bruce Schultz brulzki at gmail.com writes:

 emerge --depclean -p

case (1)
 EMERGE_DEFAULT_OPTS=--exclude gentoo-sources  @dev-java  
NOw this is strange. Today it only wants to delete a few packages:

All selected packages: =dev-lang/vala-0.26.2 =dev-java/junit-4.11
=dev-java/jmock-1.1.0-r2 =dev-java/qdox-1.12-r1 =dev-lang/vala-0.24.0-r1
=dev-java/jna-3.4.0 =dev-java/hamcrest-generator-1.3-r1
=dev-java/cglib-2.0.2-r2 =dev-java/byaccj-1.15-r1 =dev-lang/vala-0.20.1
=dev-java/swing-layout-1.0.4 =dev-java/javahelp-2.0.05_p63
=dev-java/hamcrest-core-1.3 =dev-java/jflex-1.4.3

Most are in the dev-java set. So I renames the set to DEVjava; same result.

case (2)
 I'm thinking something like the following might work
 
 EMERGE_DEFAULT_OPTS=--exclude \gentoo-sources  @DEVjava\  

emerge: error: Invalid Atom(s) in --exclude parameter: '@DEVjava' (only
package names and slot atoms (with wildcards) allowed)


case (3)
I dropped the gentoo-sources to focus in on using a set rulI think it is
closer. This one specifically fails:

EMERGE_DEFAULT_OPTS=--exclude  \ @DEVjava\   

same error message, so it does not like the set.


case (4)
EMERGE_DEFAULT_OPTS=--exclude  \DEVjava\   

This did not fail, but it give the big list, including the packages
listed in the set DEVjava


So this message seems to be telling me that sets are not supported,
back from when the lower-case, non-hyphenated syntax was tested:

emerge: error: Invalid Atom(s) in --exclude parameter: '@dev-java/*' (only
package names and slot atoms (with wildcards) allowed)

Any other ideas or comments are welcome.


James

Re: [gentoo-user] Re: depclean portect a class of ebuilds ?

2015-03-17 Thread Alan McKinnon

On 15/03/2015 02:25, James wrote:
 Neil Bothwick neil at digimed.co.uk writes:
 
 
 I'm not sure how to put everything dev-java into a set; so that 
 it will updated but not depclean out those packages.
 
 A set can be simply a list of packages in a file in /etc/portage/sets.
 
 
 Ok so I created this file (644): 
 /etc/portage/sets/dev-java
 
 I put a list of file in there, here are a few:
 dev-java/log4j
 dev-java/xpp2
 dev-java/xpp3
 dev-java/jaxme
 java-virtuals/stax-api
 snip
 
 I tried all sorts of --depclean  syntax variants but it did not protect the 
 files listed in the file from removal. I modified my make.conf like so:
 
 EMERGE_DEFAULT_OPTS=--exclude gentoo-sources @dev-java  
 
 
 Now every rendition of depclean usage just wants to remove these files.
 It feels like there is a working mechanism here, but I'm struggling
 to find the exact method to protect these files from depclean, not identify
 them form deep cleansing. What am I missing?


I'm not sure what you are trying to accomplish here - looks like you
want to stop portage from removing some stuff (per the subject line)?

Well that's easy - put them in world.
Or with sets, add the packages to a set called DEVjava and add that set
to world. Either emerge @DEVjava or manually add the set name to
/var/lib/portage/world_sets

Because that stuff is now in world, depclean will not touch it.

The --exclude syntax you are experimenting with is for installation of
packages, not removal. From the man page:

   --exclude ATOMS
  A space separated list of package names or slot atoms.
Emerge won't   install  any
  ebuild or binary package that matches any of the given
package atoms.


Any as you can see the only supported arguments are atoms, not set names

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Re: depclean portect a class of ebuilds ?

2015-03-17 Thread Neil Bothwick

On Tue, 17 Mar 2015 14:15:38 + (UTC), James wrote:

  EMERGE_DEFAULT_OPTS=--exclude gentoo-sources  @dev-java
 NOw this is strange. Today it only wants to delete a few packages:
 
 All selected packages: =dev-lang/vala-0.26.2 =dev-java/junit-4.11
 =dev-java/jmock-1.1.0-r2 =dev-java/qdox-1.12-r1 =dev-lang/vala-0.24.0-r1
 =dev-java/jna-3.4.0 =dev-java/hamcrest-generator-1.3-r1
 =dev-java/cglib-2.0.2-r2 =dev-java/byaccj-1.15-r1 =dev-lang/vala-0.20.1
 =dev-java/swing-layout-1.0.4 =dev-java/javahelp-2.0.05_p63
 =dev-java/hamcrest-core-1.3 =dev-java/jflex-1.4.3
 
 Most are in the dev-java set.

Did you emerge -n @dev-java? The whole suggestion of creating a set
depends on you adding it to world_sets? If you didn't do that, you wasted
your time creating the set.


-- 
Neil Bothwick

What is a free gift ? Aren't all gifts free?


pgpM2Dgp5PGpq.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: depclean portect a class of ebuilds ?

2015-03-15 Thread Neil Bothwick

On 15 March 2015 00:25:40 GMT+00:00, James wirel...@tampabay.rr.com wrote:
 Neil Bothwick neil at digimed.co.uk writes:
 
 
   I'm not sure how to put everything dev-java into a set; so that 
   it will updated but not depclean out those packages.
 
  A set can be simply a list of packages in a file in
 /etc/portage/sets.
 
 
 Ok so I created this file (644): 
 /etc/portage/sets/dev-java
 
 I put a list of file in there, here are a few:
 dev-java/log4j
 dev-java/xpp2
 dev-java/xpp3
 dev-java/jaxme
 java-virtuals/stax-api
 snip
 
 I tried all sorts of --depclean  syntax variants but it did not
 protect the 
 files listed in the file from removal. I modified my make.conf like
 so:
 
 EMERGE_DEFAULT_OPTS=--exclude gentoo-sources @dev-java  
 
 
 Now every rendition of depclean usage just wants to remove these
 files.
 It feels like there is a working mechanism here, but I'm struggling
 to find the exact method to protect these files from depclean, not
 identify
 them form deep cleansing. What am I missing?
 
 
 
 James

emerge - n @dev-java
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Re: depclean portect a class of ebuilds ?

2015-03-15 Thread Bruce Schultz



On 15 March 2015 10:25:40 AM AEST, James wirel...@tampabay.rr.com wrote:
Neil Bothwick neil at digimed.co.uk writes:


  I'm not sure how to put everything dev-java into a set; so that 
  it will updated but not depclean out those packages.

 A set can be simply a list of packages in a file in
/etc/portage/sets.


Ok so I created this file (644): 
/etc/portage/sets/dev-java

I put a list of file in there, here are a few:
dev-java/log4j
dev-java/xpp2
dev-java/xpp3
dev-java/jaxme
java-virtuals/stax-api
snip

I tried all sorts of --depclean  syntax variants but it did not protect
the 
files listed in the file from removal. I modified my make.conf like so:

EMERGE_DEFAULT_OPTS=--exclude gentoo-sources @dev-java  


Now every rendition of depclean usage just wants to remove these files.
It feels like there is a working mechanism here, but I'm struggling
to find the exact method to protect these files from depclean, not
identify
them form deep cleansing. What am I missing?


Does the --exclude list need to be quoted?

I'm thinking something like the following might work

EMERGE_DEFAULT_OPTS=--exclude \gentoo-sources @dev-java\  

Bruce

-- 
:b

[gentoo-user] Re: depclean portect a class of ebuilds ?

2015-03-14 Thread James

Neil Bothwick neil at digimed.co.uk writes:


  I'm not sure how to put everything dev-java into a set; so that 
  it will updated but not depclean out those packages.

 A set can be simply a list of packages in a file in /etc/portage/sets.


Ok so I created this file (644): 
/etc/portage/sets/dev-java

I put a list of file in there, here are a few:
dev-java/log4j
dev-java/xpp2
dev-java/xpp3
dev-java/jaxme
java-virtuals/stax-api
snip

I tried all sorts of --depclean  syntax variants but it did not protect the 
files listed in the file from removal. I modified my make.conf like so:

EMERGE_DEFAULT_OPTS=--exclude gentoo-sources @dev-java  


Now every rendition of depclean usage just wants to remove these files.
It feels like there is a working mechanism here, but I'm struggling
to find the exact method to protect these files from depclean, not identify
them form deep cleansing. What am I missing?



James

[gentoo-user] Re: depclean portect a class of ebuilds ?

2015-03-14 Thread James

Neil Bothwick neil at digimed.co.uk writes:


  Today, I have many many ugly and hacked java projects
  on my munge system. I have spend countless hours hacking
  at java; so I do not wish for any dev-java codes to be removed
  by --depclean, but the others can be cleaned up.

 Why not simply create a set containing all the ebuilds you are
 experimenting with?


I'm not sure how to put everything dev-java into a set; so that 
it will updated but not depclean out those packages.

Gotta quick example?  It's been a while since I used sets in portage


James

Re: [gentoo-user] Re: depclean portect a class of ebuilds ?

2015-03-14 Thread Mick

On Saturday 14 Mar 2015 23:03:26 James wrote:
 Neil Bothwick neil at digimed.co.uk writes:
   Today, I have many many ugly and hacked java projects
   on my munge system. I have spend countless hours hacking
   at java; so I do not wish for any dev-java codes to be removed
   by --depclean, but the others can be cleaned up.
  
  Why not simply create a set containing all the ebuilds you are
  experimenting with?
 
 I'm not sure how to put everything dev-java into a set; so that
 it will updated but not depclean out those packages.
 
 Gotta quick example?  It's been a while since I used sets in portage
 
 
 James

I don't use java, but assuming you know what packages you want to define 
separately for your java needs, have a look here for syntax:

http://wiki.gentoo.org/wiki//etc/portage/sets

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: depclean portect a class of ebuilds ?

2015-03-14 Thread Neil Bothwick

On Sat, 14 Mar 2015 23:03:26 + (UTC), James wrote:

  Why not simply create a set containing all the ebuilds you are
  experimenting with?  
 
 I'm not sure how to put everything dev-java into a set; so that 
 it will updated but not depclean out those packages.
 
 Gotta quick example?  It's been a while since I used sets in portage

A set can be simply a list of packages in a file in /etc/portage/sets.


-- 
Neil Bothwick

BBS: (n.) a system for connecting computers and exchanging gossip,
 facts, and uninformed speculation under false names.


pgppDtHOgz7X5.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: depclean asking to remove many perl

2012-05-11 Thread Nikos Chantziaras


On 11/05/12 17:39, Allan Gottlieb wrote:

A recent world update followed by depclean resulted in a request to
remove nearly 30 dev-perl packages (plus an old boost).

I don't use perl, but wonder what triggered this change.  I have not
changed any use flags.

My inclination is to let depclean have its way, but wanted to check here
first in case this looks suspicious to anyone.


Something dropped the perl dependency.  Same results here.  I let it 
remove it and there were no problems.

Re: [gentoo-user] Re: depclean asking to remove many perl

2012-05-11 Thread Allan Gottlieb

On Fri, May 11 2012, Nikos Chantziaras wrote:

 On 11/05/12 17:39, Allan Gottlieb wrote:
 A recent world update followed by depclean resulted in a request to
 remove nearly 30 dev-perl packages (plus an old boost).

 I don't use perl, but wonder what triggered this change.  I have not
 changed any use flags.

 My inclination is to let depclean have its way, but wanted to check here
 first in case this looks suspicious to anyone.

 Something dropped the perl dependency.  Same results here.  I let it
 remove it and there were no problems.

Thank you.

That was my conclusion as well.  I am letting depclean go as I type
this.

allan

[gentoo-user] Re: depclean stopped working


On 17/04/12 18:10, Alan McKinnon wrote:

On Tue, 17 Apr 2012 18:01:43 +0300
Nikos Chantziarasrea...@gmail.com  wrote:


emerge --depclean seems to have bugged out for me:

   * Dependencies could not be completely resolved due to
   * the following required packages not being installed:
   *
   *   =dev-libs/openssl-0.9.8* pulled in by:
   * app-emulation/vmware-workstation-8.0.2.591240
   *
   *   dev-libs/openssl:0.9.8 pulled in by:
   * www-client/google-chrome-19.0.1084.24_beta131971

It says to do a emerge --update --newuse --deep --with-bdeps=y
@world. Which is what I just did to begin with (and running it again
doesn't result in anything getting emerged.)

It also says:

   * Also, note that it may be necessary to manually uninstall
   * packages that no longer exist in the portage tree, since it may
   * not be possible to satisfy their dependencies.

However, dev-libs/openssl is installed and seems to be in the tree:

$ eix -e dev-libs/openssl
[I] dev-libs/openssl
   Available versions:
  (0.9.8) 0.9.8r (~)0.9.8s 0.9.8s-r1 0.9.8t 0.9.8u
  (0) 1.0.0d 1.0.0e (~)1.0.0e-r1 (~)1.0.0f 1.0.0f-r1
1.0.0g 1.0.0h **1.0.1
  {{bindist gmp kerberos rfc3779 sse2 static-libs test vanilla
zlib}} Installed versions:  0.9.8u(0.9.8)(22:32:12 12/03/12)(sse2
zlib -bindist -gmp -kerberos -test) 1.0.0h(22:33:20 12/03/12)(sse2
zlib -bindist -gmp -kerberos -rfc3779 -static-libs -test)




I think you should file a bug against www-client/google-chrome

It wants the exact version dev-libs/openssl:0.9.8 but the oldest in
portage is dev-libs/openssl:0.9.8r

Chances are the dev simply left off the version suffix by accident


That can't be it.  There's a wildcard at the end:

  =dev-libs/openssl-0.9.8*

which should match 0.9.8u.

[gentoo-user] Re: depclean stopped working


On 17/04/12 18:34, Nikos Chantziaras wrote:

On 17/04/12 18:10, Alan McKinnon wrote:

On Tue, 17 Apr 2012 18:01:43 +0300
Nikos Chantziarasrea...@gmail.com wrote:


emerge --depclean seems to have bugged out for me:

* Dependencies could not be completely resolved due to
* the following required packages not being installed:
*
* =dev-libs/openssl-0.9.8* pulled in by:
* app-emulation/vmware-workstation-8.0.2.591240
*
* dev-libs/openssl:0.9.8 pulled in by:
* www-client/google-chrome-19.0.1084.24_beta131971

It says to do a emerge --update --newuse --deep --with-bdeps=y
@world. Which is what I just did to begin with (and running it again
doesn't result in anything getting emerged.)

It also says:

* Also, note that it may be necessary to manually uninstall
* packages that no longer exist in the portage tree, since it may
* not be possible to satisfy their dependencies.

However, dev-libs/openssl is installed and seems to be in the tree:

$ eix -e dev-libs/openssl
[I] dev-libs/openssl
Available versions:
(0.9.8) 0.9.8r (~)0.9.8s 0.9.8s-r1 0.9.8t 0.9.8u
(0) 1.0.0d 1.0.0e (~)1.0.0e-r1 (~)1.0.0f 1.0.0f-r1
1.0.0g 1.0.0h **1.0.1
{{bindist gmp kerberos rfc3779 sse2 static-libs test vanilla
zlib}} Installed versions: 0.9.8u(0.9.8)(22:32:12 12/03/12)(sse2
zlib -bindist -gmp -kerberos -test) 1.0.0h(22:33:20 12/03/12)(sse2
zlib -bindist -gmp -kerberos -rfc3779 -static-libs -test)




I think you should file a bug against www-client/google-chrome

It wants the exact version dev-libs/openssl:0.9.8 but the oldest in
portage is dev-libs/openssl:0.9.8r

Chances are the dev simply left off the version suffix by accident


That can't be it. There's a wildcard at the end:

=dev-libs/openssl-0.9.8*

which should match 0.9.8u.


No wait, that's vmware. The chrome ebuild pulls a slot:

  dev-libs/openssl:0.9.8

This also matches correctly.  The 0.9.8 slot matches all those versions. 
 So no problem with that either.

Re: [gentoo-user] Re: depclean stopped working

2012-04-17 Thread Alan McKinnon

On Tue, 17 Apr 2012 18:41:55 +0300
Nikos Chantziaras rea...@gmail.com wrote:

 On 17/04/12 18:34, Nikos Chantziaras wrote:
  On 17/04/12 18:10, Alan McKinnon wrote:
  On Tue, 17 Apr 2012 18:01:43 +0300
  Nikos Chantziarasrea...@gmail.com wrote:
 
  emerge --depclean seems to have bugged out for me:
 
  * Dependencies could not be completely resolved due to
  * the following required packages not being installed:
  *
  * =dev-libs/openssl-0.9.8* pulled in by:
  * app-emulation/vmware-workstation-8.0.2.591240
  *
  * dev-libs/openssl:0.9.8 pulled in by:
  * www-client/google-chrome-19.0.1084.24_beta131971
 
  It says to do a emerge --update --newuse --deep --with-bdeps=y
  @world. Which is what I just did to begin with (and running it
  again doesn't result in anything getting emerged.)
 
  It also says:
 
  * Also, note that it may be necessary to manually uninstall
  * packages that no longer exist in the portage tree, since it may
  * not be possible to satisfy their dependencies.
 
  However, dev-libs/openssl is installed and seems to be in the
  tree:
 
  $ eix -e dev-libs/openssl
  [I] dev-libs/openssl
  Available versions:
  (0.9.8) 0.9.8r (~)0.9.8s 0.9.8s-r1 0.9.8t 0.9.8u
  (0) 1.0.0d 1.0.0e (~)1.0.0e-r1 (~)1.0.0f 1.0.0f-r1
  1.0.0g 1.0.0h **1.0.1
  {{bindist gmp kerberos rfc3779 sse2 static-libs test vanilla
  zlib}} Installed versions: 0.9.8u(0.9.8)(22:32:12 12/03/12)(sse2
  zlib -bindist -gmp -kerberos -test) 1.0.0h(22:33:20 12/03/12)(sse2
  zlib -bindist -gmp -kerberos -rfc3779 -static-libs -test)
 
 
 
  I think you should file a bug against www-client/google-chrome
 
  It wants the exact version dev-libs/openssl:0.9.8 but the oldest in
  portage is dev-libs/openssl:0.9.8r
 
  Chances are the dev simply left off the version suffix by accident
 
  That can't be it. There's a wildcard at the end:
 
  =dev-libs/openssl-0.9.8*
 
  which should match 0.9.8u.
 
 No wait, that's vmware. The chrome ebuild pulls a slot:
 
dev-libs/openssl:0.9.8
 
 This also matches correctly.  The 0.9.8 slot matches all those
 versions. So no problem with that either.

I missed that colon for the slot.
So this certainly looks buggy on the part of depclean. Now to find out
what's going on.

One thing that strikes me as a possibility is that the highest numbered
version has the lower slot number (0). I know that SLOT names are
just names and not supposed to be treated like they form an order, but
I've seen odd things like this before. I think KDE did it to me once.

What happens if you emerge openssl:0.9.8, let it go into world, then
run depclean? The build takes 2 minutes and you can easily remove it
from world later.

-- 
Alan McKinnnon
alan.mckin...@gmail.com

[gentoo-user] Re: depclean stopped working


On 17/04/12 19:39, Alan McKinnon wrote:

On Tue, 17 Apr 2012 18:41:55 +0300
Nikos Chantziarasrea...@gmail.com  wrote:


On 17/04/12 18:34, Nikos Chantziaras wrote:

On 17/04/12 18:10, Alan McKinnon wrote:

On Tue, 17 Apr 2012 18:01:43 +0300
Nikos Chantziarasrea...@gmail.com  wrote:


emerge --depclean seems to have bugged out for me:

* Dependencies could not be completely resolved due to
* the following required packages not being installed:
*
* =dev-libs/openssl-0.9.8* pulled in by:
* app-emulation/vmware-workstation-8.0.2.591240
*
* dev-libs/openssl:0.9.8 pulled in by:
* www-client/google-chrome-19.0.1084.24_beta131971

It says to do a emerge --update --newuse --deep --with-bdeps=y
@world. Which is what I just did to begin with (and running it
again doesn't result in anything getting emerged.)
 [...]


One thing that strikes me as a possibility is that the highest numbered
version has the lower slot number (0). I know that SLOT names are
just names and not supposed to be treated like they form an order, but
I've seen odd things like this before. I think KDE did it to me once.

What happens if you emerge openssl:0.9.8, let it go into world, then
run depclean? The build takes 2 minutes and you can easily remove it
from world later.


Nope, nothing changed.

[gentoo-user] Re: depclean stopped working


On 17/04/12 18:01, Nikos Chantziaras wrote:

emerge --depclean seems to have bugged out for me:

* Dependencies could not be completely resolved due to
* the following required packages not being installed:
*
* =dev-libs/openssl-0.9.8* pulled in by:
* app-emulation/vmware-workstation-8.0.2.591240
*
* dev-libs/openssl:0.9.8 pulled in by:
* www-client/google-chrome-19.0.1084.24_beta131971

It says to do a emerge --update --newuse --deep --with-bdeps=y @world.
Which is what I just did to begin with (and running it again doesn't
result in anything getting emerged.)


I filed a bug about this:

  https://bugs.gentoo.org/show_bug.cgi?id=412391

If someone wants to try and reproduce this:

  emerge www-client/google-chrome
  emerge -a --depclean

Re: [gentoo-user] Re: depclean stopped working

2012-04-17 Thread Paul Hartman

On Tue, Apr 17, 2012 at 1:13 PM, Nikos Chantziaras rea...@gmail.com wrote:
 On 17/04/12 18:01, Nikos Chantziaras wrote:

 emerge --depclean seems to have bugged out for me:

 * Dependencies could not be completely resolved due to
 * the following required packages not being installed:
 *
 * =dev-libs/openssl-0.9.8* pulled in by:
 * app-emulation/vmware-workstation-8.0.2.591240
 *
 * dev-libs/openssl:0.9.8 pulled in by:
 * www-client/google-chrome-19.0.1084.24_beta131971

 It says to do a emerge --update --newuse --deep --with-bdeps=y @world.
 Which is what I just did to begin with (and running it again doesn't
 result in anything getting emerged.)


 I filed a bug about this:

  https://bugs.gentoo.org/show_bug.cgi?id=412391

 If someone wants to try and reproduce this:

  emerge www-client/google-chrome
  emerge -a --depclean

FWIW I have google-chrome and vmware-workstation (same versions quoted
above) installed and don't see this issue (~amd64 box). My installed
openssl are version 0.9.8u and 1.0.0h.

Re: [gentoo-user] Re: depclean after kde-4.6 upgrade

2011-05-12 Thread Mick

On 12 May 2011 06:31, Mick michaelkintz...@gmail.com wrote:
 On Wednesday 11 May 2011 23:26:18 Nikos Chantziaras wrote:
 On 05/12/2011 12:28 AM, Mick wrote:
  Having completed the upgrade I noticed that a few packages are being
  called up
 
  for removal:
    sys-apps/dmidecode
 
       selected: 2.10
 
      protected: none
 
        omitted: none
 
  I can't think of it being a dependency - did I emerge it and forgot about
  it?

 Do you care?  Does it matter? :-)

 It probably doesn't matter, but I don't know if it does and was curious.

Found what caused this.  My removing of hal which was pulling this in.

-- 
Regards,
Mick

Re: [gentoo-user] Re: depclean after kde-4.6 upgrade

2011-05-12 Thread Mick

On Wednesday 11 May 2011 23:26:28 Paul Hartman wrote:
 On Wed, May 11, 2011 at 4:56 PM, Mick michaelkintz...@gmail.com wrote:
  kde-base/knetworkconf
 selected: 4.4.5
protected: none
  omitted: none
  
  Is asking to be removed, but there isn't a 4.6 version.  Has it been
  replaced by something else?
 
 It was replaced by knetworkmanager

Not sure it is.

knetworkconf-4.4.5 is part of kde-base family of packages and has no 
networkmanager support or indeed wicd, but knetworkmanager is part of kde-misc 
and has support for both (at least as far as their USE flags advise).

Also, knetworkconf was brought in as part kdeadmin-meta-4.4.5, knetworkmanager 
is not.
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: depclean after kde-4.6 upgrade

2011-05-11 Thread Mick

On Wednesday 11 May 2011 22:28:22 you wrote:
 Having completed the upgrade I noticed that a few packages are being called
 up for removal:
 
  sys-apps/dmidecode
 selected: 2.10
protected: none
  omitted: none
 
 I can't think of it being a dependency - did I emerge it and forgot about
 it?
 
 
 Anyway, this confused me more:
 
   kde-base/okteta
 selected: 4.4.5
protected: none
  omitted: none
 
 okteta is not my world file.  So something brought it in.  It was not
 updated to v6, instead when I try to update it manually is asking for a
 second slot ... is this normal?
 =
 # emerge -uaDv okteta
 
 These are the packages that would be merged, in order:
 
 Calculating dependencies... done!
 [ebuild  NS   ] kde-base/okteta-4.6.2 [4.4.5] USE=handbook (-aqua) -debug
 (- kdeenablefinal) (-kdeprefix) 5,933 kB
 [uninstall] kde-base/okteta-4.4.5  USE=handbook (-aqua) -debug (-
 kdeenablefinal) (-kdeprefix)
 [blocks b ] kde-base/okteta:4.6[-kdeprefix] (kde-base/okteta:4.6[-
 kdeprefix] is blocking kde-base/okteta-4.4.5)
 [blocks b ] kde-base/okteta:4.4[-kdeprefix] (kde-base/okteta:4.4[-
 kdeprefix] is blocking kde-base/okteta-4.6.2)
 
 Total: 1 package (1 in new slot, 1 uninstall), Size of downloads: 5,933 kB
 Conflict: 2 blocks
 =
 
 Why is this happening?

Similarly:

kde-base/libksane-4.4.5 does not seem to have been updated to kde-
base/libksane-4.6.2 ... as part of update world.

Shouldn't it have been?


Finally,  

kde-base/knetworkconf
selected: 4.4.5 
   protected: none 
 omitted: none

Is asking to be removed, but there isn't a 4.6 version.  Has it been replaced 
by something else?
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: depclean after kde-4.6 upgrade

2011-05-11 Thread Nikos Chantziaras


On 05/12/2011 12:28 AM, Mick wrote:

Having completed the upgrade I noticed that a few packages are being called up
for removal:

  sys-apps/dmidecode
 selected: 2.10
protected: none
  omitted: none

I can't think of it being a dependency - did I emerge it and forgot about it?


Do you care?  Does it matter? :-)



Anyway, this confused me more:

   kde-base/okteta
 selected: 4.4.5
protected: none
  omitted: none

okteta is not my world file.  So something brought it in.  It was not updated
to v6, instead when I try to update it manually is asking for a second slot
... is this normal?


Yes, it's normal.  The slot will be installed, the old slot uninstalled. 
 Btw, okteta is a dep of kdevelop, which is only pulled-in when the 
okteta USE flag is enabled.  Maybe that's why you have it installed.

Re: [gentoo-user] Re: depclean after kde-4.6 upgrade

2011-05-11 Thread Paul Hartman

On Wed, May 11, 2011 at 4:56 PM, Mick michaelkintz...@gmail.com wrote:
 kde-base/knetworkconf
    selected: 4.4.5
   protected: none
     omitted: none

 Is asking to be removed, but there isn't a 4.6 version.  Has it been replaced
 by something else?

It was replaced by knetworkmanager

Re: [gentoo-user] Re: depclean after kde-4.6 upgrade

2011-05-11 Thread Mick

On Wednesday 11 May 2011 23:26:18 Nikos Chantziaras wrote:
 On 05/12/2011 12:28 AM, Mick wrote:
  Having completed the upgrade I noticed that a few packages are being
  called up
  
  for removal:
sys-apps/dmidecode

   selected: 2.10
  
  protected: none
  
omitted: none
  
  I can't think of it being a dependency - did I emerge it and forgot about
  it?
 
 Do you care?  Does it matter? :-)

It probably doesn't matter, but I don't know if it does and was curious.


  Anyway, this confused me more:
 kde-base/okteta
 
   selected: 4.4.5
  
  protected: none
  
omitted: none
  
  okteta is not my world file.  So something brought it in.  It was not
  updated to v6, instead when I try to update it manually is asking for a
  second slot ... is this normal?
 
 Yes, it's normal.  The slot will be installed, the old slot uninstalled.
   Btw, okteta is a dep of kdevelop, which is only pulled-in when the
 okteta USE flag is enabled.  Maybe that's why you have it installed.

Ah!  Yes, that flag is now not there:

$ euse -i okteta
global use flags (searching: okteta)

no matching entries found

local use flags (searching: okteta)

[-] okteta (dev-util/kdevelop):
Enable hex editor plugin

Thanks!
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: --depclean complains that a package is not installed but it is installed.

2011-02-02 Thread Nikos Chantziaras


On 02/02/2011 09:23 AM, Dale wrote:

I run --depclean every once and a while to see if anything is not needed
anymore. Sort of do a little house cleaning. When I run it, it gives me
this message:

Calculating dependencies... done!
* Dependencies could not be completely resolved due to
* the following required packages not being installed:
*
* media-sound/phonon[-aqua] pulled in by:
* x11-libs/qt-webkit-4.7.1-r1
*
* Have you forgotten to run `emerge --update --newuse --deep @world` prior
* to depclean? It may be necessary to manually uninstall packages that
no longer
* exist in the portage tree since it may not be possible to satisfy their
* dependencies. Also, be aware of the --with-bdeps option that is
documented
* in `man emerge`.
root@fireball / #

I ran this just before the above:

root@fireball / # emerge -uvDNa world --with-bdeps y


Not sure what's going on, but with weird errors it sometimes helped here 
to unmerge the packages first and then running emerge world again.  It's 
as if portage needs to forget something first by unmerging it, and 
re-emerging doesn't fix it.

Re: [gentoo-user] Re: depclean / db php loop

2009-11-01 Thread Joshua Murphy

On Sat, Oct 31, 2009 at 9:26 PM, walt w41...@gmail.com wrote:
 On 10/31/2009 04:42 PM, Mark Knecht wrote:
 ...
    If it matters this is a PPC Mac Mini used as a MythTV backend
 server...

 Oops, I forgot to ask:

 It may be very important -- but I don't have a clue what a MythTV
 server does or what packages it depends on.

 Does your server use something like Apache/php to do the serving,
 and do you really need php to do it?

MythTV is digital video recording software, allowing
watching/recording of things through a tv tuner card, and even
pause/resume of a 'live stream'.

It's heavily dependent on mysql, as I recall, and has the option to
use Apache+PHP to serve up a web based interface, MythWeb, as is
mentioned in the OPs reply to your question. It, however, doesn't use
php's ability to interface with berkley db in any way I'm aware of, so
it should safe to merely rebuild php without the berkdb use flag, then
remove the db package.

-- 
Poison [BLX]
Joshua M. Murphy

p.s. - for the OP, php is a scripting language that's most commonly
used to provide dynamic web content, and as MythWeb is written in
php... ;)

[gentoo-user] Re: depclean / db php loop

2009-10-31 Thread walt

On 10/31/2009 04:42 PM, Mark Knecht wrote:

 ...

  *   sys-libs/db-4.6.21_p4 pulled in by:
  * dev-lang/php-5.2.11 needs libdb-4.6.so
 Calculating dependencies... done!
 [ebuild   R   ] dev-lang/php-5.2.11  USE=apache2 berkdb bzip2 cgi cli
^^
Ah, the nomenclature is a bit confusing.  libdb is supplied by the Berkely
database package (the historical name) but portage calls the package db.

This Berkely distinguishes db from db2 (which is IBM, not Berkely).

Anyway to get rid of the 'db' dependency you need to unset your berkdb USE
flag and rebuild php.  Very confusing!

[gentoo-user] Re: depclean / db php loop

2009-10-31 Thread walt

On 10/31/2009 04:42 PM, Mark Knecht wrote:
 ...
If it matters this is a PPC Mac Mini used as a MythTV backend
 server...

Oops, I forgot to ask:

It may be very important -- but I don't have a clue what a MythTV
server does or what packages it depends on.

Does your server use something like Apache/php to do the serving,
and do you really need php to do it?

Re: [gentoo-user] Re: depclean / db php loop

2009-10-31 Thread Mark Knecht

On Sat, Oct 31, 2009 at 7:26 PM, walt w41...@gmail.com wrote:
 On 10/31/2009 04:42 PM, Mark Knecht wrote:
 ...
    If it matters this is a PPC Mac Mini used as a MythTV backend
 server...

 Oops, I forgot to ask:

 It may be very important -- but I don't have a clue what a MythTV
 server does or what packages it depends on.

 Does your server use something like Apache/php to do the serving,
 and do you really need php to do it?


Walt,
   Thanks for the info on the USE flag. I'll try that tomorrow.

   As for Myth and Apache, there is a MythWeb app that allows me to
look at TV listings, what's recorded, what's coming up, etc. I don't
even know what php is so I cannot say whether I need it or not. I
suspect this is the sort of thing where a developer or whoever sets of
basic profiles set something and maybe I could get rid of it if I knew
what it did. It seems to be required by MythWeb and I don't seem to
have any real USE flag control in MythWeb. To me Apache is just a
tool, not an app, so I don't try to optimize how I use it but rather
hope the Gentoo devs are making the right choices.

   Again, thanks!

- Mark

MacMini ~ # equery depends php
[ Searching for packages depending on php... ]
www-apps/mythweb-0.21_p17573 (=virtual/httpd-php-5*)
MacMini ~ #


MacMini ~ # emerge -pv mythweb apache

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] www-servers/apache-2.2.11-r2  USE=ldap ssl -debug
-doc (-selinux) -sni -static -suexec -threads
APACHE2_MODULES=actions alias auth_basic authn_alias authn_anon
authn_dbm authn_default authn_file authz_dbm authz_default
authz_groupfile authz_host authz_owner authz_user autoindex cache dav
dav_fs dav_lock deflate dir disk_cache env expires ext_filter
file_cache filter headers include info log_config logio mem_cache mime
mime_magic negotiation rewrite setenvif speling status unique_id
userdir usertrack vhost_alias -asis -auth_digest -authn_dbd -cern_meta
-charset_lite -dbd -dumpio -ident -imagemap -log_forensic -proxy
-proxy_ajp -proxy_balancer -proxy_connect -proxy_ftp -proxy_http
-substitute -version APACHE2_MPMS=-event -itk -peruser -prefork
-worker 0 kB


[ebuild   R   ] www-apps/mythweb-0.21_p17573  USE=-vhosts 0 kB

Total: 2 packages (2 reinstalls), Size of downloads: 0 kB
MacMini ~ #

[gentoo-user] Re: depclean wants to remove qt-4.4.2

2009-03-22 Thread Marc Blumentritt


Daniel Pielmeier schrieb:

Marc Blumentritt schrieb am 21.03.2009 14:33:

Hi,

when I run emerge -p --depclen, I get these results:

[...]

These are the packages that would be unmerged:

 x11-libs/qt
selected: 4.4.2
   protected: none
 omitted: 3.3.8b-r1

 x11-libs/qt-assistant
selected: 4.4.2-r1
   protected: none
 omitted: none

 x11-libs/qt-xmlpatterns
selected: 4.4.2
   protected: none
 omitted: none
[...]

Can someone explain me this?



Yeah these packages are not needed by others anymore. If you really
want/need them which i doubt you can put x11-libs/qt into the world file.

Starting with qt-4.4 the ebuild has been split up into components.
x11-libs/qt is just a meta ebuild nothing needs to depend on.
Dependencies are set upon the components. So if you really want all qt
stuff even if you do not need parts of it put x11-libs/qt in your world
file.


OK, thanks for making this clear for me.

Marc

Re: [gentoo-user] Re: depclean wants to wipe out KDE3

2008-12-23 Thread Neil Bothwick

On Mon, 22 Dec 2008 16:04:06 +0200, Nikos Chantziaras wrote:

  Why would they?  /usr/kde/3.5/bin comes first in KDE 3 sessions and
  last in KDE 4 sessions.  There's no problem at all.  
  
  Not here
  
  % echo $PATH
  /usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i486-pc-linux-gnu/gcc-bin/4.1.2:/usr/i686-pc-linux-gnu/gcc-bin/4.3.2:/usr/kde/3.5/bin:/usr/qt/3/bin:/home/nelz/bin

 
 Maybe because you *do* use kdeprefix.  Maybe it's better without it, 
 like here, where it works ;D

I get the same order on this computer, which does not have KDE4.


-- 
Neil Bothwick

Don't just read the Tagline; read the MESSAGE!


signature.asc
Description: PGP signature

[gentoo-user] Re: depclean wants to wipe out KDE3

2008-12-23 Thread Nikos Chantziaras


Neil Bothwick wrote:

On Mon, 22 Dec 2008 16:04:06 +0200, Nikos Chantziaras wrote:


Why would they?  /usr/kde/3.5/bin comes first in KDE 3 sessions and
last in KDE 4 sessions.  There's no problem at all.  

Not here

% echo $PATH
/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i486-pc-linux-gnu/gcc-bin/4.1.2:/usr/i686-pc-linux-gnu/gcc-bin/4.3.2:/usr/kde/3.5/bin:/usr/qt/3/bin:/home/nelz/bin  
Maybe because you *do* use kdeprefix.  Maybe it's better without it, 
like here, where it works ;D


I get the same order on this computer, which does not have KDE4.


That's because you don't have it.

`echo $PATH` in a KDE3 session:

/usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/qt/3/bin:/usr/games/bin

`echo $PATH` in a KDE4 session:

/usr/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/qt/3/bin:/usr/games/bin

So can we all agree now that the kdeprefix USE flag doesn't matter the 
least with KDE3+KDE4 and that it's only there to support multiple 
installations of KDE4?  (Like KDE 4.0.x + 4.1.x at the same time.)

Re: [gentoo-user] Re: depclean wants to wipe out KDE3

2008-12-23 Thread Dale

Nikos Chantziaras wrote:
 Neil Bothwick wrote:
 On Mon, 22 Dec 2008 16:04:06 +0200, Nikos Chantziaras wrote:

 Why would they?  /usr/kde/3.5/bin comes first in KDE 3 sessions and
 last in KDE 4 sessions.  There's no problem at all.  
 Not here

 % echo $PATH
 /usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i486-pc-linux-gnu/gcc-bin/4.1.2:/usr/i686-pc-linux-gnu/gcc-bin/4.3.2:/usr/kde/3.5/bin:/usr/qt/3/bin:/home/nelz/bin
  

 Maybe because you *do* use kdeprefix.  Maybe it's better without it,
 like here, where it works ;D

 I get the same order on this computer, which does not have KDE4.

 That's because you don't have it.

 `echo $PATH` in a KDE3 session:

 /usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/qt/3/bin:/usr/games/bin


 `echo $PATH` in a KDE4 session:

 /usr/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/qt/3/bin:/usr/games/bin


 So can we all agree now that the kdeprefix USE flag doesn't matter the
 least with KDE3+KDE4 and that it's only there to support multiple
 installations of KDE4?  (Like KDE 4.0.x + 4.1.x at the same time.)




r...@smoker / # euse -i kdeprefix
global use flags (searching: kdeprefix)

[+ C  ] kdeprefix - Makes a KDE prefixed install into /usr/kde/${SLOT}
if enabled or into /usr (FHS compatible) otherwise

local use flags (searching: kdeprefix)

no matching entries found
r...@smoker / #

Dale

:-)  :-)

[gentoo-user] Re: depclean wants to wipe out KDE3

2008-12-23 Thread Nikos Chantziaras


Dale wrote:

Nikos Chantziaras wrote:

Neil Bothwick wrote:

On Mon, 22 Dec 2008 16:04:06 +0200, Nikos Chantziaras wrote:


Why would they?  /usr/kde/3.5/bin comes first in KDE 3 sessions and
last in KDE 4 sessions.  There's no problem at all.  

Not here

% echo $PATH
/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i486-pc-linux-gnu/gcc-bin/4.1.2:/usr/i686-pc-linux-gnu/gcc-bin/4.3.2:/usr/kde/3.5/bin:/usr/qt/3/bin:/home/nelz/bin 

Maybe because you *do* use kdeprefix.  Maybe it's better without it,
like here, where it works ;D

I get the same order on this computer, which does not have KDE4.

That's because you don't have it.

`echo $PATH` in a KDE3 session:

/usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/qt/3/bin:/usr/games/bin


`echo $PATH` in a KDE4 session:

/usr/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/qt/3/bin:/usr/games/bin


So can we all agree now that the kdeprefix USE flag doesn't matter the
least with KDE3+KDE4 and that it's only there to support multiple
installations of KDE4?  (Like KDE 4.0.x + 4.1.x at the same time.)





r...@smoker / # euse -i kdeprefix
global use flags (searching: kdeprefix)

[+ C  ] kdeprefix - Makes a KDE prefixed install into /usr/kde/${SLOT}
if enabled or into /usr (FHS compatible) otherwise

local use flags (searching: kdeprefix)

no matching entries found
r...@smoker / #


Here's what it should say:

[+ C  ] kdeprefix - Makes a KDE 4 prefixed install into [...]

How I know?  I don't use kdeprefix and my KDE 3 is installed in 
/usr/kde/3.5 ;)


Also, if you care to look you'll see that kdeprefix is not used by any 
KDE3 ebuild.

Re: [gentoo-user] Re: depclean wants to wipe out KDE3

2008-12-23 Thread Neil Bothwick

On Tue, 23 Dec 2008 14:54:52 +0200, Nikos Chantziaras wrote:

  Maybe because you *do* use kdeprefix.  Maybe it's better without it, 
  like here, where it works ;D  
  
  I get the same order on this computer, which does not have KDE4.  
 
 That's because you don't have it.
 
 `echo $PATH` in a KDE3 session:
 
 /usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/qt/3/bin:/usr/games/bin

On both computers, one with KDE4 installed and one without, /usr/bin
comes before any KDE directories in my $PATH.


-- 
Neil Bothwick

I used to live in the real world, but I got evicted.


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: depclean wants to wipe out KDE3

2008-12-23 Thread Dale

Nikos Chantziaras wrote:
Dale wrote:
Nikos Chantziaras wrote:
Neil Bothwick wrote:
On Mon, 22 Dec 2008 16:04:06 +0200, Nikos Chantziaras wrote:

Why would they? /usr/kde/3.5/bin comes first in KDE 3 sessions and
last in KDE 4 sessions. There's no problem at all.
Not here

% echo $PATH
/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i486-pc-linux-gnu/gcc-bin/4.1.2:/usr/i686-pc-linux-gnu/gcc-bin/4.3.2:/usr/kde/3.5/bin:/usr/qt/3/bin:/home/nelz/bin

Maybe because you *do* use kdeprefix. Maybe it's better without it,
like here, where it works ;D
I get the same order on this computer, which does not have KDE4.
That's because you don't have it.

`echo $PATH` in a KDE3 session:

/usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/qt/3/bin:/usr/games/bin

`echo $PATH` in a KDE4 session:

/usr/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/qt/3/bin:/usr/games/bin

So can we all agree now that the kdeprefix USE flag doesn't matter the
least with KDE3+KDE4 and that it's only there to support multiple
installations of KDE4? (Like KDE 4.0.x + 4.1.x at the same time.)

r...@smoker / # euse -i kdeprefix
global use flags (searching: kdeprefix)

[+ C ] kdeprefix - Makes a KDE prefixed install into /usr/kde/${SLOT}
if enabled or into /usr (FHS compatible) otherwise

local use flags (searching: kdeprefix)

no matching entries found
r...@smoker / #

Here's what it should say:

[+ C ] kdeprefix - Makes a KDE 4 prefixed install into [...]

How I know? I don't use kdeprefix and my KDE 3 is installed in
/usr/kde/3.5 ;)

Also, if you care to look you'll see that kdeprefix is not used by any
KDE3 ebuild.

I subscribe to the -dev thread and if I recall correctly, KDE 3.5
installs into /usr/kde/3.5 whether kdeprefix is set or not. KDE 3.5 and
earlier always has. However, KDE 4.0 has changed and requires that flag
if you want KDE 4.* installed in /usr/kde/4.*.

So, if you are not using KDE 4.*, then it has no effect yet. If you
have it set and have both KDE 3.5 and KDE 4.0, then it will install KDE
3.5 in /usr/kde/3.5 and KDE 4.0 in /usr/kde/4.*. If you have both KDE
3.5 and KDE 4.* and it is not set, it installs KDE 3.5 in /usr/kde/3.5
and KDE 4.* in /usr.

Since the people that do the ebuilds is the same people that wrote what
the flag does, I like how you want to change what it means. If they
don't know what the flag does, nobody else likely will either. If you
disagree with what it says, go to -dev and tell them to change it or
file a bug report.

Dale

:-) :-)

Re: [gentoo-user] Re: depclean wants to wipe out KDE3

2008-12-22 Thread Neil Bothwick

On Mon, 22 Dec 2008 02:18:27 +0200, Nikos Chantziaras wrote:

 OK, now I'm really curious; turns out they are NOT dependencies :P  I 
 just checked with equery and nothing depends on them.  Is that normal? 
 I mean, startkde for example is crucial to even start KDE 3 and it's
 not a dependency?

In which case it must have been in world. If you don't want to use KDE
4.x, just convert all kde-base entries in world to use he 3.5 slot.

sed -i 's/\(^kde-base.*\)/\1:3.5/' /var/lib/portage/world


-- 
Neil Bothwick

When you go to court you are putting yourself in the hands of 12 people
that were not smart enough to get out of jury duty.


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: depclean wants to wipe out KDE3

2008-12-22 Thread Neil Bothwick

On Mon, 22 Dec 2008 03:57:22 +0200, Nikos Chantziaras wrote:

 And how is putting KDE4 in /usr/kde going to help in this?  What 
 difference does it make if the wrong path is chosen?  Surely, it
 doesn't matter a bit how that path looks like if it's wrong.  If a KDE4
 path would come before a KDE3 path in a KDE3 session, the last thing
 you care about is whether that path is /usr/bin or /usr/kde/4.1/bin.

Because /usr/bin will always be in your PATH, so even if you are running a
KDE 3 session, KDE4 programs will be loaded. By keeping the separate,not
only from one another but also from other programs, you can ensure that
your PATH includes only KDE3 or KDE4 programs.
 

-- 
Neil Bothwick

I'm Not Sure If I'm Homosexual, Said Tom, Half In Earnest.


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: depclean wants to wipe out KDE3

2008-12-22 Thread Dale

Neil Bothwick wrote:
 On Mon, 22 Dec 2008 03:57:22 +0200, Nikos Chantziaras wrote:

   
 And how is putting KDE4 in /usr/kde going to help in this?  What 
 difference does it make if the wrong path is chosen?  Surely, it
 doesn't matter a bit how that path looks like if it's wrong.  If a KDE4
 path would come before a KDE3 path in a KDE3 session, the last thing
 you care about is whether that path is /usr/bin or /usr/kde/4.1/bin.
 

 Because /usr/bin will always be in your PATH, so even if you are running a
 KDE 3 session, KDE4 programs will be loaded. By keeping the separate,not
 only from one another but also from other programs, you can ensure that
 your PATH includes only KDE3 or KDE4 programs.
  

   

So to clarify a bit more, for me at least.  If you login to KDE 3.5 then
/usr/kde/3.5/bin is in your path but not /usr/kde/kde/4.*.  The same
could be said in the reverse I assume?

If you don't use the flag and login to KDE 3.5 then all the KDE 4.*
stuff is in your path and anytime you try to open a KDE 3.5 app, it sees
the KDE 4.* apps first?  Correct?  If it is, I can only imagine how
confused a computer would be. 

I wonder if a person could change the order that those paths are
searched?  Could you put in a config file somewhere to search one first
then the others or would that just not work well in the reverse situation?

I think I am out of cents again.  o~o  I'm starting to see why this is
so confusing to a computer now.  Whew !

Dale

:-)  :-)

[gentoo-user] Re: depclean wants to wipe out KDE3


Dale wrote:

Neil Bothwick wrote:

On Mon, 22 Dec 2008 03:57:22 +0200, Nikos Chantziaras wrote:

  
And how is putting KDE4 in /usr/kde going to help in this?  What 
difference does it make if the wrong path is chosen?  Surely, it

doesn't matter a bit how that path looks like if it's wrong.  If a KDE4
path would come before a KDE3 path in a KDE3 session, the last thing
you care about is whether that path is /usr/bin or /usr/kde/4.1/bin.


Because /usr/bin will always be in your PATH, so even if you are running a
KDE 3 session, KDE4 programs will be loaded. By keeping the separate,not
only from one another but also from other programs, you can ensure that
your PATH includes only KDE3 or KDE4 programs.


So to clarify a bit more, for me at least.  If you login to KDE 3.5 then
/usr/kde/3.5/bin is in your path but not /usr/kde/kde/4.*.  The same
could be said in the reverse I assume?

If you don't use the flag and login to KDE 3.5 then all the KDE 4.*
stuff is in your path and anytime you try to open a KDE 3.5 app, it sees
the KDE 4.* apps first?  Correct?  If it is, I can only imagine how
confused a computer would be. 


I wonder if a person could change the order that those paths are
searched?  Could you put in a config file somewhere to search one first
then the others or would that just not work well in the reverse situation?


That's already the case.  /usr/bin comes first in KDE4 sessions, while 
/usr/kde/3.5/bin is first in KDE 3 sessions.  Same goes for LDPATH.

[gentoo-user] Re: depclean wants to wipe out KDE3


Neil Bothwick wrote:

On Mon, 22 Dec 2008 03:57:22 +0200, Nikos Chantziaras wrote:

And how is putting KDE4 in /usr/kde going to help in this?  What 
difference does it make if the wrong path is chosen?  Surely, it

doesn't matter a bit how that path looks like if it's wrong.  If a KDE4
path would come before a KDE3 path in a KDE3 session, the last thing
you care about is whether that path is /usr/bin or /usr/kde/4.1/bin.


Because /usr/bin will always be in your PATH, so even if you are running a
KDE 3 session, KDE4 programs will be loaded.


Why would they?  /usr/kde/3.5/bin comes first in KDE 3 sessions and last 
in KDE 4 sessions.  There's no problem at all.

Re: [gentoo-user] Re: depclean wants to wipe out KDE3

2008-12-22 Thread Dale

Nikos Chantziaras wrote:
 Neil Bothwick wrote:
 On Mon, 22 Dec 2008 03:57:22 +0200, Nikos Chantziaras wrote:

 And how is putting KDE4 in /usr/kde going to help in this?  What
 difference does it make if the wrong path is chosen?  Surely, it
 doesn't matter a bit how that path looks like if it's wrong.  If a KDE4
 path would come before a KDE3 path in a KDE3 session, the last thing
 you care about is whether that path is /usr/bin or /usr/kde/4.1/bin.

 Because /usr/bin will always be in your PATH, so even if you are
 running a
 KDE 3 session, KDE4 programs will be loaded.

 Why would they?  /usr/kde/3.5/bin comes first in KDE 3 sessions and
 last in KDE 4 sessions.  There's no problem at all.




Then why doesn't it work then?  I'm confused.  I just know that I have
already put the USE flag in mine for when KDE 4 goes stable and starts
moving in.  I like having KDE in the place it has always been since it
has worked for me so far. 

Yes, I read the arguments made on -dev a while ago.  It didn't make
sense then and it still doesn't.

Dale

:-)  :-)

Re: [gentoo-user] Re: depclean wants to wipe out KDE3

2008-12-22 Thread Neil Bothwick

On Mon, 22 Dec 2008 13:37:08 +0200, Nikos Chantziaras wrote:

  Because /usr/bin will always be in your PATH, so even if you are
  running a KDE 3 session, KDE4 programs will be loaded.  
 
 Why would they?  /usr/kde/3.5/bin comes first in KDE 3 sessions and
 last in KDE 4 sessions.  There's no problem at all.

Not here

% echo $PATH
/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i486-pc-linux-gnu/gcc-bin/4.1.2:/usr/i686-pc-linux-gnu/gcc-bin/4.3.2:/usr/kde/3.5/bin:/usr/qt/3/bin:/home/nelz/bin

Keeping the programs separate seems a more robust approach than hoping
they will be found in the right order. I would never recommend anyone to
use two KDE slots without kdeprefix.


-- 
Neil Bothwick

Dream as if you'll live forever. Live as if you'll die today.


signature.asc
Description: PGP signature

[gentoo-user] Re: depclean wants to wipe out KDE3


Dale wrote:

Nikos Chantziaras wrote:

Neil Bothwick wrote:

On Mon, 22 Dec 2008 03:57:22 +0200, Nikos Chantziaras wrote:


And how is putting KDE4 in /usr/kde going to help in this?  What
difference does it make if the wrong path is chosen?  Surely, it
doesn't matter a bit how that path looks like if it's wrong.  If a KDE4
path would come before a KDE3 path in a KDE3 session, the last thing
you care about is whether that path is /usr/bin or /usr/kde/4.1/bin.

Because /usr/bin will always be in your PATH, so even if you are
running a
KDE 3 session, KDE4 programs will be loaded.

Why would they?  /usr/kde/3.5/bin comes first in KDE 3 sessions and
last in KDE 4 sessions.  There's no problem at all.


Then why doesn't it work then?


It works.  It's just that this thread has gone off topic :P

[gentoo-user] Re: depclean wants to wipe out KDE3


Neil Bothwick wrote:

On Mon, 22 Dec 2008 13:37:08 +0200, Nikos Chantziaras wrote:


Because /usr/bin will always be in your PATH, so even if you are
running a KDE 3 session, KDE4 programs will be loaded.  

Why would they?  /usr/kde/3.5/bin comes first in KDE 3 sessions and
last in KDE 4 sessions.  There's no problem at all.


Not here

% echo $PATH
/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i486-pc-linux-gnu/gcc-bin/4.1.2:/usr/i686-pc-linux-gnu/gcc-bin/4.3.2:/usr/kde/3.5/bin:/usr/qt/3/bin:/home/nelz/bin


Maybe because you *do* use kdeprefix.  Maybe it's better without it, 
like here, where it works ;D

Re: [gentoo-user] Re: depclean wants to wipe out KDE3

2008-12-21 Thread Albert Hopkins

On Sun, 2008-12-21 at 06:34 +0200, Nikos Chantziaras wrote:
 Nikos Chantziaras wrote:
  [...]
  The reason is that KDE4 is a new product and has nothing to do with KDE3 
  other than the name.  And another reason is the problem I'm describing 
  in this very thread which should have not been a problem if KDE4 had its 
  own tree.  Now I'm required to have non-straightforward voodoo performed 
  to get things right just because the devs made a wrong decision.

That's what SLOTS are fore.  KDE4 is in it's own slot and can be
installed instead of/in addition to KDE 3.5.  Putting a package in a
different SLOT is effectively putting it i it's own tree.

$ emerge -p kde-base/kde-meta:3.5
[...]

[ebuild  N] kde-base/kdepim-wizards-3.5.10  USE=-debug 
[ebuild  N] kde-base/karm-3.5.10  USE=-debug 
[ebuild  N] kde-base/kontact-specialdates-3.5.10  USE=-debug 
[ebuild  N] kde-base/kdepim-meta-3.5.10  USE=-pda 
[ebuild  N] kde-base/kde-meta-3.5.10  USE=nls -accessibility 

$ emerge -p kde-base/kde-meta:4.1
[...]
[ebuild  N] kde-base/krunner-4.1.3  USE=opengl -debug -kdeprefix
-xcomposite -xscreensaver 
[ebuild  N] kde-base/kdepim-meta-4.1.3 
[ebuild  N] kde-base/kdebase-startkde-4.1.3  USE=-kdeprefix 
[ebuild  N] kde-base/kdebase-meta-4.1.3 
[ebuild  N] kde-base/kde-meta-4.1.3  USE=-accessibility 

What kind of voodoo is that?

In the past, Gentoo devs have spend a lot of time and effort moving
split package trees under one tree (e.g. PHP).  I don't see them going
backwards any time soon.
  
 
 Another problem, this time not technical.  I just don't want many of 
 those packages in my world file.  I want to use depclean and have those 
 packages removed when the package that depends on them is also removed. 
   The depclean feature just got useless for those packages.
 

By definition, --depclean doesn't remove anything in the world file (or
its dependencies).  If you want something removed don't put it in the
world file (or put something that depends on it in your world file).
*You* are the controller of your world file.  Nothing gets put there
without your specifying so.

Anyone still thinks it was a good idea to have KDE4 use the same tree 
 with KDE3? This is was clearly a wrong decision.
 
 Workarounds are welcome.

I don't think you need a work-around, just to understand how portage
works.  A (re-)read of the man pages should help.

-a

Re: [gentoo-user] Re: depclean wants to wipe out KDE3

2008-12-21 Thread Alan McKinnon

On Saturday 20 December 2008 14:35:13 Nikos Chantziaras wrote:
 Alan McKinnon wrote:
  On Saturday 20 December 2008 11:53:05 Nikos Chantziaras wrote:
  You can start by giving the relevant information, like what exactly
  related to kde is in world?. Chances are you only have KDE there, and
  emerge will probably want to nuke all but the latest SLOT. Common
  problems with KDE:
 
  Put 'kdeprefix' in USE and rebuild
  Put KDE:3.5 in world and recheck.
 
  This last one often needs to be redone recursively to get everything in
  world that needs to be there. I've heard that autounmask helps with
  this
 
  kdeprefix has nothing to do with KDE3.  It's not needed.  It's only
  needed to have many KDE4 versions at the same time.
 
  That's not true.

 Yes it is.

 http://www.gentoo.org/proj/en/desktop/kde/kde4-guide.xml#doc_chap3

 This restriction does not apply to KDE 3.5 [...]. You can have a
 non-kdeprefix version of KDE 4.1, KDE 3.5 and a live version of KDE
 installed on the same system.

 kdeprefix is *only* for multiple KDE 4 installations.

Now go back and read my post again. I'm not talking about what the docs are 
talking about. I'm talking about kde-3* being installed into /usr/kde/3.5 and 
KDE-4 being installed into /usr/ and the resulting mess that happens when you 
get LDPATH, PATH and various other env vars set up wrong when you start a 
session.

  With USE=-kdeprefix, KDE4 is installed into /usr/
  With USE=kdeprefix, KDE4 is installed into /usr/kde/4.x

 Yes, and KDE3 is *always* installed in /usr/kde/3.5 no matter what.
 Therefore, kdeprefix is totally irrelevant here.

No it is not, and you have not read my post properly. I'm not talking about 
the *installation* of kde-3.5 interfering with KDE-4, I'm talking about run 
time.

I'm saying that KDE-4 co-existing with kde-3.5 is so much easier if KDE-4 is 
installed into /usr/kde.

  The net result, when co-installed with kde-3.x, is that your various
  *PATH variables will always have 3 before 4 or vice-versa. Which is a
  major pita trying to get 3 and 4 to co-exist. Try it sometime, and watch
  KDE-4 try to read KDE-3's config and data files. Or have KDE-4 launch
  konqueror-4 and always get it right every time.

 Has nothing to do with kdeprefix :P

See above.

  There's only one sane way to install KDE on gentoo - always use SLOTs,
  always put every version in it's own directory in /usr/kde/, always add
  the relevant directories to PATH | LDPATH | etc at start-up. The other
  option is to have one, and only one, kde version at any time.

 You're misinformed, I think.  For the reasons above :)

  I'll try the KDE:3.5 thingy.  I wonder though why the heck I have to do
  this.  KDE4 should have been put in its own tree.
 
  Well that's your opinion, you are entitled to it. The KDE devs don't
  agree though, and their three of a kind trumps your two pairs. If you are
  going to assert that KDE-4 SHOULD be in it's own tree, then you are going
  to have to present a sane argument for why, and for why the existing
  decision is incorrect. Just saying something should be doesn't cut the
  mustard in this case.

 The reason is that KDE4 is a new product and has nothing to do with KDE3
 other than the name.  And another reason is the problem I'm describing
 in this very thread which should have not been a problem if KDE4 had its
 own tree.  Now I'm required to have non-straightforward voodoo performed
 to get things right just because the devs made a wrong decision.

It would *still* be a problem. The konqueror binary is called konqueror 
on-disk in 3.5 and 4. If you don't set up the environment correctly, which 
one is going to be launched?

It makes much more sense to install all versions of all DEs calling 
themselves KDE the same way if you have two or more of them installed. If 
you only have KDE-4 and do not have KDE-3*, then elect to USE kdeprefix any 
way that suits your needs.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Re: depclean wants to wipe out KDE3

2008-12-21 Thread Neil Bothwick

On Sun, 21 Dec 2008 06:34:39 +0200, Nikos Chantziaras wrote:

 Another problem, this time not technical.  I just don't want many of 
 those packages in my world file.  I want to use depclean and have those 
 packages removed when the package that depends on them is also removed. 
   The depclean feature just got useless for those packages.

That's incorrect. You only need the packages you use in world, portage is
clever enough to figure out which dependencies are needed by 3.5 packages.


-- 
Neil Bothwick

If this leaves a waxy buildup - on anything - I'm coming back.


signature.asc
Description: PGP signature

[gentoo-user] Re: depclean wants to wipe out KDE3


Neil Bothwick wrote:

On Sun, 21 Dec 2008 06:34:39 +0200, Nikos Chantziaras wrote:

Another problem, this time not technical.  I just don't want many of 
those packages in my world file.  I want to use depclean and have those 
packages removed when the package that depends on them is also removed. 
  The depclean feature just got useless for those packages.


That's incorrect. You only need the packages you use in world, portage is
clever enough to figure out which dependencies are needed by 3.5 packages.


But it wants to unmerge these for example:

  kde-base/kate
  kde-base/kdebase-startkde
  kde-base/ksmserver

These were dependencies and therefore were not in my world file.  If 
they get unmerge, things will break.  KDevelop will break without Kate, 
and KDE 3.5 itself will break without the other two. :P

[gentoo-user] Re: depclean wants to wipe out KDE3


Nikos Chantziaras wrote:

  kde-base/kate
  kde-base/kdebase-startkde
  kde-base/ksmserver

These were dependencies and therefore were not in my world file.  If 
they get unmerge, things will break.  KDevelop will break without Kate, 
and KDE 3.5 itself will break without the other two. :P


OK, now I'm really curious; turns out they are NOT dependencies :P  I 
just checked with equery and nothing depends on them.  Is that normal? 
I mean, startkde for example is crucial to even start KDE 3 and it's not 
a dependency?

[gentoo-user] Re: depclean wants to wipe out KDE3


Alan McKinnon wrote:

On Saturday 20 December 2008 14:35:13 Nikos Chantziaras wrote:

Alan McKinnon wrote:

On Saturday 20 December 2008 11:53:05 Nikos Chantziaras wrote:

kdeprefix has nothing to do with KDE3.  It's not needed.  It's only
needed to have many KDE4 versions at the same time.

That's not true.

Yes it is.

http://www.gentoo.org/proj/en/desktop/kde/kde4-guide.xml#doc_chap3

This restriction does not apply to KDE 3.5 [...]. You can have a
non-kdeprefix version of KDE 4.1, KDE 3.5 and a live version of KDE
installed on the same system.

kdeprefix is *only* for multiple KDE 4 installations.


Now go back and read my post again. I'm not talking about what the docs are 
talking about. I'm talking about kde-3* being installed into /usr/kde/3.5 and 
KDE-4 being installed into /usr/ and the resulting mess that happens when you 
get LDPATH, PATH and various other env vars set up wrong when you start a 
session.


And how is putting KDE4 in /usr/kde going to help in this?  What 
difference does it make if the wrong path is chosen?  Surely, it doesn't 
matter a bit how that path looks like if it's wrong.  If a KDE4 path 
would come before a KDE3 path in a KDE3 session, the last thing you care 
about is whether that path is /usr/bin or /usr/kde/4.1/bin.


And anyway, starting KDE3 puts the KDE3 paths first.  Starting KDE4 puts 
the KDE4 paths first.  And you don't need kdeprefix to get that behavior.




With USE=-kdeprefix, KDE4 is installed into /usr/
With USE=kdeprefix, KDE4 is installed into /usr/kde/4.x

Yes, and KDE3 is *always* installed in /usr/kde/3.5 no matter what.
Therefore, kdeprefix is totally irrelevant here.


No it is not, and you have not read my post properly. I'm not talking about 
the *installation* of kde-3.5 interfering with KDE-4, I'm talking about run 
time.


I'm saying that KDE-4 co-existing with kde-3.5 is so much easier if KDE-4 is 
installed into /usr/kde.


Doesn't look any easier to me.

Re: [gentoo-user] Re: depclean wants to wipe out KDE3

2008-12-21 Thread Willie Wong

On Mon, Dec 22, 2008 at 02:18:27AM +0200, Penguin Lover Nikos Chantziaras 
squawked:
 Nikos Chantziaras wrote:
   kde-base/kate
   kde-base/kdebase-startkde
   kde-base/ksmserver
 These were dependencies and therefore were not in my world file.  If they 
 get unmerge, things will break.  KDevelop will break without Kate, and KDE 
 3.5 itself will break without the other two. :P

 OK, now I'm really curious; turns out they are NOT dependencies :P  I just 
 checked with equery and nothing depends on them.  Is that normal? I mean, 
 startkde for example is crucial to even start KDE 3 and it's not a 
 dependency?

Hum, that is bizarre. I just tried emerge -pvt kde-meta, and it shows
that kde-meta depends on kdebase-meta depends on kdebase-startkde
(all version 3.5.9)

Checking all the ebuilds currently in the tree (versions 3.5.9,
3.5.10, 4.1.2 and 4.1.3), shows that all versions of kdebase-meta
depend on their corresponding versions of kdebase-startkde (they all
contain the line 

 =kde-base/kdebase-startkde-${PV}:${SLOT}

which picks the right slot). So something is probably broken on your
system. Check the contents of the various ebuilds for the versions you
installed to see what's wrong. 

W

-- 
For the relative problem is one in which the relative radius vectors...from 
one to the other? So, actually, I was wrong. Kepler was right after all.
~DeathMech, S. Sondhi. P-town PHY 205
Sortir en Pantoufles: up 745 days, 44 min

[gentoo-user] Re: depclean wants to wipe out KDE3