Re: [gentoo-user] --depclean wants to remove udev. What!?

[Dale]

Julien Roy wrote:
> Hello,
>
> On 6/19/22 21:38, Dale wrote:
>> Anyone have ideas on this?  I mess up something?  Catch the tree in a
>> bad state?  Something else I'm not aware of?  It's not making sense to
>> me yet.  :/
>
> sys-fs/udev has been replaced by a USE flag on the
> sys-apps/systemd-utils package. When you updated your system, portage
> most likely installed systemd-utils with the 'udev' USE flag by
> default. It also replaces sys-apps/systemd-tmpfiles, which is also
> included in your --depclean.
>
> You can read more about this change here :
> https://www.gentoo.org/support/news-items/2022-04-19-systemd-utils.html
>
> Regards,
> Julien


I don't recall that news item but for my memory, that was a long time
ago.  So, it is safe to remove udev and it is being replaced by
systemd-utils?  OK.  I can live with that.  I did a news list and
grepped for udev.  It didn't find that given that name and I may have
missed it with that name since I don't use systemd.  Oh well. 

Now I got to remember to keep a eye out for changes to this instead of
udev.  o_O 

Thanks much.

Dale

:-)  :-) 

Re: [gentoo-user] --depclean wants to remove udev. What!?

[Dale]

Dale wrote:
> Howdy all,
>
> Once a month or so, or when told to by a news item, I run emerge with
> the --depclean option.  I look at the list in case there something there
> I want to keep or something that shouldn't be removed, like gcc or
> something.  I ran it a bit ago and got back this: 
>
>
> These are the packages that would be unmerged:
>>  dev-lang/vala
>>     selected: 0.52.10
>>    protected: none
>>  omitted: 0.54.7 0.56.1
>>
>>  sys-apps/systemd-tmpfiles
>>     selected: 250
>>    protected: none
>>  omitted: none
>>
>>  dev-libs/rapidjson
>>     selected: 1.1.0-r3
>>    protected: none
>>  omitted: none
>>
>>  sys-fs/udev
>>     selected: 250
>>    protected: none
>>  omitted: none
>>
>>  sys-devel/clang
>>     selected: 13.0.1
>>    protected: none
>>  omitted: 14.0.4
>>
>>  sys-devel/clang-runtime
>>     selected: 13.0.1
>>    protected: none
>>  omitted: 14.0.4
>>
>>  sys-libs/compiler-rt
>>     selected: 13.0.1
>>    protected: none
>>  omitted: 14.0.4
>>
>>  sys-libs/compiler-rt-sanitizers
>>     selected: 13.0.1
>>    protected: none
>>  omitted: 14.0.4
>>
>>  sys-devel/llvm
>>     selected: 13.0.1
>>    protected: none
>>  omitted: 14.0.4
>>
>> All selected packages: =sys-devel/clang-runtime-13.0.1
>> =sys-libs/compiler-rt-13.0.1 =sys-libs/compiler-rt-sanitizers-13.0.1
>> =sys-devel/clang-13.0.1 =dev-lang/vala-0.52.10
>> =sys-apps/systemd-tmpfiles-250 =sys-fs/udev-250 =sys-devel/llvm-13.0.1
>> =dev-libs/rapidjson-1.1.0-r3
>>
> 'Selected' packages are slated for removal.
> 'Protected' and 'omitted' packages will not be removed.
>> Would you like to unmerge these packages? [Yes/No]
>
>
> The part that has me concerned is sys-fs/udev.  There's another that I'm
> not sure about but that one caught my eye right away.  I don't recall
> seeing anything posted on -dev about switching to something else or udev
> no longer being needed and being removed.  I'm confused here.  Isn't the
> virtual supposed to prevent this from being removed?  Is this a portage
> change or did I mess something up somewhere? 
>
> This is what I show here depending either on the virtual or udev itself. 
>
>
>> root@fireball / # equery d sys-fs/udev
>>  * These packages depend on sys-fs/udev:
>> virtual/libudev-232-r7 (!systemd ?
>> sys-fs/udev[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
>> virtual/udev-217-r5 (sys-fs/udev)
>> root@fireball / # equery d virtual/udev
>>  * These packages depend on virtual/udev:
>> app-crypt/zulucrypt-5.5.0_pre20180223 (udev ? virtual/udev)
>> app-pda/usbmuxd-1.1.1 (virtual/udev)
>> dev-libs/libinput-1.20.1 (virtual/udev)
>> media-video/vlc-3.0.17.4 (udev ? virtual/udev)
>> net-misc/dhcpcd-9.4.1 (udev ? virtual/udev)
>> sys-block/f3-8.0 (extra ? virtual/udev)
>> sys-fs/cryptmount-5.3.3-r2 (udev ? virtual/udev)
>> sys-fs/udev-init-scripts-34 (>=virtual/udev-217)
>> sys-fs/udisks-2.9.4 (virtual/udev)
>> sys-kernel/dracut-055-r4 (virtual/udev)
>> sys-libs/libblockdev-2.26 (lvm ? virtual/udev)
>> sys-power/nut-2.7.4-r8 (virtual/udev)
>> sys-power/upower-0.99.17 (kernel_linux ? virtual/udev)
>> virtual/dev-manager-0-r2 (virtual/udev)
>> x11-misc/spacefm-1.0.6-r1 (virtual/udev)
>> xfce-base/thunar-4.16.11 (udisks ? virtual/udev)
>> xfce-extra/thunar-volman-4.16.0 (virtual/udev)
>> root@fireball / # 
>
> This is the packages I have installed containing udev. 
>
>
>> root@fireball / # equery list *udev*
>>  * Searching for *udev* ...
>> [IP-] [  ] dev-libs/libgudev-237-r1:0/0
>> [IP-] [  ] sys-fs/udev-250:0
>> [IP-] [  ] sys-fs/udev-init-scripts-34:0
>> [IP-] [  ] virtual/libudev-232-r7:0/1
>> [IP-] [  ] virtual/udev-217-r5:0
>> root@fireball / # 
>
>
> Anyone have ideas on this?  I mess up something?  Catch the tree in a
> bad state?  Something else I'm not aware of?  It's not making sense to
> me yet.  :/
>
> Thanks.
>
> Dale
>
> :-)  :-) 
>


I think I found something but not sure if it is what I think it is.  The
virtual says it needs one of the following:


sys-apps/systemd-utils[udev]
sys-fs/udev
>=sys-fs/eudev-2.1.1
>=sys-apps/systemd-217


Since systemd-utils is at the top, I looked to see if it was installed
or not, and it is. 

[IP-] [  ] sys-apps/systemd-utils-250.7:0

as is:

sys-fs/udev-250


So, I think it wants to remove udev and use the other.  This is what
depends on the systemd package. 


root@fireball / # equery d sys-apps/systemd-utils
 * These packages depend on sys-apps/systemd-utils:
sys-apps/systemd-tmpfiles-250 (sys-apps/systemd-utils[tmpfiles])
sys-fs/udev-250
(sys-apps/systemd-utils[udev,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
virtual/libudev-232-r7 (!systemd ?
sys-apps/systemd-utils[udev,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
virtual/tmpfiles-0-r3 

Re: [gentoo-user] --depclean wants to remove udev. What!?

[Julien Roy]

Hello,

On 6/19/22 21:38, Dale wrote:

Anyone have ideas on this?  I mess up something?  Catch the tree in a
bad state?  Something else I'm not aware of?  It's not making sense to
me yet.  :/


sys-fs/udev has been replaced by a USE flag on the 
sys-apps/systemd-utils package. When you updated your system, portage 
most likely installed systemd-utils with the 'udev' USE flag by default. 
It also replaces sys-apps/systemd-tmpfiles, which is also included in 
your --depclean.


You can read more about this change here : 
https://www.gentoo.org/support/news-items/2022-04-19-systemd-utils.html


Regards,
Julien


OpenPGP_0x20B80B7E70598F97.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

[gentoo-user] --depclean wants to remove udev. What!?

[Dale]

Howdy all,

Once a month or so, or when told to by a news item, I run emerge with
the --depclean option.  I look at the list in case there something there
I want to keep or something that shouldn't be removed, like gcc or
something.  I ran it a bit ago and got back this: 


> >>> These are the packages that would be unmerged:
>
>  dev-lang/vala
>     selected: 0.52.10
>    protected: none
>  omitted: 0.54.7 0.56.1
>
>  sys-apps/systemd-tmpfiles
>     selected: 250
>    protected: none
>  omitted: none
>
>  dev-libs/rapidjson
>     selected: 1.1.0-r3
>    protected: none
>  omitted: none
>
>  sys-fs/udev
>     selected: 250
>    protected: none
>  omitted: none
>
>  sys-devel/clang
>     selected: 13.0.1
>    protected: none
>  omitted: 14.0.4
>
>  sys-devel/clang-runtime
>     selected: 13.0.1
>    protected: none
>  omitted: 14.0.4
>
>  sys-libs/compiler-rt
>     selected: 13.0.1
>    protected: none
>  omitted: 14.0.4
>
>  sys-libs/compiler-rt-sanitizers
>     selected: 13.0.1
>    protected: none
>  omitted: 14.0.4
>
>  sys-devel/llvm
>     selected: 13.0.1
>    protected: none
>  omitted: 14.0.4
>
> All selected packages: =sys-devel/clang-runtime-13.0.1
> =sys-libs/compiler-rt-13.0.1 =sys-libs/compiler-rt-sanitizers-13.0.1
> =sys-devel/clang-13.0.1 =dev-lang/vala-0.52.10
> =sys-apps/systemd-tmpfiles-250 =sys-fs/udev-250 =sys-devel/llvm-13.0.1
> =dev-libs/rapidjson-1.1.0-r3
>
> >>> 'Selected' packages are slated for removal.
> >>> 'Protected' and 'omitted' packages will not be removed.
>
> Would you like to unmerge these packages? [Yes/No]



The part that has me concerned is sys-fs/udev.  There's another that I'm
not sure about but that one caught my eye right away.  I don't recall
seeing anything posted on -dev about switching to something else or udev
no longer being needed and being removed.  I'm confused here.  Isn't the
virtual supposed to prevent this from being removed?  Is this a portage
change or did I mess something up somewhere? 

This is what I show here depending either on the virtual or udev itself. 


> root@fireball / # equery d sys-fs/udev
>  * These packages depend on sys-fs/udev:
> virtual/libudev-232-r7 (!systemd ?
> sys-fs/udev[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
> virtual/udev-217-r5 (sys-fs/udev)
> root@fireball / # equery d virtual/udev
>  * These packages depend on virtual/udev:
> app-crypt/zulucrypt-5.5.0_pre20180223 (udev ? virtual/udev)
> app-pda/usbmuxd-1.1.1 (virtual/udev)
> dev-libs/libinput-1.20.1 (virtual/udev)
> media-video/vlc-3.0.17.4 (udev ? virtual/udev)
> net-misc/dhcpcd-9.4.1 (udev ? virtual/udev)
> sys-block/f3-8.0 (extra ? virtual/udev)
> sys-fs/cryptmount-5.3.3-r2 (udev ? virtual/udev)
> sys-fs/udev-init-scripts-34 (>=virtual/udev-217)
> sys-fs/udisks-2.9.4 (virtual/udev)
> sys-kernel/dracut-055-r4 (virtual/udev)
> sys-libs/libblockdev-2.26 (lvm ? virtual/udev)
> sys-power/nut-2.7.4-r8 (virtual/udev)
> sys-power/upower-0.99.17 (kernel_linux ? virtual/udev)
> virtual/dev-manager-0-r2 (virtual/udev)
> x11-misc/spacefm-1.0.6-r1 (virtual/udev)
> xfce-base/thunar-4.16.11 (udisks ? virtual/udev)
> xfce-extra/thunar-volman-4.16.0 (virtual/udev)
> root@fireball / # 


This is the packages I have installed containing udev. 


> root@fireball / # equery list *udev*
>  * Searching for *udev* ...
> [IP-] [  ] dev-libs/libgudev-237-r1:0/0
> [IP-] [  ] sys-fs/udev-250:0
> [IP-] [  ] sys-fs/udev-init-scripts-34:0
> [IP-] [  ] virtual/libudev-232-r7:0/1
> [IP-] [  ] virtual/udev-217-r5:0
> root@fireball / # 



Anyone have ideas on this?  I mess up something?  Catch the tree in a
bad state?  Something else I'm not aware of?  It's not making sense to
me yet.  :/

Thanks.

Dale

:-)  :-) 

Re: [gentoo-user] depclean wants to remove xf86-video-intel

[Neil Bothwick]

On Mon, 14 Mar 2022 17:07:54 - (UTC), Grant Edwards wrote:

> I was a bit startled thos morning when emerge --depclean wanted to
> remove xf86-video-intel. I presume this is a result of the switch to
> the "built in" modesetting driver? And there are no corresponding Xorg
> config changes that need to be made?

I bit the bullet, let it depclean and rebooted. The desktp came up as
usual but there was a warning in the log about not being able to load the
intel module

[13.920] (==) Matched intel as autoconfigured driver 0
[13.920] (==) Matched modesetting as autoconfigured driver 1
[13.920] (==) Matched fbdev as autoconfigured driver 2
[13.920] (==) Matched vesa as autoconfigured driver 3
[13.920] (==) Assigned the driver to the xf86ConfigLayout
[13.920] (II) LoadModule: "intel"
[13.920] (WW) Warning, couldn't open module intel
[13.920] (EE) Failed to load module "intel" (module does not exist, 0)
[13.920] (II) LoadModule: "modesetting"
[13.920] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so
[13.935] (II) Module modesetting: vendor="X.Org Foundation"
[13.935]compiled for 1.21.1.3, module version = 1.21.1
[13.935]Module class: X.Org Video Driver
[13.935]ABI class: X.Org Video Driver, version 25.2
[13.935] (II) LoadModule: "fbdev"
[13.935] (WW) Warning, couldn't open module fbdev
[13.935] (EE) Failed to load module "fbdev" (module does not exist, 0)
[13.935] (II) LoadModule: "vesa"
[13.935] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so
[13.937] (II) Module vesa: vendor="X.Org Foundation"
[13.937]compiled for 1.21.1.3, module version = 2.5.0
[13.937]Module class: X.Org Video Driver
[13.937]ABI class: X.Org Video Driver, version 25.2
[13.937] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[13.937] (II) VESA: driver for VESA chipsets: vesa
[13.943] (II) modeset(0): using drv /dev/dri/card0
[13.943] (II) modeset(0): Creating default Display subsection in Screen 
section


> 
> My video chipset is
> 
>   00:02.0 VGA compatible controller: Intel Corporation IvyBridge GT2
> [HD Graphics 4000] (rev 09) 

I have:

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)

> And the only card-selection configuration I've done was to set
> VIDEO_CARDS="intel" in make.conf.

ditto


-- 
Neil Bothwick

Old hitchhikers never die-they just throw in the towel.


pgpCSqkSUmeDI.pgp
Description: OpenPGP digital signature

[gentoo-user] depclean wants to remove xf86-video-intel

[Grant Edwards]

I was a bit startled thos morning when emerge --depclean wanted to
remove xf86-video-intel. I presume this is a result of the switch to
the "built in" modesetting driver? And there are no corresponding Xorg
config changes that need to be made?

My video chipset is

  00:02.0 VGA compatible controller: Intel Corporation IvyBridge GT2 [HD 
Graphics 4000] (rev 09)
 
And the only card-selection configuration I've done was to set
VIDEO_CARDS="intel" in make.conf.

--
Grant

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

[Michael Orlitzky]

On Sun, 2021-07-25 at 20:52 -0400, Rich Freeman wrote:
> On Sun, Jul 25, 2021 at 8:39 PM Michael Orlitzky  wrote:
> > 
> > This is indeed a bug, but not the ones that have been suggested. The
> > underlying problem is that the DJB programs (mail-mta/netqmail, but
> > also net-dns/djbdns, for example) require a particular service manager.
> 
> Is it actually using daemontools as a service manager?  I am not
> familiar enough with it to say.
> 
> When I skimmed the daemontools wiki page I got the impression that it
> was intended to be used in conjunction with openrc.

You start svscan (part of daemontools) with OpenRC, but then you do
some other stuff to make svscan actually start the daemon.


> So, if it is intended as a service manager, it really shouldn't list
> it as a dependency.  After all, we don't go sticking
> openrc/systemd/runit in every package that provides configs for these.

If a service manager is only needed to launch a daemon, then sure. But
the -conf setup programs for djbdns (I don't know about qmail)
create scripts that run executables from daemontools. So unless those
are rewritten or replaced, daemontools is actually needed at runtime.


> 
> > We should have made them support OpenRC and systemd.
> 
> Well, this at least is the subject of a Council decision: no package
> has to support ANY service manager, nor can package maintainers block
> adding support for service managers to a package.
> 

It may be legal to ship a package that's useless out-of-the-box, but
I'm gonna consider it a bug =)

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

[Rich Freeman]

On Sun, Jul 25, 2021 at 8:39 PM Michael Orlitzky  wrote:
>
> This is indeed a bug, but not the ones that have been suggested. The
> underlying problem is that the DJB programs (mail-mta/netqmail, but
> also net-dns/djbdns, for example) require a particular service manager.

Is it actually using daemontools as a service manager?  I am not
familiar enough with it to say.

When I skimmed the daemontools wiki page I got the impression that it
was intended to be used in conjunction with openrc.  Or at least that
is one way it can be used.  Of course, if this is the case it
shouldn't be in that virtual, or if it is then it should itself pull
in openrc as a dependency (assuming it can't also be used with
systemd).

I'd have to spend a lot more time than I care to looking into
daemontools to really comment on that.

> When OpenRC is installed only as a side effect of being listed first in
> virtual/service-manager, it becomes "redundant" after one of the DJB
> programs pulls in daemontools, and portage will offer to remove OpenRC.

So, if it is intended as a service manager, it really shouldn't list
it as a dependency.  After all, we don't go sticking
openrc/systemd/runit in every package that provides configs for these.

> We should have made them support OpenRC and systemd.

Well, this at least is the subject of a Council decision: no package
has to support ANY service manager, nor can package maintainers block
adding support for service managers to a package.

Obviously at this point most packages support openrc/systemd, but they
aren't actually required to.

> With all of that said, maybe in the Handbook we should tell OpenRC
> users to "emerge openrc", in case some other not-mutually-exclusive
> init system is ever pulled in by another program.

So, packages shouldn't be pulling in service managers in general.
That would be a bug if it is the case.  If daemontools does things
other than service management then it might not be an issue, but of
course in that case we probably do need to be careful about treating
it as a service manager automatically.

If a package happens to only supply a systemd service unit then it
shouldn't just pull in systemd because obviously anybody who uses the
package must want to reconfigure their entire host...

It isn't unheard of to have packages that happen to only support one
service manager (though much less common now) - these pacakges should
never just list that service manager as a dependency.  After all,
users can just add their own service units/init.d's/whatevers.

I don't want to say that qmail shouldn't list daemontools without
knowing more about the situation, but that is why I suggested talking
to the maintainer as a first step...

-- 
Rich

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

[Michael Orlitzky]

(Replying nowhere in particular)

This is indeed a bug, but not the ones that have been suggested. The
underlying problem is that the DJB programs (mail-mta/netqmail, but
also net-dns/djbdns, for example) require a particular service manager.
When OpenRC is installed only as a side effect of being listed first in
virtual/service-manager, it becomes "redundant" after one of the DJB
programs pulls in daemontools, and portage will offer to remove OpenRC.

That's not really a problem with @system or virtual/service-manager. On
a distribution where users are supposed to be able to choose their init
systems, a package that requires one specific init system is just a bad
fit -- for exactly this reason. So in my view, it's a bug in
djbdns/qmail. We should have made them support OpenRC and systemd.

I am halfway responsible for this, since I maintain djbdns and have
never figured out a way to make it work with OpenRC (which would
prevent it from pulling in daemontools, which would prevent --depclean
from trying to remove OpenRC). But, as the maintainer of djbdns, I can
let you in on a secret: don't use djbdns. And if you're not already
heavily invested in qmail, postfix is better in every way.

There's no upstream for these packages so you're unlikely to see any of
this fixed, especially when there are better alternatives.

With all of that said, maybe in the Handbook we should tell OpenRC
users to "emerge openrc", in case some other not-mutually-exclusive
init system is ever pulled in by another program.

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

[Neil Bothwick]

On Sun, 25 Jul 2021 17:25:17 +, Alan Mackenzie wrote:

> The number of people who would lose their systems by this mechanism is
> likely very small, but that loss would probably involve a
> re-installation.  I mean all a victim has to go on is the fact that his
> machine won't boot, combined with a memory of having run emerge
> --depclean the night before.

So boot into busybox or a rescue disk, look in emerge.log to see what
changed and undo it. I think a "Can't find init" message would be fairly
easy to understand.

> > 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. Yes, it would
> > require a one-off rebuild of daemontools for everyone with it
> > installed, but the potential for breakage would be removed.  
> 
> Another idea I had today is to have two packages, daemontools and
> daemontools-init, which would be identical, apart from the fact that
> only the second of these would satisfy virtual/service-manager.

See below.

> I can't help feeling that maybe portage has become too complicated.

See above.

Actually, this has little to do with portage, which s doing exactly what
you told it to do - remove all unnecessary/unwanted packages. The problem
is in your configuration that tells portage that openrc is not needed. If
you want a simple, clean and reasonably permanent solution that doesn't
involve putting openrc in @world, copy the virtual to your local overlay
and remove the daemontools dependency.


-- 
Neil Bothwick

Bus: (n.) a connector you plug money into, something like a slot machine.


pgpy9NDOL6Ami.pgp
Description: OpenPGP digital signature

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

[Alan Mackenzie]

Hello, Neil.

On Sun, Jul 25, 2021 at 16:40:23 +0100, Neil Bothwick wrote:
> On Sun, 25 Jul 2021 13:43:46 +, Alan Mackenzie wrote:

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

> > Just as systemd is for your system.  If you'd installed daemontools you
> > would also have come within a keystroke of destroying your system, just
> > 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.

> This is a valid point, that appears to have been obscured by some of the
> discussions about the cause. As to whether it would render the system
> unbootable, I have no idea, would daemontools have taken care of that.

And this is the main point of my complaint - the surprise, the shock, and
the innocence (as in opposite of guilty, not of wordly-wise) of the
victims.  They have done nothing but installing a package in the normal
way.  daemontools can only boot a system if it's been configured to do
so.  That involves writing entries into /etc/inittab.

The number of people who would lose their systems by this mechanism is
likely very small, but that loss would probably involve a
re-installation.  I mean all a victim has to go on is the fact that his
machine won't boot, combined with a memory of having run emerge
--depclean the night before.

My guess (for which I have little basis) would be that daemontools is
used more as part of the various qmail variants rather than as the prime
init system.  I don't recall anybody on this list using d. rather than o.
or s. as their main init system.  In fact, I wasn't even aware it was
possible, before looking it up on Wikipedia this afternoon.

> 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. Yes, it would require a
> one-off rebuild of daemontools for everyone with it installed, but the
> potential for breakage would be removed.

Another idea I had today is to have two packages, daemontools and
daemontools-init, which would be identical, apart from the fact that only
the second of these would satisfy virtual/service-manager.

> If I had to allocate blame for this, I would say it is the virtual that
> is the cause of the problem. With the current setup, unmerging openrc is
> the only way for depclean to deal with it when you have daemontools in
> @world.

I can't help feeling that maybe portage has become too complicated.

> -- 
> Neil Bothwick

> Top Oxymorons Number 41: Good grief

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Neil Bothwick]

On Sun, 25 Jul 2021 13:43:46 +, Alan Mackenzie wrote:

> > It may be critical for *your* system ... :-)  
> 
> Just as systemd is for your system.  If you'd installed daemontools you
> would also have come within a keystroke of destroying your system, just
> 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.

This is a valid point, that appears to have been obscured by some of the
discussions about the cause. As to whether it would render the system
unbootable, I have no idea, would daemontools have taken care of that.

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. Yes, it would require a
one-off rebuild of daemontools for everyone with it installed, but the
potential for breakage would be removed.

If I had to allocate blame for this, I would say it is the virtual that
is the cause of the problem. With the current setup, unmerging openrc is
the only way for depclean to deal with it when you have daemontools in
@world.


-- 
Neil Bothwick

Top Oxymorons Number 41: Good grief


pgp0ucdbJwt78.pgp
Description: OpenPGP digital signature

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

[Dale]

Wols Lists wrote:
> On 25/07/21 14:49, Dale wrote:
>> The problem here is that a user installed a package outside of
>> emerge/portage's knowledge.
> No that does *NOT* appear to be the problem.
>
> The problem is that the user installed - *using* *portage* - a package
> that satisfied a critical system dependency. Except that they did not
> intend for it to satisfy that dependency!
>
> If they HAD installed it outside of portage, they wouldn't have this
> problem.
>
> Cheers,
> Wol
>
>


That is another way of looking at it for sure.  If Alan wants to install
his mail program then maybe he should install the packages it depends on
manually as well.  My point was that emerge/portage has no way of
knowing why he installed daemontools and to emerge/portage, that meant
removing a package that the virtual no longer needed.  To
emerge/portage, having daemontools and openrc installed was no longer
required.  Since he installed daemontools, emerge/portage assumed that
is what he wanted to use.  Since emerge/portage is in the dark as to
why, it's a expected behavior in my opinion. 

Either way, installing packages outside of emerge/portage puts the user
in charge of the problems it creates.  There's several ways to correct
this so maybe one will be attractive enough to Alan to apply.  I like
Neil's myself but to each his own.

Dale

:-)  :-) 

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

[Dale]

Alan Mackenzie wrote:
> Hello, Wol.
>
> On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote:
>> On 25/07/21 12:47, Alan Mackenzie wrote:
 They are, @system is a set of packages and nothing it it will be
> depcleaned. However, openrc is not part of @system, the virtual is.
>>> Ah, that's it.  So we have critical system packages which aren't part of
>>> @system.  I think openrc is a critical system package.
>> 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 may be critical for *your* system ... :-)
> Just as systemd is for your system.  If you'd installed daemontools you
> would also have come within a keystroke of destroying your system, just
> 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.
>

Since it had a package left that satisfies the virtual, it shouldn't
warn you.  I don't recall emerge/portage ever warning about removing a
unneeded package other than the warning when you run --depclean and it
first starts.  As said before, this is really expected behavior. 

>> Let's rephrase it - "openrc is one of the (optional) packages that
>> satisfied a critical dependency".
> If you must.
>
>> Your problem is caused because you have explicitly installed an
>> alternate package that satisfies the same critical dependency.
> No, my problem is caused by Gentoo allowing its package system, without
> me doing anything strange, to bring my system to within a single
> keystroke of destruction.  That is a bug in any circumstance.  All you
> and most of the others have done is pointed out the mechanisms by which
> this happened, with the implicit assumption that because that's what
> they do, they must be right.  They're not at all right.
>
> Nobody here has made any suggestions as to how this situation might be
> prevented in the future, not just for me, but for the next user who
> needs daemontools.
>
>> Cheers,
>> Wol


But the problem started when you installed a package outside of
emerge/portage.  As I pointed out earlier, since you installed a package
outside of emerge/portage's knowledge, how do you expect it to know you
need both packages?  It's also why I suggested to either create a ebuild
or add the packages your mail program depends on to the world file. 
Neil came up with what I think is a better solution of using sets.  It
sounds like what he is doing so it must work well enough.

What we are saying is this.  When you install a package outside
emerge/portage's knowledge, you have to manage the things it depends on
and the problems that creates.  In your case, daemontools satisfied the
virtual and emerge/portage wanted to remove openrc but it did so because
you installed another package that satisfies that virtual.  If you
hadn't installed the other package that your mail program needs, that
would not have happened.  So, you actually created the conditions that
made emerge/portage think it was OK to remove the package openrc. 
Again, emerge/portage doesn't know you have your mail program installed
or what it depends on.  It has no idea why you need BOTH daemontools and
openrc installed.  Luckily for you, one isn't a blocker for the other or
that is a whole new can of worms.  Also luckily you caught it was about
to remove it as well. 

The lesson from this, when you install a package outside of
emerge/portage and use emerge/portage to install packages it depends on,
you have to be careful of the problems it creates.  You can't expect
emerge/portage to understand what you are doing and why. 

Dale

:-)  :-) 

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

[Wols Lists]

On 25/07/21 14:49, Dale wrote:
> The problem here is that a user installed a package outside of
> emerge/portage's knowledge.

No that does *NOT* appear to be the problem.

The problem is that the user installed - *using* *portage* - a package
that satisfied a critical system dependency. Except that they did not
intend for it to satisfy that dependency!

If they HAD installed it outside of portage, they wouldn't have this
problem.

Cheers,
Wol

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

[Dale]

tastytea wrote:
> On 2021-07-25 13:26+0100 Wols Lists  wrote:
>
>> On 25/07/21 12:47, Alan Mackenzie wrote:
 They are, @system is a set of packages and nothing it it will be  
> depcleaned. However, openrc is not part of @system, the virtual
> is.  
>>> Ah, that's it.  So we have critical system packages which aren't
>>> part of @system.  I think openrc is a critical system package.
>>>   
>> 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.
>>
>> It may be critical for *your* system ... :-)
>>
>> Let's rephrase it - "openrc is one of the (optional) packages that
>> satisfied a critical dependency". Your problem is caused because you
>> have explicitly installed an alternate package that satisfies the same
>> critical dependency.
> Maybe OpenRC should come pre-recorded into @world on profiles that
> default to it. If I switch to another init system I can explicitly
> uninstall OpenRC. Forgetting to uninstall it is no big deal.
> Accidentally uninstalling it makes my system unbootable.
>


>From my understanding, nothing should be in @world by default.  The bare
necessities are in @system and what the user installs is in @world.  I
haven't downloaded a starge3 tarball in ages to look but I'm pretty sure
the world file comes empty. 

The problem here is that a user installed a package outside of
emerge/portage's knowledge.  At that point, the user is responsible for
making sure what that package depends on is installed, at the correct
version etc etc.  Since emerge/portage has no knowledge of the package,
it can't making decisions about that package or what it depends on. 

Neil did post a good solution tho.  It's easy enough and will at least
tell emerge/portage that the packages are needed even if it doesn't know
why. 

Dale

:-)  :-) 

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

[Alan Mackenzie]

Hello, Wol.

On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote:
> On 25/07/21 12:47, Alan Mackenzie wrote:
> >> They are, @system is a set of packages and nothing it it will be
> >> > depcleaned. However, openrc is not part of @system, the virtual is.

> > Ah, that's it.  So we have critical system packages which aren't part of
> > @system.  I think openrc is a critical system package.

> 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 may be critical for *your* system ... :-)

Just as systemd is for your system.  If you'd installed daemontools you
would also have come within a keystroke of destroying your system, just
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.

> Let's rephrase it - "openrc is one of the (optional) packages that
> satisfied a critical dependency".

If you must.

> Your problem is caused because you have explicitly installed an
> alternate package that satisfies the same critical dependency.

No, my problem is caused by Gentoo allowing its package system, without
me doing anything strange, to bring my system to within a single
keystroke of destruction.  That is a bug in any circumstance.  All you
and most of the others have done is pointed out the mechanisms by which
this happened, with the implicit assumption that because that's what
they do, they must be right.  They're not at all right.

Nobody here has made any suggestions as to how this situation might be
prevented in the future, not just for me, but for the next user who
needs daemontools.

> Cheers,
> Wol

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Dale]

Neil Bothwick wrote:
>
> My point is that you are mixing portage and non-portage packages, that's
> why portage is getting confused. I don't know much about daemontools, but
> it seems the sort of package that should not be in @world, but only
> installed as a dependency of something else.
>
> I'm nit suggesting that you should avoid non-portage packages, that may
> be impossible or undesirable, but you should be aware of possible
> consequences. When I need portage to install dependencies to a
> non-portage package, I generally create a set for them, so you could
> create qmail-deps containing both daemontools and openrc and emerge it.
> Then you are safe from either being depcleaned. If you ever decide to
> stop using qmail, you can just unmerge the set and let portage clean up.
>
>

I forgot about the sets option.  That would be another good way to solve
this issue.  It does mean emerge/portage doesn't know why the packages
are needed but it wouldn't remove them because the user told
emerge/portage not too.  That may be better than adding daemontools to
the world file and much easier than creating a ebuild. 

Nice thinking Neil.  :-D 

Dale

:-)  :-) 

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

[Neil Bothwick]

On Sun, 25 Jul 2021 11:47:40 +, Alan Mackenzie wrote:

> > > I would say all packages in @system _are_ needed, unless the user
> > > explicitly says otherwise.  
> 
> > They are, @system is a set of packages and nothing it it will be
> > depcleaned. However, openrc is not part of @system, the virtual is.  
> 
> Ah, that's it.  So we have critical system packages which aren't part of
> @system.  I think openrc is a critical system package.

openrc is not necessarily critical, just some sort of service manager.
that's the whole point of a virtual, to handle different use cases and
requirements.

> > That is possible, but it is also possible that this is entirely down
> > to you installing things outside of portage and handling their
> > dependencies manually, creating unwanted side-effects like this.  
> 
> Quite the contrary.  If I'd've stuck to the daemontools I installed from
> a tarball, this whole thing wouldn't have happened.  It's BECAUSE I
> switched to using the portage version that this danger reared its ugly
> head.

My point is that you are mixing portage and non-portage packages, that's
why portage is getting confused. I don't know much about daemontools, but
it seems the sort of package that should not be in @world, but only
installed as a dependency of something else.

I'm nit suggesting that you should avoid non-portage packages, that may
be impossible or undesirable, but you should be aware of possible
consequences. When I need portage to install dependencies to a
non-portage package, I generally create a set for them, so you could
create qmail-deps containing both daemontools and openrc and emerge it.
Then you are safe from either being depcleaned. If you ever decide to
stop using qmail, you can just unmerge the set and let portage clean up.

> > > Maybe the answer is to regard --depclean as a tool for experts only,
> > > since it is capable in ordinary innocent use of rendering a system
> > > unusable.  
> 
> > I feel it's more a case of Gentoo being a system for those that
> > understand what they are doing with the system - with great power
> > comes great responsibility and all that.  
> 
> That feels needlessly patronising, Neil.  I fear the Gentoo maintainers
> will take the same attitude.  Not only can the user shoot himself in the
> foot, but it's Gentoo that provides the gun, innocently wrapped, with a
> "press here" direction on the packaging above a hidden trigger.  Nobody
> accepts any responsibility for preventing accidents.

It wasn't meant to be patronising, but you should be aware of what is
going on. In this case you were because although portage suggested
removing openrc, you sensibly declined the offer.
 
> The implication of what you say is that nobody should use portage
> without understanding every last intricate detail of it.  This doesn't
> feel reasonable.

No, but it is a system that demands a greater level of understanding from
its users than, say, apt or rpm.

> Nobody but me seems to see anything wrong with all this.  It's one thing
> saying users should look after themselves, but surely it's quite another
> thing to provide an obsure mechanism where one's one keypress away from
> destroying ones system.

You could cripple it but not destroy it. It would not be nice, but you
can recover from the accidental removal of openrc or even python.
Fortunately, you don't have to find out exactly how not nice :)


-- 
Neil Bothwick

- How many surrealists does it take to change a light bulb?
- Two: one to hold the giraffe, the other to fill the bathtub with
  lots of brightly colored machine tools.


pgpykLyJBxQD7.pgp
Description: OpenPGP digital signature

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

[tastytea]

On 2021-07-25 13:26+0100 Wols Lists  wrote:

> On 25/07/21 12:47, Alan Mackenzie wrote:
> >> They are, @system is a set of packages and nothing it it will be  
> >> > depcleaned. However, openrc is not part of @system, the virtual
> >> > is.  
> 
> > Ah, that's it.  So we have critical system packages which aren't
> > part of @system.  I think openrc is a critical system package.
> >   
> 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.
> 
> It may be critical for *your* system ... :-)
> 
> Let's rephrase it - "openrc is one of the (optional) packages that
> satisfied a critical dependency". Your problem is caused because you
> have explicitly installed an alternate package that satisfies the same
> critical dependency.

Maybe OpenRC should come pre-recorded into @world on profiles that
default to it. If I switch to another init system I can explicitly
uninstall OpenRC. Forgetting to uninstall it is no big deal.
Accidentally uninstalling it makes my system unbootable.

-- 
Get my PGP key with `gpg --locate-keys tasty...@tastytea.de` or at
.


pgpkXNEeQ2rTz.pgp
Description: Digitale Signatur von OpenPGP

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

[Dale]

Alan Mackenzie wrote:
> Hello, Neil.
>
> On Sun, Jul 25, 2021 at 10:03:44 +0100, Neil Bothwick wrote:
>> On Sat, 24 Jul 2021 21:01:34 +, Alan Mackenzie wrote:
> It seems it's insisting on removing all packages but one which
> satisfy a virtual.  Maybe that is unwise, and it should keep _all_
> such packages which are currently installed.  
 Well, the whole point of an any-of dependency is to only require one
 of them.  Why force packages to stick around if they aren't needed?  
>>> I would say all packages in @system _are_ needed, unless the user
>>> explicitly says otherwise.
>> They are, @system is a set of packages and nothing it it will be
>> depcleaned. However, openrc is not part of @system, the virtual is.
> Ah, that's it.  So we have critical system packages which aren't part of
> @system.  I think openrc is a critical system package.
>
 Now, whether daemontools actually should satisfy the dependency I
 don't want to comment on without doing more research.  Surely though
 there is little point in having openrc and systemd and runit on the
 same system unless the user explicitly wants this (and if they do they
 can just stick them in @world).  
>>> The user might be switching between them, doing comparisons.  (No, I
>>> don't know if this is practical.)  I don't know either whether it's
>>> practical to boot Gentoo with just daemontools.  But there are use cases
>>> which require both openrc and daemontools on the same system, so there's
>>> something not quite right about the service-manager ebuild, or emerge.
>> That is possible, but it is also possible that this is entirely down to
>> you installing things outside of portage and handling their dependencies
>> manually, creating unwanted side-effects like this.
> Quite the contrary.  If I'd've stuck to the daemontools I installed from
> a tarball, this whole thing wouldn't have happened.  It's BECAUSE I
> switched to using the portage version that this danger reared its ugly head. 
>
>>> I think that would be solving the wrong problem.  The fact is, it is
>>> easy, far too easy, to shoot yourself in the foot here.  As well as
>>> openrc, --depclean also wanted to remove nano (the editor) for the same
>>> reason.  That might be serious for some people.
>> It did that because you have another suitable editor installed. I don't
>> like nano so I'm happy to install something else that satisfies
>> virtual/editor and let depclean get rid of nano, knowing that it won't do
>> it unless I already have a suitable alternative installed.
>>> Maybe the answer is to regard --depclean as a tool for experts only,
>>> since it is capable in ordinary innocent use of rendering a system
>>> unusable.
>> I feel it's more a case of Gentoo being a system for those that
>> understand what they are doing with the system - with great power comes
>> great responsibility and all that.
> That feels needlessly patronising, Neil.  I fear the Gentoo maintainers
> will take the same attitude.  Not only can the user shoot himself in the
> foot, but it's Gentoo that provides the gun, innocently wrapped, with a
> "press here" direction on the packaging above a hidden trigger.  Nobody
> accepts any responsibility for preventing accidents.
>
> The implication of what you say is that nobody should use portage
> without understanding every last intricate detail of it.  This doesn't
> feel reasonable.
>
> Nobody but me seems to see anything wrong with all this.  It's one thing
> saying users should look after themselves, but surely it's quite another
> thing to provide an obsure mechanism where one's one keypress away from
> destroying ones system.
>
> I'm quite a bit less enthusiastic about Gentoo than I was a few days
> ago.
>
>> -- 
>> Neil Bothwick
>> Caution, an incorrigible punster - don't incorrige.


The point is the same as it always has been.  If you install a package
outside of portage's knowledge, it is on you to make sure any
dependencies are installed and to update the package itself.  Surely you
don't expect emerge/portage to know you installed a package outside its
knowledge and to keep things it depends on by some sort of magic.  When
a user updates using emerge/portage, it can only go by what it knows. 
It can't assume something it has no knowledge of. 

This is why I mentioned creating a ebuild for your mail program and
using emerge to install it.  In the ebuild will be what that software
depends on.  That puts emerge/portage in the know that certain things
are needed and not to remove them.  Unless you do that, or add needed
packages to the world file, emerge/portage will want to remove things it
feels are not needed based on what it knows.  To be honest, this is
expected behavior.  It's the whole point of --depclean. 

In short, this is expected behavior.  If it didn't work this way, then
I'd say there is a bug that needs to be addressed. 

I might add, this is why I try to never install anything outside of
using 

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

[Wols Lists]

On 25/07/21 12:47, Alan Mackenzie wrote:
>> They are, @system is a set of packages and nothing it it will be
>> > depcleaned. However, openrc is not part of @system, the virtual is.

> Ah, that's it.  So we have critical system packages which aren't part of
> @system.  I think openrc is a critical system package.
> 
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.

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

Let's rephrase it - "openrc is one of the (optional) packages that
satisfied a critical dependency". Your problem is caused because you
have explicitly installed an alternate package that satisfies the same
critical dependency.

Cheers,
Wol

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

[Alan Mackenzie]

Hello, Neil.

On Sun, Jul 25, 2021 at 10:03:44 +0100, Neil Bothwick wrote:
> On Sat, 24 Jul 2021 21:01:34 +, Alan Mackenzie wrote:

> > > > It seems it's insisting on removing all packages but one which
> > > > satisfy a virtual.  Maybe that is unwise, and it should keep _all_
> > > > such packages which are currently installed.  

> > > Well, the whole point of an any-of dependency is to only require one
> > > of them.  Why force packages to stick around if they aren't needed?  

> > I would say all packages in @system _are_ needed, unless the user
> > explicitly says otherwise.

> They are, @system is a set of packages and nothing it it will be
> depcleaned. However, openrc is not part of @system, the virtual is.

Ah, that's it.  So we have critical system packages which aren't part of
@system.  I think openrc is a critical system package.

> > > Now, whether daemontools actually should satisfy the dependency I
> > > don't want to comment on without doing more research.  Surely though
> > > there is little point in having openrc and systemd and runit on the
> > > same system unless the user explicitly wants this (and if they do they
> > > can just stick them in @world).  

> > The user might be switching between them, doing comparisons.  (No, I
> > don't know if this is practical.)  I don't know either whether it's
> > practical to boot Gentoo with just daemontools.  But there are use cases
> > which require both openrc and daemontools on the same system, so there's
> > something not quite right about the service-manager ebuild, or emerge.

> That is possible, but it is also possible that this is entirely down to
> you installing things outside of portage and handling their dependencies
> manually, creating unwanted side-effects like this.

Quite the contrary.  If I'd've stuck to the daemontools I installed from
a tarball, this whole thing wouldn't have happened.  It's BECAUSE I
switched to using the portage version that this danger reared its ugly head. 

> > I think that would be solving the wrong problem.  The fact is, it is
> > easy, far too easy, to shoot yourself in the foot here.  As well as
> > openrc, --depclean also wanted to remove nano (the editor) for the same
> > reason.  That might be serious for some people.

> It did that because you have another suitable editor installed. I don't
> like nano so I'm happy to install something else that satisfies
> virtual/editor and let depclean get rid of nano, knowing that it won't do
> it unless I already have a suitable alternative installed.

> > Maybe the answer is to regard --depclean as a tool for experts only,
> > since it is capable in ordinary innocent use of rendering a system
> > unusable.

> I feel it's more a case of Gentoo being a system for those that
> understand what they are doing with the system - with great power comes
> great responsibility and all that.

That feels needlessly patronising, Neil.  I fear the Gentoo maintainers
will take the same attitude.  Not only can the user shoot himself in the
foot, but it's Gentoo that provides the gun, innocently wrapped, with a
"press here" direction on the packaging above a hidden trigger.  Nobody
accepts any responsibility for preventing accidents.

The implication of what you say is that nobody should use portage
without understanding every last intricate detail of it.  This doesn't
feel reasonable.

Nobody but me seems to see anything wrong with all this.  It's one thing
saying users should look after themselves, but surely it's quite another
thing to provide an obsure mechanism where one's one keypress away from
destroying ones system.

I'm quite a bit less enthusiastic about Gentoo than I was a few days
ago.

> -- 
> Neil Bothwick

> Caution, an incorrigible punster - don't incorrige.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Neil Bothwick]

On Sat, 24 Jul 2021 21:01:34 +, Alan Mackenzie wrote:

> > > It seems it's insisting on removing all packages but one which
> > > satisfy a virtual.  Maybe that is unwise, and it should keep _all_
> > > such packages which are currently installed.  
> 
> > Well, the whole point of an any-of dependency is to only require one
> > of them.  Why force packages to stick around if they aren't needed?  
> 
> I would say all packages in @system _are_ needed, unless the user
> explicitly says otherwise.

They are, @system is a set of packages and nothing it it will be
depcleaned. However, openrc is not part of @system, the virtual is.

> > Now, whether daemontools actually should satisfy the dependency I
> > don't want to comment on without doing more research.  Surely though
> > there is little point in having openrc and systemd and runit on the
> > same system unless the user explicitly wants this (and if they do they
> > can just stick them in @world).  
> 
> The user might be switching between them, doing comparisons.  (No, I
> don't know if this is practical.)  I don't know either whether it's
> practical to boot Gentoo with just daemontools.  But there are use cases
> which require both openrc and daemontools on the same system, so there's
> something not quite right about the service-manager ebuild, or emerge.

That is possible, but it is also possible that this is entirely down to
you installing things outside of portage and handling their dependencies
manually, creating unwanted side-effects like this.

> I think that would be solving the wrong problem.  The fact is, it is
> easy, far too easy, to shoot yourself in the foot here.  As well as
> openrc, --depclean also wanted to remove nano (the editor) for the same
> reason.  That might be serious for some people.

It did that because you have another suitable editor installed. I don't
like nano so I'm happy to install something else that satisfies
virtual/editor and let depclean get rid of nano, knowing that it won't do
it unless I already have a suitable alternative installed.

> Maybe the answer is to regard --depclean as a tool for experts only,
> since it is capable in ordinary innocent use of rendering a system
> unusable.

I feel it's more a case of Gentoo being a system for those that
understand what they are doing with the system - with great power comes
great responsibility and all that.


-- 
Neil Bothwick

Caution, an incorrigible punster - don't incorrige.


pgpjz1KCrrge_.pgp
Description: OpenPGP digital signature

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

[Wols Lists]

On 24/07/21 22:09, Alan Mackenzie wrote:
> I'm actually using s/qmail, tarball direct from its maintainer, since
> there's no ebuild for it.  Originally, I had daemontools from the same
> place, until I discovered there was an ebuild for it.

THAT LOOKS LIKE YOUR PROBLEM.

If daemontools has been pulled in because it's explicitly named in
world, then emerge will (quite reasonably) assume that openrc (which is
an implied dependency) can be dispensed with.

In other words, if one member of a virtual package is explicitly
installed, all the other members can be dispensed with. Changing this is
likely to cause breakage all over the place!!!

Okay, it's a nasty surprise to discover that installing a package with
multiple uses can make the system assume you're using it for things
you're not, but I think the only *workable* fix is, as others have said,
to add openrc to the world set.

You've explicitly pulled in a boot manager package. You can't expect
portage to keep a bunch of implicit package managers (systemd, sysV,
openrc etc) lying around when you haven't asked for them. I've installed
postfix as my mailer - I don't want exim, sendmail, etc etc lying around
"just in case".

Cheers,
Wol

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

[Dale]

Alan Mackenzie wrote:
> Hello, Dale.
>
> On Sat, Jul 24, 2021 at 10:03:52 -0500, Dale wrote:
>
>> Maybe qmail needs a USE flag to pull in daemontools?
> I'm actually using s/qmail, tarball direct from its maintainer, since
> there's no ebuild for it.  Originally, I had daemontools from the same
> place, until I discovered there was an ebuild for it.
>
>

Ahhh.  That could be a issue when filing a bug.  When using something
without the package manager installing it, it usually leaves you on your
own.  The easiest thing may be to just add daemontools to your world
file and leave it at that.  The maintainer may have another solution but
I'm suspecting not. 

Another option, create a ebuild for your mail program and put it in your
overlay.  Then you can use emerge to install your mail program so that
emerge knows the dependencies it needs, including daemontools.  As it
is, it doesn't even know you have the mail program there.  Sort of hard
for emerge/portage to know you need a tool kept around.  A ebuild for it
and using emerge to install it would fix that.  Maybe a USE flag or just
a plain hard requirement for daemontools. 

Just a thought.  Someone else may have a better hammer to fix this
problem. 

Dale

:-)  :-) 

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

[Alan Mackenzie]

Hello, Dale.

On Sat, Jul 24, 2021 at 10:03:52 -0500, Dale wrote:
> Alan Mackenzie wrote:

> > I'm considering submitting a bug to bugs.gentoo.org, requesting that
> > _all_ installed packages satisfying a virtual get kept.  There is surely
> > something wrong when somebody who just wants to be a user (me) has to
> > read .ebuild files to get normal things done.



> If you can, I'd recommend trying to reach out to the maintainer to see
> if that is expected behavior.  It could be that that is the way it is
> supposed to work.  If that is so tho, I find it odd.

I find it infuriating when ordinary innocent use of something like
emerge can totally break a system.

> Maybe qmail needs a USE flag to pull in daemontools?

I'm actually using s/qmail, tarball direct from its maintainer, since
there's no ebuild for it.  Originally, I had daemontools from the same
place, until I discovered there was an ebuild for it.

> Maybe something else needs changing.  I'd start by reaching out to the
> maintainer.  I guess a bug report would be considered reaching out but
> a email may also work as well. 

Thanks, I submitted a bug report.  I think it's a bug in emerge.  I've
got a nasty feeling there isn't enough sympathy for non-experts for that
bug to go anywhere, but we'll see.

> Just my thoughts.  May not be worth much.  ;-)

> Dale

> :-)  :-) 

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hello again, Rich.

On Sat, Jul 24, 2021 at 10:58:55 -0400, Rich Freeman wrote:
> On Sat, Jul 24, 2021 at 10:46 AM Alan Mackenzie  wrote:

> > On Sat, Jul 24, 2021 at 10:14:20 -0400, Rich Freeman wrote:
> > > On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie  wrote:

> > > > So in these virtual packages, it seems by default the _last_ mentioned
> > > > package in a || ( ... ) construct is the one --depclean keeps.  It all
> > > > has the feeling of things not having been properly thought through.

> > > I'm not sure what the default is - most likely PMS just requires that
> > > one of them be kept.

> > PMS?  Part of emerge?

> Package Manager Specification.  Specifically:
> https://projects.gentoo.org/pms/8/pms.html#x1-760008.2.3

Ah, thanks!

> All it requires is that one be present.  Portage can use whatever
> behavior it wishes to decide which to keep (assuming all installed
> packages have their deps).

> > It seems it's insisting on removing all packages but one which satisfy a
> > virtual.  Maybe that is unwise, and it should keep _all_ such packages
> > which are currently installed.

> Well, the whole point of an any-of dependency is to only require one
> of them.  Why force packages to stick around if they aren't needed?

I would say all packages in @system _are_ needed, unless the user
explicitly says otherwise.

> Now, whether daemontools actually should satisfy the dependency I
> don't want to comment on without doing more research.  Surely though
> there is little point in having openrc and systemd and runit on the
> same system unless the user explicitly wants this (and if they do they
> can just stick them in @world).

The user might be switching between them, doing comparisons.  (No, I
don't know if this is practical.)  I don't know either whether it's
practical to boot Gentoo with just daemontools.  But there are use cases
which require both openrc and daemontools on the same system, so there's
something not quite right about the service-manager ebuild, or emerge.

> > I'm considering submitting a bug to bugs.gentoo.org, requesting that
> > _all_ installed packages satisfying a virtual get kept.  There is surely
> > something wrong when somebody who just wants to be a user (me) has to
> > read .ebuild files to get normal things done.

> I'd be shocked if that went anywhere.  I'd think the better solution
> would be to have some kind of USE flag that tells daemontools whether
> it is used as an actual service manager or not, though that has its
> own issues (changing that state shouldn't require rebuilds/etc, but it
> would).

I think that would be solving the wrong problem.  The fact is, it is
easy, far too easy, to shoot yourself in the foot here.  As well as
openrc, --depclean also wanted to remove nano (the editor) for the same
reason.  That might be serious for some people.

I have, in fact, submitted a bug on the "shoot yourself in the foot"
problem.  So far it's got one reply which (possibly wilfully)
misunderstood the intent of the report, and said, much like you did "add
daemontools to @world and the problem's solved".

Maybe the answer is to regard --depclean as a tool for experts only,
since it is capable in ordinary innocent use of rendering a system
unusable.

> In any case, you probably should have a chat with the daemontools
> maintainer.  I doubt the portage team would consider doing something
> like this as some kind of universal policy.  It would impact hundreds
> of things that have any-of dependencies.

OK.  The suggestion I made in my bug report was that @system packages
should be protected, much like @world packages are already.  I don't see
the rationale in protecting @world, but not the more important @system.

> -- 
> Rich

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Dale]

Alan Mackenzie wrote:
>
> I'm considering submitting a bug to bugs.gentoo.org, requesting that
> _all_ installed packages satisfying a virtual get kept.  There is surely
> something wrong when somebody who just wants to be a user (me) has to
> read .ebuild files to get normal things done.
>
>

If you can, I'd recommend trying to reach out to the maintainer to see
if that is expected behavior.  It could be that that is the way it is
supposed to work.  If that is so tho, I find it odd.  Maybe qmail needs
a USE flag to pull in daemontools?  Maybe something else needs
changing.  I'd start by reaching out to the maintainer.  I guess a bug
report would be considered reaching out but a email may also work as well. 

Just my thoughts.  May not be worth much.  ;-)

Dale

:-)  :-) 

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

[Rich Freeman]

On Sat, Jul 24, 2021 at 10:46 AM Alan Mackenzie  wrote:
>
> On Sat, Jul 24, 2021 at 10:14:20 -0400, Rich Freeman wrote:
> > On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie  wrote:
>
> > > So in these virtual packages, it seems by default the _last_ mentioned
> > > package in a || ( ... ) construct is the one --depclean keeps.  It all
> > > has the feeling of things not having been properly thought through.
>
> > I'm not sure what the default is - most likely PMS just requires that
> > one of them be kept.
>
> PMS?  Part of emerge?

Package Manager Specification.  Specifically:
https://projects.gentoo.org/pms/8/pms.html#x1-760008.2.3

All it requires is that one be present.  Portage can use whatever
behavior it wishes to decide which to keep (assuming all installed
packages have their deps).

> It seems it's insisting on removing all packages but one which satisfy a
> virtual.  Maybe that is unwise, and it should keep _all_ such packages
> which are currently installed.

Well, the whole point of an any-of dependency is to only require one
of them.  Why force packages to stick around if they aren't needed?

Now, whether daemontools actually should satisfy the dependency I
don't want to comment on without doing more research.  Surely though
there is little point in having openrc and systemd and runit on the
same system unless the user explicitly wants this (and if they do they
can just stick them in @world).

> I'm considering submitting a bug to bugs.gentoo.org, requesting that
> _all_ installed packages satisfying a virtual get kept.  There is surely
> something wrong when somebody who just wants to be a user (me) has to
> read .ebuild files to get normal things done.

I'd be shocked if that went anywhere.  I'd think the better solution
would be to have some kind of USE flag that tells daemontools whether
it is used as an actual service manager or not, though that has its
own issues (changing that state shouldn't require rebuilds/etc, but it
would).

In any case, you probably should have a chat with the daemontools
maintainer.  I doubt the portage team would consider doing something
like this as some kind of universal policy.  It would impact hundreds
of things that have any-of dependencies.

-- 
Rich

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

[Alan Mackenzie]

Hello, Rich.

On Sat, Jul 24, 2021 at 10:14:20 -0400, Rich Freeman wrote:
> On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie  wrote:

> > So in these virtual packages, it seems by default the _last_ mentioned
> > package in a || ( ... ) construct is the one --depclean keeps.  It all
> > has the feeling of things not having been properly thought through.


> I'm not sure what the default is - most likely PMS just requires that
> one of them be kept.

PMS?  Part of emerge?

It seems it's insisting on removing all packages but one which satisfy a
virtual.  Maybe that is unwise, and it should keep _all_ such packages
which are currently installed.

> If daemontools (or something that depends on it) is in your @world
> that would explain why openrc was selected for removal.

OK, that solves the mystery, thanks.

> I don't know enough to comment on whether daemontools is a substitute
> for openrc.  My first complete guess would be that it could either be
> used in addition to openrc or on its own.

I've only ever used it as part of qmail (the mail transport program),
never on its own.  I'm loathe to mess around with it, since my email
depends on it.  But from what I remember about daemontools, it probably
could be used as an alternative to openrc, I just don't envisage anybody
wanting to do it, though.

> Busybox can be a substitute for sysvinit or udev though most people
> who have it installed probably don't intend for it to be used that
> way.  You could have that conversation with the maintainer.

I'm considering submitting a bug to bugs.gentoo.org, requesting that
_all_ installed packages satisfying a virtual get kept.  There is surely
something wrong when somebody who just wants to be a user (me) has to
read .ebuild files to get normal things done.

> -- 
> Rich

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Rich Freeman]

On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie  wrote:
>
> So in these virtual packages, it seems by default the _last_ mentioned
> package in a || ( ... ) construct is the one --depclean keeps.  It all
> has the feeling of things not having been properly thought through.
>

I'm not sure what the default is - most likely PMS just requires that
one of them be kept.

If daemontools (or something that depends on it) is in your @world
that would explain why openrc was selected for removal.

I don't know enough to comment on whether daemontools is a substitute
for openrc.  My first complete guess would be that it could either be
used in addition to openrc or on its own.  Busybox can be a substitute
for sysvinit or udev though most people who have it installed probably
don't intend for it to be used that way.  You could have that
conversation with the maintainer.

-- 
Rich

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

[Alan Mackenzie]

Hello, Neil.

On Wed, Jul 21, 2021 at 21:27:05 +0100, Neil Bothwick wrote:
> On Wed, 21 Jul 2021 22:13:50 +0200, tastytea wrote:

> > > emerge included openrc (the only version of it on my system) in the
> > > packages it planned to remove.  It was kind enough to give me a
> > > warning that this "might" do bad things, but I was somewhat shocked
> > > to see it there at all.  I might have accidentally typed 'y' instead
> > > of 'n'.

> > > Maybe the program wants revenge at me executing so seldomly.  Or
> > > something like that.

> Well, it would help if you ran it more often.

> > > But now, my question is how can I trust --depclean even a little bit
> > > after that?  Do I have to go through all the package versions,
> > > manually removing the obsolete ones?  There are several hundred.  :-(


> > I'm not sure why it would want to remove openrc, as far as I know it
> > should be part of the @system set unless you're on a systemd profile.

> It's the first dependency of virtual/system-manager, which in turn is
> part of @system. I don't see why it would be removed unless you have
> something else installed that satisfies the virtual , such as systemd or
> runit.

The virtual/service-manager ebuild looks like:

;
# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

EAPI=7

DESCRIPTION="Virtual for various service managers"

SLOT="0"
KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~m68k ~mips ppc ppc64 ~riscv ~s390 
sparc x86 ~x64-cygwin ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos 
~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris ~x86-winnt"
IUSE="kernel_linux"

RDEPEND="
prefix-guest? ( >=sys-apps/baselayout-prefix-2.2 )
!prefix-guest? (
|| (
sys-apps/openrc
kernel_linux? ( || (
sys-apps/systemd
sys-process/runit
virtual/daemontools <
) ) ) )"
;

Maybe virtual/daemontools is what's doing it.  I have
sys-process/daemontools-0.76-r8 installed, and this ebuild satisfies
virtual/daemontools.

However daemontools is NOT (necessarily) an alternative to openrc, but a
supplementary utility.  (I need it for running a qmail variant.)  So,
maybe having daemontools in virtual/service-manager is a bug.

Also, why is --depclean keeping the _last_ installed package which
satisfies a virtual rather than the _first_ package which does?  I
thought only a single package satisfying a virtual was allowed.  Maybe I
used some sort of forcing flag to get daemontools installed, I can't
remember, and there's nothing about this in my notes.

I've got a similar situation with virtual/editor, where I've got vim
installed, and --depclean wants to remove nano, but is warning me against
it.

So in these virtual packages, it seems by default the _last_ mentioned
package in a || ( ... ) construct is the one --depclean keeps.  It all
has the feeling of things not having been properly thought through.

> > You can record it in your @world set with `emerge --select --noreplace
> > sys-apps/openrc`. That should prevent accidental removals.

> It would, but it doesn't address the issue of why portage wants to remove
> it.


> -- 
> Neil Bothwick

> mandelbug /man'del-buhg/ n.
>  [from the Mandelbrot set] A
>bug whose underlying causes are so complex and obscure as to make
>its behavior appear chaotic or even non-deterministic.  This term
>implies that the speaker thinks it is a Bohr bug, rather than
>a heisenbug.  See also schroedinbug.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Neil Bothwick]

On Wed, 21 Jul 2021 22:13:50 +0200, tastytea wrote:

> > emerge included openrc (the only version of it on my system) in the
> > packages it planned to remove.  It was kind enough to give me a
> > warning that this "might" do bad things, but I was somewhat shocked
> > to see it there at all.  I might have accidentally typed 'y' instead
> > of 'n'.
> > 
> > Maybe the program wants revenge at me executing so seldomly.  Or
> > something like that.

Well, it would help if you ran it more often.

> > But now, my question is how can I trust --depclean even a little bit
> > after that?  Do I have to go through all the package versions,
> > manually removing the obsolete ones?  There are several hundred.  :-(
> >  
> 
> I'm not sure why it would want to remove openrc, as far as I know it
> should be part of the @system set unless you're on a systemd profile.

It's the first dependency of virtual/system-manager, which in turn is
part of @system. I don't see why it would be removed unless you have
something else installed that satisfies the virtual , such as systemd or
runit.

> You can record it in your @world set with `emerge --select --noreplace
> sys-apps/openrc`. That should prevent accidental removals.

It would, but it doesn't address the issue of why portage wants to remove
it.


-- 
Neil Bothwick

mandelbug /man'del-buhg/ n.
 [from the Mandelbrot set] A
   bug whose underlying causes are so complex and obscure as to make
   its behavior appear chaotic or even non-deterministic.  This term
   implies that the speaker thinks it is a Bohr bug, rather than
   a heisenbug.  See also schroedinbug.


pgpP4DvBDXCVH.pgp
Description: OpenPGP digital signature

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

[tastytea]

On 2021-07-21 20:06+ Alan Mackenzie  wrote:

> Hello, Gentoo.
> 
> As prompted after the recent perl update, I did # emerge --depclean
> -va.
> 
> emerge included openrc (the only version of it on my system) in the
> packages it planned to remove.  It was kind enough to give me a
> warning that this "might" do bad things, but I was somewhat shocked
> to see it there at all.  I might have accidentally typed 'y' instead
> of 'n'.
> 
> Maybe the program wants revenge at me executing so seldomly.  Or
> something like that.
> 
> But now, my question is how can I trust --depclean even a little bit
> after that?  Do I have to go through all the package versions,
> manually removing the obsolete ones?  There are several hundred.  :-(

I'm not sure why it would want to remove openrc, as far as I know it
should be part of the @system set unless you're on a systemd profile.

You can record it in your @world set with `emerge --select --noreplace
sys-apps/openrc`. That should prevent accidental removals.

Kind regards, tastytea

-- 
Get my PGP key with `gpg --locate-keys tasty...@tastytea.de` or at
.


pgpwm5jgbCOgs.pgp
Description: Digitale Signatur von OpenPGP

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

[Alan Mackenzie]

Hello, Gentoo.

As prompted after the recent perl update, I did # emerge --depclean -va.

emerge included openrc (the only version of it on my system) in the
packages it planned to remove.  It was kind enough to give me a warning
that this "might" do bad things, but I was somewhat shocked to see it
there at all.  I might have accidentally typed 'y' instead of 'n'.

Maybe the program wants revenge at me executing so seldomly.  Or
something like that.

But now, my question is how can I trust --depclean even a little bit
after that?  Do I have to go through all the package versions, manually
removing the obsolete ones?  There are several hundred.  :-(

What do I do?

Help!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[allan gottlieb]

On Fri, Aug 10 2018, Michael Orlitzky wrote:

> On 08/09/2018 10:49 PM, allan gottlieb wrote:
>> I run a stable system so am surprised to see that eix reports
>> I have gcc version ~7.3.0-r3 installed.  (gcc-config -l reports
>> that stable x86_64-pc-linux-gnu-6.4.0 is the active compiler)
>> 
>> More surprising is that
>>emerge --depclean --pretend sys-devel/gcc
>> wants to remove everything *except* the testing/nonstable 7.3.0-r3
>> 
>
> gcc-7.3.0-r3 is stable, you probably updated your ::gentoo repository
> without updating eix. Run eix-update and check again.

Thank you!

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.

I believe not as the requirement when upgrading to 13.0 was due to the
new generation of PIE output.

Again, thank you.
allan

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

[Michael Orlitzky]

On 08/09/2018 10:49 PM, allan gottlieb wrote:
> I run a stable system so am surprised to see that eix reports
> I have gcc version ~7.3.0-r3 installed.  (gcc-config -l reports
> that stable x86_64-pc-linux-gnu-6.4.0 is the active compiler)
> 
> More surprising is that
>emerge --depclean --pretend sys-devel/gcc
> wants to remove everything *except* the testing/nonstable 7.3.0-r3
> 

gcc-7.3.0-r3 is stable, you probably updated your ::gentoo repository
without updating eix. Run eix-update and check again.

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

[allan gottlieb]

I run a stable system so am surprised to see that eix reports
I have gcc version ~7.3.0-r3 installed.  (gcc-config -l reports
that stable x86_64-pc-linux-gnu-6.4.0 is the active compiler)

More surprising is that
   emerge --depclean --pretend sys-devel/gcc
wants to remove everything *except* the testing/nonstable 7.3.0-r3

grep -r gcc /etc/portage
has no hits.

@system and several installed packages require gcc but all would be
satisfied by stable 6.4.0-r1 my active compiler

# emerge --depclean --verbose --pretend sys-devel/gcc

Calculating dependencies... done!
  sys-devel/gcc-7.3.0-r3 pulled in by:
@system requires sys-devel/gcc
dev-java/icedtea-bin-3.6.0 requires >=sys-devel/gcc-5.4.0
net-libs/webkit-gtk-2.20.4 requires >=sys-devel/gcc-4.9
sys-devel/llvm-4.0.1-r1 requires >=sys-devel/gcc-3.0
sys-devel/llvm-5.0.2 requires >=sys-devel/gcc-3.0
sys-devel/llvm-6.0.1 requires >=sys-devel/gcc-3.0
sys-libs/glibc-2.26-r7 requires >=sys-devel/gcc-4.9

>>> These are the packages that would be unmerged:

 sys-devel/gcc
selected: 4.9.3 4.9.4 5.4.0-r3 6.4.0-r1 
   protected: none 
 omitted: 7.3.0-r3 

Am I supposed to
   emerge --unmerge =sys-devel/gcc-7.3.0-r3
?

thanks in advance,
allan

PS I moved some months ago to the 17.0 profile and did the
make --emptytree @world

[gentoo-user] depclean confusion

[Walter Dnes]

  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

2) I've done "emerge --update --newuse --deep @world"

Total: 0 packages, Size of downloads: 0 KiB

3) I've done revdep-rebuild

Your system is consistent

  And "emerge --depclean" stills gives the same message.  I'm near the
end of the portion inside the chroot of the install process.  Will it
break the system if I unmerge iproute2, and then depclean, and then
revdep-rebuild?

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

Re: [gentoo-user] depclean missing packages

[Róbert Čerňanský]

On Wed, 4 Jan 2017 21:32:50 +0100
Arve Barsnes  wrote:

> On 4 January 2017 at 21:25, Daniel Frey  wrote:
> 
> > I always do `emerge -uDN world`. Which is --update --deep
> > --newuse... I've just never had that happen with depclean before.
> > Odd, no?
> >
> > I usually do:
> >
> > `emerge -uDN world`
> >
> > and
> >
> > `emerge -ac` to depclean afterwards.
> >
> > As I use --deep all the time, I'm still confused as to why needed
> > packages weren't installed.
> >
> >  
> I've also always used --deep, but I've seen this many times. I've
> recently started using "--with-bdeps=y" as well, and I don't think
> I've seen this happen since then, so I'm guessing binary deps are the
> culprit.

I think so too.  Since Dan does not use --with-bdeps this is what
might happen:

'qtdeclarative', 'qtxml' and 'qtcore' were updated from 5.6.1 to a
higher version.  However 'linguist-tools', being only a build
dependency, was not updated and remains at version 5.6.1.  Since
'linguist-tools-5.6.1' depends on 'qtdeclarative-5.6.1', 'qtxml-5.6.1'
and 'qtcore-5.6.1' --depclean resolves those as missing packages.

So as Arve is saying - using --with-bdeps should prevent this.  There
are two ways how to use it:

- As 'emerge -uDN --with-bdeps=y world' - in this case build
dependencies will be updated as well.

- As 'emerge -ac --with-bdeps=n' - in this case build dependencies
will be depcleaned (removed).  Notice there is 'n' in --with-bdeps.

I prefer second option since this leaves a clean system where only
packages required to run it are installed.  Disadvantage is that upon
next update the build dependencies are emerged again, so it takes more
time to update the system.

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk

Re: [gentoo-user] depclean missing packages

[Dale]

Alan McKinnon wrote:
> On 05/01/2017 06:46, Dale wrote:
>> Alan McKinnon wrote:
>>> On 04/01/2017 22:25, Daniel Frey wrote:
 On 01/04/2017 08:30 AM, Neil Bothwick wrote:
> On Wed, 4 Jan 2017 18:11:10 +0200, Alan McKinnon wrote:
>
>>> Using the --deep switch can / does pull in a lot of seemingly extra
>>> packages.  
>> --deep is practically *required* to do a full proper update.
>>
>> Say A is in world, and A depends on B which depends on C.
>> C is updated in the tree, and usually you will want C updated.
>>
>> However, update world will NOT update C.
>> Why? Because "world" is not a synonym for "everything",
>> "world" is something quite literal - the exact contents of
>> /var/lib/portage/world (and /var/lib/portage/world_sets if present)
>> "update world" updates that list only.
> That's not quite true, according to the man page. Without --deep portage
> considers only the specified files and their immediate dependencies
> (deps that are listed in the package's ebuild). So without --deep,
> updates to B as well a A would be picked up, but not C.
>
>> Adding --deep follows the
>> dependencies of the list, basically meaning
>>
>> "update --deep world" IS a synonym for "everything"
 I always do `emerge -uDN world`. Which is --update --deep --newuse...
 I've just never had that happen with depclean before. Odd, no?

 I usually do:

 `emerge -uDN world`

 and

 `emerge -ac` to depclean afterwards.

 As I use --deep all the time, I'm still confused as to why needed
 packages weren't installed.

 Dan

>>> s/I always do/I always do except this once when I forgot and then forgot
>>> that I forgot/g
>>>
>>>
>> This is why adding some options to make.conf is a good idea as you
>> already know.  I added -1 ages ago.  Why?  I would be trying to get a
>> update done and needed to do a few by hand and would forget the -1
>> option.  One can only imagine what the world file looked like.  lol 
>> Since I added -1 to make.conf, nothing has went into the world file that
>> I didn't add there on purpose.  Of course, one has to remember to use
>> --select y to add those new packages but in general, I may do that a few
>> times a year where I average updating about twice a week.  Plus, when
>> you do -a --depclean and it spits out the list, you will see it and slap
>> your forehead and then go add it if you really want to keep it around. 
>>
>> In all honesty, I can't imagine how a person can keep a Gentoo install
>> up to date without adding that or having a really crappy looking world
>> file.  ;-)
>>
>> I wonder why the -1 isn't there by default???  I would think it would be
>> a problem only when doing the initial install, when you want to add a
>> lot of packages to the world file since most likely, nothing is there. 
>> Just a thought. 
> -1 isn't there by default because the purpose of emerge is to build and
> install something, then remember you did it.
>
> What -1 does is build and install something then neglect to record you
> did it.
>
> -1 cannot ever possibly be a good default.
>
>


That's true but for the purpose I was speaking of, once your install is
done, most emerges then are either updates or trying to update doing one
package at a time, to avoid conflicts etc.  If I built a new rig and was
doing a fresh install, then I would want everything I install recorded
in the world file.  Once I get the install done and I'm to the point
that I'm mostly updating, I don't generally want individual packages
recorded. 

I see the point and during a install, no one would want that as a
default.  That's likely the reason it isn't. 

Dale

:-)  :-)

Re: [gentoo-user] depclean missing packages

[Alan McKinnon]

On 05/01/2017 06:46, Dale wrote:
> Alan McKinnon wrote:
>> On 04/01/2017 22:25, Daniel Frey wrote:
>>> On 01/04/2017 08:30 AM, Neil Bothwick wrote:
 On Wed, 4 Jan 2017 18:11:10 +0200, Alan McKinnon wrote:

>> Using the --deep switch can / does pull in a lot of seemingly extra
>> packages.  
> --deep is practically *required* to do a full proper update.
>
> Say A is in world, and A depends on B which depends on C.
> C is updated in the tree, and usually you will want C updated.
>
> However, update world will NOT update C.
> Why? Because "world" is not a synonym for "everything",
> "world" is something quite literal - the exact contents of
> /var/lib/portage/world (and /var/lib/portage/world_sets if present)
> "update world" updates that list only.
 That's not quite true, according to the man page. Without --deep portage
 considers only the specified files and their immediate dependencies
 (deps that are listed in the package's ebuild). So without --deep,
 updates to B as well a A would be picked up, but not C.

> Adding --deep follows the
> dependencies of the list, basically meaning
>
> "update --deep world" IS a synonym for "everything"

>>> I always do `emerge -uDN world`. Which is --update --deep --newuse...
>>> I've just never had that happen with depclean before. Odd, no?
>>>
>>> I usually do:
>>>
>>> `emerge -uDN world`
>>>
>>> and
>>>
>>> `emerge -ac` to depclean afterwards.
>>>
>>> As I use --deep all the time, I'm still confused as to why needed
>>> packages weren't installed.
>>>
>>> Dan
>>>
>> s/I always do/I always do except this once when I forgot and then forgot
>> that I forgot/g
>>
>>
> 
> This is why adding some options to make.conf is a good idea as you
> already know.  I added -1 ages ago.  Why?  I would be trying to get a
> update done and needed to do a few by hand and would forget the -1
> option.  One can only imagine what the world file looked like.  lol 
> Since I added -1 to make.conf, nothing has went into the world file that
> I didn't add there on purpose.  Of course, one has to remember to use
> --select y to add those new packages but in general, I may do that a few
> times a year where I average updating about twice a week.  Plus, when
> you do -a --depclean and it spits out the list, you will see it and slap
> your forehead and then go add it if you really want to keep it around. 
> 
> In all honesty, I can't imagine how a person can keep a Gentoo install
> up to date without adding that or having a really crappy looking world
> file.  ;-)
> 
> I wonder why the -1 isn't there by default???  I would think it would be
> a problem only when doing the initial install, when you want to add a
> lot of packages to the world file since most likely, nothing is there. 
> Just a thought. 

-1 isn't there by default because the purpose of emerge is to build and
install something, then remember you did it.

What -1 does is build and install something then neglect to record you
did it.

-1 cannot ever possibly be a good default.


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

Re: [gentoo-user] depclean missing packages

[Dale]

Alan McKinnon wrote:
> On 04/01/2017 22:25, Daniel Frey wrote:
>> On 01/04/2017 08:30 AM, Neil Bothwick wrote:
>>> On Wed, 4 Jan 2017 18:11:10 +0200, Alan McKinnon wrote:
>>>
> Using the --deep switch can / does pull in a lot of seemingly extra
> packages.  
 --deep is practically *required* to do a full proper update.

 Say A is in world, and A depends on B which depends on C.
 C is updated in the tree, and usually you will want C updated.

 However, update world will NOT update C.
 Why? Because "world" is not a synonym for "everything",
 "world" is something quite literal - the exact contents of
 /var/lib/portage/world (and /var/lib/portage/world_sets if present)
 "update world" updates that list only.
>>> That's not quite true, according to the man page. Without --deep portage
>>> considers only the specified files and their immediate dependencies
>>> (deps that are listed in the package's ebuild). So without --deep,
>>> updates to B as well a A would be picked up, but not C.
>>>
 Adding --deep follows the
 dependencies of the list, basically meaning

 "update --deep world" IS a synonym for "everything"
>>>
>> I always do `emerge -uDN world`. Which is --update --deep --newuse...
>> I've just never had that happen with depclean before. Odd, no?
>>
>> I usually do:
>>
>> `emerge -uDN world`
>>
>> and
>>
>> `emerge -ac` to depclean afterwards.
>>
>> As I use --deep all the time, I'm still confused as to why needed
>> packages weren't installed.
>>
>> Dan
>>
> s/I always do/I always do except this once when I forgot and then forgot
> that I forgot/g
>
>

This is why adding some options to make.conf is a good idea as you
already know.  I added -1 ages ago.  Why?  I would be trying to get a
update done and needed to do a few by hand and would forget the -1
option.  One can only imagine what the world file looked like.  lol 
Since I added -1 to make.conf, nothing has went into the world file that
I didn't add there on purpose.  Of course, one has to remember to use
--select y to add those new packages but in general, I may do that a few
times a year where I average updating about twice a week.  Plus, when
you do -a --depclean and it spits out the list, you will see it and slap
your forehead and then go add it if you really want to keep it around. 

In all honesty, I can't imagine how a person can keep a Gentoo install
up to date without adding that or having a really crappy looking world
file.  ;-)

I wonder why the -1 isn't there by default???  I would think it would be
a problem only when doing the initial install, when you want to add a
lot of packages to the world file since most likely, nothing is there. 
Just a thought. 

Dale

:-)  :-) 

Re: [gentoo-user] depclean missing packages

[Alan McKinnon]

On 04/01/2017 22:32, Arve Barsnes wrote:
> On 4 January 2017 at 21:25, Daniel Frey  > wrote:
> 
> I always do `emerge -uDN world`. Which is --update --deep --newuse...
> I've just never had that happen with depclean before. Odd, no?
> 
> I usually do:
> 
> `emerge -uDN world`
> 
> and
> 
> `emerge -ac` to depclean afterwards.
> 
> As I use --deep all the time, I'm still confused as to why needed
> packages weren't installed.
> 
> 
> I've also always used --deep, but I've seen this many times. I've
> recently started using "--with-bdeps=y" as well, and I don't think I've
> seen this happen since then, so I'm guessing binary deps are the culprit.
> 
> Arve
> 


bdeps are not binary deps, they are build deps.

And Qt will never be a build-dep in this case. cmake maybe but Qt no

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

Re: [gentoo-user] depclean missing packages

[Alan McKinnon]

On 04/01/2017 22:25, Daniel Frey wrote:
> On 01/04/2017 08:30 AM, Neil Bothwick wrote:
>> On Wed, 4 Jan 2017 18:11:10 +0200, Alan McKinnon wrote:
>>
 Using the --deep switch can / does pull in a lot of seemingly extra
 packages.  
>>>
>>> --deep is practically *required* to do a full proper update.
>>>
>>> Say A is in world, and A depends on B which depends on C.
>>> C is updated in the tree, and usually you will want C updated.
>>>
>>> However, update world will NOT update C.
>>> Why? Because "world" is not a synonym for "everything",
>>> "world" is something quite literal - the exact contents of
>>> /var/lib/portage/world (and /var/lib/portage/world_sets if present)
>>
>>> "update world" updates that list only.
>>
>> That's not quite true, according to the man page. Without --deep portage
>> considers only the specified files and their immediate dependencies
>> (deps that are listed in the package's ebuild). So without --deep,
>> updates to B as well a A would be picked up, but not C.
>>
>>> Adding --deep follows the
>>> dependencies of the list, basically meaning
>>>
>>> "update --deep world" IS a synonym for "everything"
>>
>>
> 
> I always do `emerge -uDN world`. Which is --update --deep --newuse...
> I've just never had that happen with depclean before. Odd, no?
> 
> I usually do:
> 
> `emerge -uDN world`
> 
> and
> 
> `emerge -ac` to depclean afterwards.
> 
> As I use --deep all the time, I'm still confused as to why needed
> packages weren't installed.
> 
> Dan
> 

s/I always do/I always do except this once when I forgot and then forgot
that I forgot/g


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

Re: [gentoo-user] depclean missing packages

[Arve Barsnes]

On 4 January 2017 at 21:25, Daniel Frey  wrote:

> I always do `emerge -uDN world`. Which is --update --deep --newuse...
> I've just never had that happen with depclean before. Odd, no?
>
> I usually do:
>
> `emerge -uDN world`
>
> and
>
> `emerge -ac` to depclean afterwards.
>
> As I use --deep all the time, I'm still confused as to why needed
> packages weren't installed.
>
>
I've also always used --deep, but I've seen this many times. I've recently
started using "--with-bdeps=y" as well, and I don't think I've seen this
happen since then, so I'm guessing binary deps are the culprit.

Arve

Re: [gentoo-user] depclean missing packages

[Daniel Frey]

On 01/04/2017 08:30 AM, Neil Bothwick wrote:
> On Wed, 4 Jan 2017 18:11:10 +0200, Alan McKinnon wrote:
> 
>>> Using the --deep switch can / does pull in a lot of seemingly extra
>>> packages.  
>>
>> --deep is practically *required* to do a full proper update.
>>
>> Say A is in world, and A depends on B which depends on C.
>> C is updated in the tree, and usually you will want C updated.
>>
>> However, update world will NOT update C.
>> Why? Because "world" is not a synonym for "everything",
>> "world" is something quite literal - the exact contents of
>> /var/lib/portage/world (and /var/lib/portage/world_sets if present)
> 
>> "update world" updates that list only.
> 
> That's not quite true, according to the man page. Without --deep portage
> considers only the specified files and their immediate dependencies
> (deps that are listed in the package's ebuild). So without --deep,
> updates to B as well a A would be picked up, but not C.
> 
>> Adding --deep follows the
>> dependencies of the list, basically meaning
>>
>> "update --deep world" IS a synonym for "everything"
> 
> 

I always do `emerge -uDN world`. Which is --update --deep --newuse...
I've just never had that happen with depclean before. Odd, no?

I usually do:

`emerge -uDN world`

and

`emerge -ac` to depclean afterwards.

As I use --deep all the time, I'm still confused as to why needed
packages weren't installed.

Dan

Re: [gentoo-user] depclean missing packages

[Neil Bothwick]

On Wed, 4 Jan 2017 18:11:10 +0200, Alan McKinnon wrote:

> > Using the --deep switch can / does pull in a lot of seemingly extra
> > packages.  
> 
> --deep is practically *required* to do a full proper update.
> 
> Say A is in world, and A depends on B which depends on C.
> C is updated in the tree, and usually you will want C updated.
> 
> However, update world will NOT update C.
> Why? Because "world" is not a synonym for "everything",
> "world" is something quite literal - the exact contents of
> /var/lib/portage/world (and /var/lib/portage/world_sets if present)

> "update world" updates that list only.

That's not quite true, according to the man page. Without --deep portage
considers only the specified files and their immediate dependencies
(deps that are listed in the package's ebuild). So without --deep,
updates to B as well a A would be picked up, but not C.

> Adding --deep follows the
> dependencies of the list, basically meaning
> 
> "update --deep world" IS a synonym for "everything"


-- 
Neil Bothwick

O.K. I'm weird, but I'm saving up to become eccentric.


pgpuWMTcdg3Fm.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] depclean missing packages

[Alan McKinnon]

On 04/01/2017 18:06, Corbin Bird wrote:
> 
> On 01/03/2017 02:42 PM, Daniel Frey wrote:
>> So, for the first time I've seen the following message after an `emerge
>> -uDN world`:
>>
>>
>> # emerge -cp
>>
>>  * Always study the list of packages to be cleaned for any obvious
>>  * mistakes. Packages that are part of the world set will always
>>  * be kept.  They can be manually added to this set with
>>  * `emerge --noreplace `.  Packages that are listed in
>>  * package.provided (see portage(5)) will be removed by
>>  * depclean, even if they are part of the world set.
>>  *
>>  * As a safety measure, depclean will not remove any packages
>>  * unless *all* required dependencies have been resolved.  As a
>>  * consequence of this, it often becomes necessary to run
>>  * `emerge --update --newuse --deep @world` prior to depclean.
>>
>> Calculating dependencies... done!
>>  * Dependencies could not be completely resolved due to
>>  * the following required packages not being installed:
>>  *
>>  *   ~dev-qt/qtdeclarative-5.6.1 pulled in by:
>>  * dev-qt/linguist-tools-5.6.1
>>  *
>>  *   ~dev-qt/qtxml-5.6.1 pulled in by:
>>  * dev-qt/linguist-tools-5.6.1
>>  *
>>  *   ~dev-qt/qtcore-5.6.1 pulled in by:
>>  * dev-qt/linguist-tools-5.6.1
>>  *
>>  * Have you forgotten to do a complete update prior to depclean? The
>>  * most comprehensive command for this purpose is as follows:
>>  *
>>  *   emerge --update --newuse --deep --with-bdeps=y @world
>>  *
>>  * Note that the --with-bdeps=y option is not required in many
>>  * situations. Refer to the emerge manual page (run `man emerge`)
>>  * for more information about --with-bdeps.
>>  *
>>  * 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.
>>
>> What I don't understand is why these packages were not installed in the
>> first place. Should this be reported as a bug? I've ran an update with
>> --with-bdeps as suggested and it's telling me 20 packages are missing
>> from my system! (And is currently installing them.)
>>
>> What I don't understand is I've been updating and depcleaning for more
>> than a decade and haven't seen that message before. Am I just lucky?
>>
>> Dan
>>
> 
> One switch makes all the difference : --deep
> 
> I have not been getting that error message.
> What I have been using  : emerge --update --tree --newuse --deep
> --with-bdeps=y @world
> 
> Using the --deep switch can / does pull in a lot of seemingly extra
> packages.

--deep is practically *required* to do a full proper update.

Say A is in world, and A depends on B which depends on C.
C is updated in the tree, and usually you will want C updated.

However, update world will NOT update C.
Why? Because "world" is not a synonym for "everything",
"world" is something quite literal - the exact contents of
/var/lib/portage/world (and /var/lib/portage/world_sets if present)

"update world" updates that list only. Adding --deep follows the
dependencies of the list, basically meaning

"update --deep world" IS a synonym for "everything"


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

Re: [gentoo-user] depclean missing packages

[Corbin Bird]

On 01/03/2017 02:42 PM, Daniel Frey wrote:
> So, for the first time I've seen the following message after an `emerge
> -uDN world`:
>
>
> # emerge -cp
>
>  * Always study the list of packages to be cleaned for any obvious
>  * mistakes. Packages that are part of the world set will always
>  * be kept.  They can be manually added to this set with
>  * `emerge --noreplace `.  Packages that are listed in
>  * package.provided (see portage(5)) will be removed by
>  * depclean, even if they are part of the world set.
>  *
>  * As a safety measure, depclean will not remove any packages
>  * unless *all* required dependencies have been resolved.  As a
>  * consequence of this, it often becomes necessary to run
>  * `emerge --update --newuse --deep @world` prior to depclean.
>
> Calculating dependencies... done!
>  * Dependencies could not be completely resolved due to
>  * the following required packages not being installed:
>  *
>  *   ~dev-qt/qtdeclarative-5.6.1 pulled in by:
>  * dev-qt/linguist-tools-5.6.1
>  *
>  *   ~dev-qt/qtxml-5.6.1 pulled in by:
>  * dev-qt/linguist-tools-5.6.1
>  *
>  *   ~dev-qt/qtcore-5.6.1 pulled in by:
>  * dev-qt/linguist-tools-5.6.1
>  *
>  * Have you forgotten to do a complete update prior to depclean? The
>  * most comprehensive command for this purpose is as follows:
>  *
>  *   emerge --update --newuse --deep --with-bdeps=y @world
>  *
>  * Note that the --with-bdeps=y option is not required in many
>  * situations. Refer to the emerge manual page (run `man emerge`)
>  * for more information about --with-bdeps.
>  *
>  * 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.
>
> What I don't understand is why these packages were not installed in the
> first place. Should this be reported as a bug? I've ran an update with
> --with-bdeps as suggested and it's telling me 20 packages are missing
> from my system! (And is currently installing them.)
>
> What I don't understand is I've been updating and depcleaning for more
> than a decade and haven't seen that message before. Am I just lucky?
>
> Dan
>

One switch makes all the difference : --deep

I have not been getting that error message.
What I have been using  : emerge --update --tree --newuse --deep
--with-bdeps=y @world

Using the --deep switch can / does pull in a lot of seemingly extra
packages.

Hope this helps.

Re: [gentoo-user] depclean missing packages

[Arve Barsnes]

On 3 January 2017 at 21:42, Daniel Frey  wrote:

> What I don't understand is I've been updating and depcleaning for more
> than a decade and haven't seen that message before. Am I just lucky?
>

Yes.

I've seen this many times.

Arve

[gentoo-user] depclean missing packages

[Daniel Frey]

So, for the first time I've seen the following message after an `emerge
-uDN world`:


# emerge -cp

 * Always study the list of packages to be cleaned for any obvious
 * mistakes. Packages that are part of the world set will always
 * be kept.  They can be manually added to this set with
 * `emerge --noreplace `.  Packages that are listed in
 * package.provided (see portage(5)) will be removed by
 * depclean, even if they are part of the world set.
 *
 * As a safety measure, depclean will not remove any packages
 * unless *all* required dependencies have been resolved.  As a
 * consequence of this, it often becomes necessary to run
 * `emerge --update --newuse --deep @world` prior to depclean.

Calculating dependencies... done!
 * Dependencies could not be completely resolved due to
 * the following required packages not being installed:
 *
 *   ~dev-qt/qtdeclarative-5.6.1 pulled in by:
 * dev-qt/linguist-tools-5.6.1
 *
 *   ~dev-qt/qtxml-5.6.1 pulled in by:
 * dev-qt/linguist-tools-5.6.1
 *
 *   ~dev-qt/qtcore-5.6.1 pulled in by:
 * dev-qt/linguist-tools-5.6.1
 *
 * Have you forgotten to do a complete update prior to depclean? The
 * most comprehensive command for this purpose is as follows:
 *
 *   emerge --update --newuse --deep --with-bdeps=y @world
 *
 * Note that the --with-bdeps=y option is not required in many
 * situations. Refer to the emerge manual page (run `man emerge`)
 * for more information about --with-bdeps.
 *
 * 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.

What I don't understand is why these packages were not installed in the
first place. Should this be reported as a bug? I've ran an update with
--with-bdeps as suggested and it's telling me 20 packages are missing
from my system! (And is currently installing them.)

What I don't understand is I've been updating and depcleaning for more
than a decade and haven't seen that message before. Am I just lucky?

Dan

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

[Neil Bothwick]

On Sat, 14 Mar 2015 16:39:58 + (UTC), James wrote:

 Ok, so I use this syntax (in make.conf) to protect gentoo-source
 kernels, as I like to keep kernel codes around for quite a while:
 
 EMERGE_DEFAULT_OPTS=--exclude gentoo-sources
 
 It works just fine.
 
 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.
 
 I have not been able to find a way to (inside of make.conf)
 to prevent these dev-java/* ebuild removals.

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


-- 
Neil Bothwick

For security reasons, all text in this mail
  is double-rot13 encrypted.


pgpNHHOKlIHkA.pgp
Description: OpenPGP digital signature

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

[James]

Howdy,

Ok, so I use this syntax (in make.conf) to protect gentoo-source kernels,
as I like to keep kernel codes around for quite a while:

EMERGE_DEFAULT_OPTS=--exclude gentoo-sources

It works just fine.

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.

I have not been able to find a way to (inside of make.conf)
to prevent these dev-java/* ebuild removals.


Insight, discussion and syntax snippents are all welcome, that will
allow me to protect *java* from depclean.



James

Re: [gentoo-user] depclean wants to remove all perl?

[Dale]

Mick wrote:
 On Thursday 31 Jul 2014 06:14:56 J. Roeleveld wrote:

 I always check the list from depclean to see if there is any package and/or
 version that I am actually using. If yes, I add it to the world file.
 (Emerge --noreplace)
 I don't add packages to my world file, let alone specific versions, unless I 
 want them to be there.  I let portage manage versions and dependencies.

If you don't add anything to your world file, how do you keep anything
installed and updated?  Unless you just use sets, which is basically the
same thing as putting a package in world, then it should be in the world
file. 

There are times when versions are required tho.  I know I do that for my
kernel.  I always keep my current kernel and my backup kernel version at
least.  Every once in a while, I go through and clean them manually. 

For some people, there may be other packages that need to be done that
way.  One of those your mileage may vary type things.  ;-)

Dale

:-)  :-) 

Re: [gentoo-user] depclean wants to remove all perl?

[Alan McKinnon]

On 31/07/2014 10:12, Dale wrote:
 Mick wrote:
 On Thursday 31 Jul 2014 06:14:56 J. Roeleveld wrote:

 I always check the list from depclean to see if there is any package and/or
 version that I am actually using. If yes, I add it to the world file.
 (Emerge --noreplace)
 I don't add packages to my world file, let alone specific versions, unless I 
 want them to be there.  I let portage manage versions and dependencies.
 
 If you don't add anything to your world file, how do you keep anything
 installed and updated?  Unless you just use sets, which is basically the
 same thing as putting a package in world, then it should be in the world
 file. 
 
 There are times when versions are required tho.  I know I do that for my
 kernel.  I always keep my current kernel and my backup kernel version at
 least.  Every once in a while, I go through and clean them manually. 
 
 For some people, there may be other packages that need to be done that
 way.  One of those your mileage may vary type things.  ;-)
 
 Dale
 
 :-)  :-) 
 
 
 

I think Mick means more that he doesn't like adding libs and modules and
plugins to world, and doesn't mean the actual apps.

So he would add a music player to world, and let portage plus USE figure
out which of the 500 odd bits of gstreamer to pull in and install



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

Re: [gentoo-user] depclean wants to remove all perl?

[J. Roeleveld]

On Thursday, July 31, 2014 06:48:01 AM Mick wrote:
 On Thursday 31 Jul 2014 06:14:56 J. Roeleveld wrote:
  I always check the list from depclean to see if there is any package
  and/or
  version that I am actually using. If yes, I add it to the world file.
  (Emerge --noreplace)
 
 I don't add packages to my world file, let alone specific versions, unless I
 want them to be there.  I let portage manage versions and 
dependencies.

That's what I said as well.
Please note, I mentioned  that I am actually using .

This includes:
- programs I use
- kernel
- libraries I need for my own projects
- dependencies for software that isn't in the portage tree
  (I should create a meta-package for those)

--
Joost

Re: [gentoo-user] depclean wants to remove all perl?

[Dale]

Alan McKinnon wrote:
 On 31/07/2014 10:12, Dale wrote:
 Mick wrote:
 On Thursday 31 Jul 2014 06:14:56 J. Roeleveld wrote:

 I always check the list from depclean to see if there is any package and/or
 version that I am actually using. If yes, I add it to the world file.
 (Emerge --noreplace)
 I don't add packages to my world file, let alone specific versions, unless 
 I 
 want them to be there.  I let portage manage versions and dependencies.
 If you don't add anything to your world file, how do you keep anything
 installed and updated?  Unless you just use sets, which is basically the
 same thing as putting a package in world, then it should be in the world
 file. 

 There are times when versions are required tho.  I know I do that for my
 kernel.  I always keep my current kernel and my backup kernel version at
 least.  Every once in a while, I go through and clean them manually. 

 For some people, there may be other packages that need to be done that
 way.  One of those your mileage may vary type things.  ;-)

 Dale

 :-)  :-) 



 I think Mick means more that he doesn't like adding libs and modules and
 plugins to world, and doesn't mean the actual apps.

 So he would add a music player to world, and let portage plus USE figure
 out which of the 500 odd bits of gstreamer to pull in and install




Ahhh.  OK.  I was curious because when something is installed, it has to
be recorded somewhere for it to get updated etc.  Running emerge
--depclean would be interesting too. 

Thanks for kicking me into gear.  ;-)

Dale

:-)  :-) 

Re: [gentoo-user] depclean wants to remove all perl?

[Mick]

On Thursday 31 Jul 2014 09:25:03 J. Roeleveld wrote:
 On Thursday, July 31, 2014 06:48:01 AM Mick wrote:
  On Thursday 31 Jul 2014 06:14:56 J. Roeleveld wrote:
   I always check the list from depclean to see if there is any package
   and/or
   version that I am actually using. If yes, I add it to the world file.
   (Emerge --noreplace)
  
  I don't add packages to my world file, let alone specific versions,
  unless I want them to be there.  I let portage manage versions and
 
 dependencies.
 
 That's what I said as well.
 Please note, I mentioned  that I am actually using .
 
 This includes:
 - programs I use
 - kernel
 - libraries I need for my own projects
 - dependencies for software that isn't in the portage tree
   (I should create a meta-package for those)

Right, yes, we are in agreement.  I misread what you wrote.  In my case I 
don't have a requirement for my own libraries or dependencies - I don't 
develop anything of note other than the odd kludge of a script.  So portage 
drags in what it needs and my world only has applications that I have 
explicitly installed.

-- 
Regards,
Mick


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

Re: [gentoo-user] depclean wants to remove all perl?

[Neil Bothwick]

On Thu, 31 Jul 2014 10:25:03 +0200, J. Roeleveld wrote:

 This includes:
 - programs I use
 - kernel
 - libraries I need for my own projects
 - dependencies for software that isn't in the portage tree
   (I should create a meta-package for those)

I use sets for the last one, just list the packages
in /etc/portage/sets/foo_deps and emerge -a @foo_deps. It makes
cleaning up afterwards a lot easier, just remove the set.


-- 
Neil Bothwick

Theory is when you know everything, but nothing works.
Reality is when everything works, but you don't know why.
However, usually theory and reality are mixed together :
Nothing works, and nobody knows why not.


signature.asc
Description: PGP signature

[gentoo-user] depclean wants to remove all perl?

[Mick]

Having updated some perl packages, I ran perl-cleaner which failed with some 
blockers, I ran:

emerge --deselect --ask $(qlist -IC 'perl-core/*')

emerge -uD1a $(qlist -IC 'virtual/perl-*')

as advised by perl-cleaner, before I ran perl-cleaner successfully.

Following all this depclean give me a lng list of perl packages, but I am 
reluctant to hit yes, before I confirm that this correct:
 

 These are the packages that would be unmerged:

 perl-core/Module-Load-Conditional
selected: 0.540.0 
   protected: none 
 omitted: none 

 virtual/perl-ExtUtils-Install
selected: 1.590.0-r1 
   protected: none 
 omitted: none 

 virtual/perl-ExtUtils-Command
selected: 1.170.0-r5 
   protected: none 
 omitted: none 

 perl-core/Archive-Tar
selected: 1.900.0-r1 
   protected: none 
 omitted: none 

 perl-core/File-Spec
selected: 3.400.0 
   protected: none 
 omitted: none 

 perl-core/Time-Local
selected: 1.230.0-r1 
   protected: none 
 omitted: none 

 perl-core/CPAN-Meta-Requirements
selected: 2.122.0-r1 
   protected: none 
 omitted: none 

 perl-core/Test-Harness
selected: 3.260.0 
   protected: none 
 omitted: none 

 virtual/perl-Module-Load-Conditional
selected: 0.540.0-r1 
   protected: none 
 omitted: none 

 perl-core/ExtUtils-ParseXS
selected: 3.180.0-r1 
   protected: none 
 omitted: none 

 perl-core/IO-Compress
selected: 2.60.0 
   protected: none 
 omitted: none 

 perl-core/CPAN-Meta
selected: 2.120.921-r1 
   protected: none 
 omitted: none 

 perl-core/Compress-Raw-Bzip2
selected: 2.60.0 
   protected: none 
 omitted: none 

 perl-core/Parse-CPAN-Meta
selected: 1.440.400-r1 
   protected: none 
 omitted: none 

 perl-core/Params-Check
selected: 0.360.0-r1 
   protected: none 
 omitted: none 

 perl-core/Module-Load
selected: 0.240.0 
   protected: none 
 omitted: none 

 perl-core/Scalar-List-Utils
selected: 1.270.0 
   protected: none 
 omitted: none 

 perl-core/Module-Build
selected: 0.400.300-r1 
   protected: none 
 omitted: none 

 perl-core/Compress-Raw-Zlib
selected: 2.60.0 
   protected: none 
 omitted: none 

 perl-core/Digest-MD5
selected: 2.520.0-r1 
   protected: none 
 omitted: none 

 virtual/perl-IPC-Cmd
selected: 0.800.0-r1 
   protected: none 
 omitted: none 

 perl-core/CPAN-Meta-YAML
selected: 0.8.0-r1 
   protected: none 
 omitted: none 

 perl-core/Module-Metadata
selected: 1.0.11-r1 
   protected: none 
 omitted: none 

 virtual/perl-ExtUtils-Manifest
selected: 1.630.0-r1 
   protected: none 
 omitted: none 

 virtual/perl-ExtUtils-ParseXS
selected: 3.180.0-r2 
   protected: none 
 omitted: none 

 virtual/perl-IO-Zlib
selected: 1.100.0-r4 
   protected: none 
 omitted: none 

 virtual/perl-Test-Harness
selected: 3.260.0-r2 
   protected: none 
 omitted: none 

 virtual/perl-Module-CoreList
selected: 3.30.0 
   protected: none 
 omitted: none 

 virtual/perl-Module-Load
selected: 0.240.0-r1 
   protected: none 
 omitted: none 

 virtual/perl-Params-Check
selected: 0.360.0-r1 
   protected: none 
 omitted: none 

 virtual/perl-Compress-Raw-Bzip2
selected: 2.60.0-r2 
   protected: none 
 omitted: none 

 virtual/perl-Package-Constants
selected: 0.20.0-r4 
   protected: none 
 omitted: none 

 virtual/perl-File-Temp
selected: 0.230.0 
   protected: none 
 omitted: none 

 virtual/perl-CPAN-Meta-Requirements
selected: 2.122.0-r2 
   protected: none 
 omitted: none 

 virtual/perl-Test-Simple
selected: 0.980.0-r5 
   protected: none 
 omitted: none 

 virtual/perl-Digest
selected: 1.170.0-r3 
   protected: none 
 omitted: none 

 virtual/perl-Perl-OSType
selected: 1.3.0-r1 
   protected: none 
 omitted: none 

 virtual/perl-Archive-Tar
selected: 1.900.0-r2 
   protected: none 
 omitted: none 

 virtual/perl-CPAN-Meta
selected: 2.120.921-r2 
   protected: none 
 omitted: none 

 virtual/perl-Locale-Maketext-Simple
selected: 0.210.0-r4 
   protected: none 
 omitted: none 

 virtual/perl-Module-Metadata
selected: 1.0.11-r1 
   protected: none 
 omitted: none 

 virtual/perl-ExtUtils-CBuilder
selected: 0.280.210-r1 
   protected: none 
 omitted: none 

 virtual/perl-Parse-CPAN-Meta
selected: 1.440.400-r1 
   protected: none 
 omitted: none 

 virtual/perl-JSON-PP
selected: 2.272.20-r1 
   protected: none 
 omitted: none 

 virtual/perl-CPAN-Meta-YAML
selected: 0.8.0-r2 
   protected: none 
 omitted: none 

 virtual/perl-version
selected: 0.990.200-r1 
   protected: none 
 omitted: none 

All selected packages: virtual/perl-CPAN-Meta-2.120.921-r2 virtual/perl-
Package-Constants-0.20.0-r4 perl-core/Compress-Raw-Bzip2-2.60.0 virtual/perl-
Module-Metadata-1.0.11-r1 virtual/perl-Archive-Tar-1.900.0-r2 perl-

Re: [gentoo-user] depclean wants to remove all perl?

[Alan McKinnon]

On 30/07/2014 23:47, Mick wrote:
 Having updated some perl packages, I ran perl-cleaner which failed with some 
 blockers, I ran:
 
 emerge --deselect --ask $(qlist -IC 'perl-core/*')
 
 emerge -uD1a $(qlist -IC 'virtual/perl-*')
 
 as advised by perl-cleaner, before I ran perl-cleaner successfully.
 
 Following all this depclean give me a lng list of perl packages, but I am 
 reluctant to hit yes, before I confirm that this correct:


It's very likely safe:

http://dilfridge.blogspot.com/2014/07/perl-in-gentoo-dev-langperl-virtuals.html

I'm quite sure that whole list is now bundled with perl itself so
there's no need to have the modules as well.

Do read the link above and check your main perl version













  
 
 These are the packages that would be unmerged:
 
  perl-core/Module-Load-Conditional
 selected: 0.540.0 
protected: none 
  omitted: none 
 
  virtual/perl-ExtUtils-Install
 selected: 1.590.0-r1 
protected: none 
  omitted: none 
 
  virtual/perl-ExtUtils-Command
 selected: 1.170.0-r5 
protected: none 
  omitted: none 
 
  perl-core/Archive-Tar
 selected: 1.900.0-r1 
protected: none 
  omitted: none 
 
  perl-core/File-Spec
 selected: 3.400.0 
protected: none 
  omitted: none 
 
  perl-core/Time-Local
 selected: 1.230.0-r1 
protected: none 
  omitted: none 
 
  perl-core/CPAN-Meta-Requirements
 selected: 2.122.0-r1 
protected: none 
  omitted: none 
 
  perl-core/Test-Harness
 selected: 3.260.0 
protected: none 
  omitted: none 
 
  virtual/perl-Module-Load-Conditional
 selected: 0.540.0-r1 
protected: none 
  omitted: none 
 
  perl-core/ExtUtils-ParseXS
 selected: 3.180.0-r1 
protected: none 
  omitted: none 
 
  perl-core/IO-Compress
 selected: 2.60.0 
protected: none 
  omitted: none 
 
  perl-core/CPAN-Meta
 selected: 2.120.921-r1 
protected: none 
  omitted: none 
 
  perl-core/Compress-Raw-Bzip2
 selected: 2.60.0 
protected: none 
  omitted: none 
 
  perl-core/Parse-CPAN-Meta
 selected: 1.440.400-r1 
protected: none 
  omitted: none 
 
  perl-core/Params-Check
 selected: 0.360.0-r1 
protected: none 
  omitted: none 
 
  perl-core/Module-Load
 selected: 0.240.0 
protected: none 
  omitted: none 
 
  perl-core/Scalar-List-Utils
 selected: 1.270.0 
protected: none 
  omitted: none 
 
  perl-core/Module-Build
 selected: 0.400.300-r1 
protected: none 
  omitted: none 
 
  perl-core/Compress-Raw-Zlib
 selected: 2.60.0 
protected: none 
  omitted: none 
 
  perl-core/Digest-MD5
 selected: 2.520.0-r1 
protected: none 
  omitted: none 
 
  virtual/perl-IPC-Cmd
 selected: 0.800.0-r1 
protected: none 
  omitted: none 
 
  perl-core/CPAN-Meta-YAML
 selected: 0.8.0-r1 
protected: none 
  omitted: none 
 
  perl-core/Module-Metadata
 selected: 1.0.11-r1 
protected: none 
  omitted: none 
 
  virtual/perl-ExtUtils-Manifest
 selected: 1.630.0-r1 
protected: none 
  omitted: none 
 
  virtual/perl-ExtUtils-ParseXS
 selected: 3.180.0-r2 
protected: none 
  omitted: none 
 
  virtual/perl-IO-Zlib
 selected: 1.100.0-r4 
protected: none 
  omitted: none 
 
  virtual/perl-Test-Harness
 selected: 3.260.0-r2 
protected: none 
  omitted: none 
 
  virtual/perl-Module-CoreList
 selected: 3.30.0 
protected: none 
  omitted: none 
 
  virtual/perl-Module-Load
 selected: 0.240.0-r1 
protected: none 
  omitted: none 
 
  virtual/perl-Params-Check
 selected: 0.360.0-r1 
protected: none 
  omitted: none 
 
  virtual/perl-Compress-Raw-Bzip2
 selected: 2.60.0-r2 
protected: none 
  omitted: none 
 
  virtual/perl-Package-Constants
 selected: 0.20.0-r4 
protected: none 
  omitted: none 
 
  virtual/perl-File-Temp
 selected: 0.230.0 
protected: none 
  omitted: none 
 
  virtual/perl-CPAN-Meta-Requirements
 selected: 2.122.0-r2 
protected: none 
  omitted: none 
 
  virtual/perl-Test-Simple
 selected: 0.980.0-r5 
protected: none 
  omitted: none 
 
  virtual/perl-Digest
 selected: 1.170.0-r3 
protected: none 
  omitted: none 
 
  virtual/perl-Perl-OSType
 selected: 1.3.0-r1 
protected: none 
  omitted: none 
 
  virtual/perl-Archive-Tar
 selected: 1.900.0-r2 
protected: none 
  omitted: none 
 
  virtual/perl-CPAN-Meta
 selected: 2.120.921-r2 
protected: none 
  omitted: none 
 
  virtual/perl-Locale-Maketext-Simple
 selected: 0.210.0-r4 
protected: none 
  omitted: none 
 
  virtual/perl-Module-Metadata
 selected: 1.0.11-r1 
protected: none 
  omitted: none 
 
  virtual/perl-ExtUtils-CBuilder
 selected: 0.280.210-r1 
protected: none 
  omitted: none 
 
  virtual/perl-Parse-CPAN-Meta
 selected: 1.440.400-r1 

Re: [gentoo-user] depclean wants to remove all perl?

[Kerin Millar]

On 30/07/2014 22:58, Alan McKinnon wrote:

On 30/07/2014 23:47, Mick wrote:

Having updated some perl packages, I ran perl-cleaner which failed with some
blockers, I ran:

emerge --deselect --ask $(qlist -IC 'perl-core/*')

emerge -uD1a $(qlist -IC 'virtual/perl-*')

as advised by perl-cleaner, before I ran perl-cleaner successfully.

Following all this depclean give me a lng list of perl packages, but I am
reluctant to hit yes, before I confirm that this correct:



It's very likely safe:

http://dilfridge.blogspot.com/2014/07/perl-in-gentoo-dev-langperl-virtuals.html

I'm quite sure that whole list is now bundled with perl itself so
there's no need to have the modules as well.


Everything except for IO::Compress and Scalar::List::Utils. I concur; 
nothing about this list appears surprising.


--Kerin

Re: [gentoo-user] depclean wants to remove all perl?

[Mick]

On Wednesday 30 Jul 2014 23:02:38 Kerin Millar wrote:
 On 30/07/2014 22:58, Alan McKinnon wrote:
  On 30/07/2014 23:47, Mick wrote:
  Having updated some perl packages, I ran perl-cleaner which failed with
  some blockers, I ran:
  
  emerge --deselect --ask $(qlist -IC 'perl-core/*')
  
  emerge -uD1a $(qlist -IC 'virtual/perl-*')
  
  as advised by perl-cleaner, before I ran perl-cleaner successfully.
  
  Following all this depclean give me a lng list of perl packages, but
  I am
  
  reluctant to hit yes, before I confirm that this correct:
  It's very likely safe:
  
  http://dilfridge.blogspot.com/2014/07/perl-in-gentoo-dev-langperl-virtual
  s.html
  
  I'm quite sure that whole list is now bundled with perl itself so
  there's no need to have the modules as well.
 
 Everything except for IO::Compress and Scalar::List::Utils. I concur;
 nothing about this list appears surprising.
 
 --Kerin

Thank you both!

I am on dev-lang/perl-5.18.2-r1

-- 
Regards,
Mick


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

Re: [gentoo-user] depclean wants to remove all perl?

[Kerin Millar]

On 30/07/2014 23:12, Mick wrote:

On Wednesday 30 Jul 2014 23:02:38 Kerin Millar wrote:

On 30/07/2014 22:58, Alan McKinnon wrote:

On 30/07/2014 23:47, Mick wrote:

Having updated some perl packages, I ran perl-cleaner which failed with
some blockers, I ran:

emerge --deselect --ask $(qlist -IC 'perl-core/*')

emerge -uD1a $(qlist -IC 'virtual/perl-*')

as advised by perl-cleaner, before I ran perl-cleaner successfully.

Following all this depclean give me a lng list of perl packages, but
I am



reluctant to hit yes, before I confirm that this correct:

It's very likely safe:

http://dilfridge.blogspot.com/2014/07/perl-in-gentoo-dev-langperl-virtual
s.html

I'm quite sure that whole list is now bundled with perl itself so
there's no need to have the modules as well.


Everything except for IO::Compress and Scalar::List::Utils. I concur;
nothing about this list appears surprising.

--Kerin


Thank you both!

I am on dev-lang/perl-5.18.2-r1


As Perl 5.16 is EOL, perhaps that's no bad thing. Incidentally, you can 
check whether a module is part of the Perl core by using the corelist tool.


$ corelist Archive::Tar
Archive::Tar was first released with perl v5.9.3

--Kerin

Re: [gentoo-user] depclean wants to remove all perl?

[J. Roeleveld]

On 30 July 2014 23:47:19 CEST, Mick michaelkintz...@gmail.com wrote:
Having updated some perl packages, I ran perl-cleaner which failed with
some 
blockers, I ran:

emerge --deselect --ask $(qlist -IC 'perl-core/*')

emerge -uD1a $(qlist -IC 'virtual/perl-*')

as advised by perl-cleaner, before I ran perl-cleaner successfully.

Following all this depclean give me a lng list of perl packages,
but I am 
reluctant to hit yes, before I confirm that this correct:
 

 These are the packages that would be unmerged:

 perl-core/Module-Load-Conditional
selected: 0.540.0 
   protected: none 
 omitted: none 

 virtual/perl-ExtUtils-Install
selected: 1.590.0-r1 
   protected: none 
 omitted: none 

 virtual/perl-ExtUtils-Command
selected: 1.170.0-r5 
   protected: none 
 omitted: none 

 perl-core/Archive-Tar
selected: 1.900.0-r1 
   protected: none 
 omitted: none 

 perl-core/File-Spec
selected: 3.400.0 
   protected: none 
 omitted: none 

 perl-core/Time-Local
selected: 1.230.0-r1 
   protected: none 
 omitted: none 

 perl-core/CPAN-Meta-Requirements
selected: 2.122.0-r1 
   protected: none 
 omitted: none 

 perl-core/Test-Harness
selected: 3.260.0 
   protected: none 
 omitted: none 

 virtual/perl-Module-Load-Conditional
selected: 0.540.0-r1 
   protected: none 
 omitted: none 

 perl-core/ExtUtils-ParseXS
selected: 3.180.0-r1 
   protected: none 
 omitted: none 

 perl-core/IO-Compress
selected: 2.60.0 
   protected: none 
 omitted: none 

 perl-core/CPAN-Meta
selected: 2.120.921-r1 
   protected: none 
 omitted: none 

 perl-core/Compress-Raw-Bzip2
selected: 2.60.0 
   protected: none 
 omitted: none 

 perl-core/Parse-CPAN-Meta
selected: 1.440.400-r1 
   protected: none 
 omitted: none 

 perl-core/Params-Check
selected: 0.360.0-r1 
   protected: none 
 omitted: none 

 perl-core/Module-Load
selected: 0.240.0 
   protected: none 
 omitted: none 

 perl-core/Scalar-List-Utils
selected: 1.270.0 
   protected: none 
 omitted: none 

 perl-core/Module-Build
selected: 0.400.300-r1 
   protected: none 
 omitted: none 

 perl-core/Compress-Raw-Zlib
selected: 2.60.0 
   protected: none 
 omitted: none 

 perl-core/Digest-MD5
selected: 2.520.0-r1 
   protected: none 
 omitted: none 

 virtual/perl-IPC-Cmd
selected: 0.800.0-r1 
   protected: none 
 omitted: none 

 perl-core/CPAN-Meta-YAML
selected: 0.8.0-r1 
   protected: none 
 omitted: none 

 perl-core/Module-Metadata
selected: 1.0.11-r1 
   protected: none 
 omitted: none 

 virtual/perl-ExtUtils-Manifest
selected: 1.630.0-r1 
   protected: none 
 omitted: none 

 virtual/perl-ExtUtils-ParseXS
selected: 3.180.0-r2 
   protected: none 
 omitted: none 

 virtual/perl-IO-Zlib
selected: 1.100.0-r4 
   protected: none 
 omitted: none 

 virtual/perl-Test-Harness
selected: 3.260.0-r2 
   protected: none 
 omitted: none 

 virtual/perl-Module-CoreList
selected: 3.30.0 
   protected: none 
 omitted: none 

 virtual/perl-Module-Load
selected: 0.240.0-r1 
   protected: none 
 omitted: none 

 virtual/perl-Params-Check
selected: 0.360.0-r1 
   protected: none 
 omitted: none 

 virtual/perl-Compress-Raw-Bzip2
selected: 2.60.0-r2 
   protected: none 
 omitted: none 

 virtual/perl-Package-Constants
selected: 0.20.0-r4 
   protected: none 
 omitted: none 

 virtual/perl-File-Temp
selected: 0.230.0 
   protected: none 
 omitted: none 

 virtual/perl-CPAN-Meta-Requirements
selected: 2.122.0-r2 
   protected: none 
 omitted: none 

 virtual/perl-Test-Simple
selected: 0.980.0-r5 
   protected: none 
 omitted: none 

 virtual/perl-Digest
selected: 1.170.0-r3 
   protected: none 
 omitted: none 

 virtual/perl-Perl-OSType
selected: 1.3.0-r1 
   protected: none 
 omitted: none 

 virtual/perl-Archive-Tar
selected: 1.900.0-r2 
   protected: none 
 omitted: none 

 virtual/perl-CPAN-Meta
selected: 2.120.921-r2 
   protected: none 
 omitted: none 

 virtual/perl-Locale-Maketext-Simple
selected: 0.210.0-r4 
   protected: none 
 omitted: none 

 virtual/perl-Module-Metadata
selected: 1.0.11-r1 
   protected: none 
 omitted: none 

 virtual/perl-ExtUtils-CBuilder
selected: 0.280.210-r1 
   protected: none 
 omitted: none 

 virtual/perl-Parse-CPAN-Meta
selected: 1.440.400-r1 
   protected: none 
 omitted: none 

 virtual/perl-JSON-PP
selected: 2.272.20-r1 
   protected: none 
 omitted: none 

 virtual/perl-CPAN-Meta-YAML
selected: 0.8.0-r2 
   protected: none 
 omitted: none 

 virtual/perl-version
selected: 0.990.200-r1 
   protected: none 
 omitted: none 

All selected packages: virtual/perl-CPAN-Meta-2.120.921-r2
virtual/perl-
Package-Constants-0.20.0-r4 perl-core/Compress-Raw-Bzip2-2.60.0
virtual/perl-

Re: [gentoo-user] depclean wants to remove all perl?

[Mick]

On Thursday 31 Jul 2014 06:14:56 J. Roeleveld wrote:

 I always check the list from depclean to see if there is any package and/or
 version that I am actually using. If yes, I add it to the world file.
 (Emerge --noreplace)

I don't add packages to my world file, let alone specific versions, unless I 
want them to be there.  I let portage manage versions and dependencies.
-- 
Regards,
Mick


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

[gentoo-user] depclean asking to remove *many* perl

[Allan Gottlieb]

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.

thanks,
allan

 These are the packages that would be unmerged:

 app-text/libspectre
selected: 0.2.6 
   protected: none 
 omitted: none 

 dev-perl/Module-Install
selected: 1.60.0 
   protected: none 
 omitted: none 

 dev-libs/boost
selected: 1.48.0-r2 
   protected: none 
 omitted: 1.49.0-r1 

 dev-perl/PAR-Dist
selected: 0.480.0 
   protected: none 
 omitted: none 

 dev-perl/File-Remove
selected: 1.520.0 
   protected: none 
 omitted: none 

 dev-perl/YAML-Tiny
selected: 1.510.0 
   protected: none 
 omitted: none 

 dev-perl/JSON
selected: 2.530.0 
   protected: none 
 omitted: none 

 dev-perl/Module-ScanDeps
selected: 1.80.0 
   protected: none 
 omitted: none 

 dev-util/boost-build
selected: 1.48.0-r1 
   protected: none 
 omitted: 1.49.0 

 dev-perl/LWP-Protocol-https
selected: 6.30.0 
   protected: none 
 omitted: none 

 dev-perl/libwww-perl
selected: 6.40.0 
   protected: none 
 omitted: none 

 dev-perl/WWW-RobotRules
selected: 6.10.0 
   protected: none 
 omitted: none 

 dev-perl/HTTP-Cookies
selected: 6.0.1 
   protected: none 
 omitted: none 

 dev-perl/HTTP-Daemon
selected: 6.10.0 
   protected: none 
 omitted: none 

 dev-perl/HTTP-Negotiate
selected: 6.0.1 
   protected: none 
 omitted: none 

 dev-perl/File-Listing
selected: 6.40.0 
   protected: none 
 omitted: none 

 dev-perl/Net-HTTP
selected: 6.30.0 
   protected: none 
 omitted: none 

 dev-perl/HTTP-Message
selected: 6.30.0 
   protected: none 
 omitted: none 

 virtual/perl-Encode
selected: 2.440.0 
   protected: none 
 omitted: none 

 dev-perl/Encode-Locale
selected: 1.30.0 
   protected: none 
 omitted: none 

 dev-perl/HTML-Parser
selected: 3.690.0 
   protected: none 
 omitted: none 

 dev-perl/LWP-MediaTypes
selected: 6.20.0 
   protected: none 
 omitted: none 

 dev-perl/URI
selected: 1.600.0 
   protected: none 
 omitted: none 

 dev-perl/HTTP-Date
selected: 6.20.0 
   protected: none 
 omitted: none 

 dev-perl/HTML-Tagset
selected: 3.200.0 
   protected: none 
 omitted: none 

 perl-core/Encode
selected: 2.440.0 
   protected: none 
 omitted: none 

 virtual/perl-Time-Local
selected: 1.200.0-r1 
   protected: none 
 omitted: none 

 perl-core/Time-Local
selected: 1.200.0 
   protected: none 
 omitted: none 

[gentoo-user] depclean stopped working

[Nikos Chantziaras]

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)

Re: [gentoo-user] depclean stopped working

[Alan McKinnon]

On Tue, 17 Apr 2012 18:01:43 +0300
Nikos Chantziaras rea...@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





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

Re: [gentoo-user] --depclean wants to remove much of java. Is this safe?

[Jonathan]

On Sun, 11 Sep 2011 02:26:35 -0400
Philip Webb purs...@ca.inter.net wrote:

 I recently removed Java from my system: all I seem to have lost
 is direct access to the help files in LibreOffice,
 which have a fully adequate PDF substitute.

The offlinehelp flag is now in the libreoffice-l10n ebuild. I use Libreoffice 
with the java flag disabled and my offline help works fine.

Re: [gentoo-user] --depclean wants to remove much of java. Is this safe?

[Allan Gottlieb]

On Tue, Sep 13 2011, Jonathan wrote:

 On Sun, 11 Sep 2011 02:26:35 -0400
 Philip Webb purs...@ca.inter.net wrote:

 I recently removed Java from my system: all I seem to have lost
 is direct access to the help files in LibreOffice,
 which have a fully adequate PDF substitute.

 The offlinehelp flag is now in the libreoffice-l10n ebuild. I use
 Libreoffice with the java flag disabled and my offline help works
 fine.

thanks,
allan

Re: [gentoo-user] --depclean wants to remove much of java. Is this safe?

[Philip Webb]

110910 Allan Gottlieb wrote:
 I converted two machines from icedtea (java6) to oracle-jdk-bin (java7).
 I did in effect
  emerge --depclean icedtea icedtea-web =virtual/jdk-1.6.0 =virtual/jdk-1.6.0
 On one machine portage now claims that I basically don't need java
 (see the output of --depclean below).  Can this be right?
 
  dev-java/ant-nodeps
 selected: 1.8.1 
protected: none 
  omitted: none 

*** remainder snipped ***

I recently removed Java from my system: all I seem to have lost
is direct access to the help files in LibreOffice,
which have a fully adequate PDF substitute.

You can check each package in your list with 'emerge -cpv pkg'
 see what it says requires it: if they only support one another,
you can fairly safely remove them all.

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

Re: [gentoo-user] --depclean wants to remove much of java. Is this safe?

[Allan Gottlieb]

On Sun, Sep 11 2011, Philip Webb wrote:

 110910 Allan Gottlieb wrote:
 I converted two machines from icedtea (java6) to oracle-jdk-bin (java7).
 I did in effect
  emerge --depclean icedtea icedtea-web =virtual/jdk-1.6.0 =virtual/jdk-1.6.0
 On one machine portage now claims that I basically don't need java
 (see the output of --depclean below).  Can this be right?
 
  dev-java/ant-nodeps
 selected: 1.8.1 
protected: none 
  omitted: none 

 *** remainder snipped ***

 I recently removed Java from my system: all I seem to have lost
 is direct access to the help files in LibreOffice,
 which have a fully adequate PDF substitute.

 You can check each package in your list with 'emerge -cpv pkg'
  see what it says requires it: if they only support one another,
 you can fairly safely remove them all.

Thanks.  I did the check and then let depclean remove them.
allan

[gentoo-user] --depclean wants to remove much of java. Is this safe?

[Allan Gottlieb]

I converted two machines from icedtea (java6) to oracle-jdk-bin
(java7).

I did in effect

 emerge --depclean icedtea icedtea-web =virtual/jdk-1.6.0 =virtual/jdk-1.6.0

On one machine portage now claims that I basically don't need java (see
the output of --depclean below).  Can this be right?  More importantly,
I believe it is safe to do the suggested unmerges (i.e. I could always
remerge them) since

1.  None of these are in system
2.  Portage itself doesn't use java

Am I correct that letting the unmerge happen is reversible.

thanks,
allan



oldlap ~ # emerge --ignore-default-opts --pretend --depclean

 * Depclean may break link level dependencies. Thus, it is
 * recommended to use a tool such as `revdep-rebuild` (from
 * app-portage/gentoolkit) in order to detect such breakage.
 * 
 * Always study the list of packages to be cleaned for any obvious
 * mistakes. Packages that are part of the world set will always
 * be kept.  They can be manually added to this set with
 * `emerge --noreplace atom`.  Packages that are listed in
 * package.provided (see portage(5)) will be removed by
 * depclean, even if they are part of the world set.
 * 
 * As a safety measure, depclean will not remove any packages
 * unless *all* required dependencies have been resolved.  As a
 * consequence, it is often necessary to run `emerge --update
 * --newuse --deep @world` prior to depclean.

Calculating dependencies... done!
 Calculating removal order...

 These are the packages that would be unmerged:

 dev-java/ant-nodeps
selected: 1.8.1 
   protected: none 
 omitted: none 

 dev-libs/libgee
selected: 0.6.1 
   protected: none 
 omitted: 0.7.0 

 net-print/gutenprint
selected: 5.2.7 
   protected: none 
 omitted: none 

 dev-java/xalan
selected: 2.7.1 
   protected: none 
 omitted: none 

 dev-java/bcel
selected: 5.2-r2 
   protected: none 
 omitted: none 

 dev-java/javacup
selected: 0.11a_beta20060608 
   protected: none 
 omitted: none 

 dev-java/xerces
selected: 2.9.1 
   protected: none 
 omitted: none 

 dev-java/xjavac
selected: 20041208-r5 
   protected: none 
 omitted: none 

 dev-java/xml-commons-resolver
selected: 1.2 
   protected: none 
 omitted: none 

 dev-java/xalan-serializer
selected: 2.7.1 
   protected: none 
 omitted: none 

 dev-java/xml-commons-external
selected: 1.3.04 
   protected: none 
 omitted: none 

 dev-java/ant-core
selected: 1.8.1 
   protected: none 
 omitted: none 

 dev-java/javatoolkit
selected: 0.3.0-r6 
   protected: none 
 omitted: none 

 virtual/jre
selected: 1.7.0 
   protected: none 
 omitted: none 

 virtual/jdk
selected: 1.7.0 
   protected: none 
 omitted: none 

 dev-java/oracle-jdk-bin
selected: 1.7.0 
   protected: none 
 omitted: none 

 dev-java/java-config
selected: 2.1.11-r3 
   protected: none 
 omitted: none 

 dev-java/java-config-wrapper
selected: 0.16 
   protected: none 
 omitted: none 

All selected packages: dev-java/java-config-2.1.11-r3 
net-print/gutenprint-5.2.7 dev-java/xml-commons-external-1.3.04 
dev-java/xml-commons-resolver-1.2 dev-java/javacup-0.11a_beta20060608 
dev-java/ant-nodeps-1.8.1 dev-java/xerces-2.9.1 dev-java/bcel-5.2-r2 
dev-java/xalan-2.7.1 dev-java/ant-core-1.8.1 dev-java/oracle-jdk-bin-1.7.0 
dev-libs/libgee-0.6.1 dev-java/javatoolkit-0.3.0-r6 virtual/jre-1.7.0 
dev-java/xalan-serializer-2.7.1 dev-java/xjavac-20041208-r5 virtual/jdk-1.7.0 
dev-java/java-config-wrapper-0.16

 'Selected' packages are slated for removal.
 'Protected' and 'omitted' packages will not be removed.

Packages installed:   966
Packages in world:143
Packages in system:   45
Required packages:948
Number to remove: 18
oldlap ~ # 

[gentoo-user] depclean after kde-4.6 upgrade

[Mick]

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?
-- 
Regards,
Mick


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

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

[Paul Hartman]

On Wed, May 11, 2011 at 4:28 PM, Mick michaelkintz...@gmail.com wrote:
 Having completed the upgrade I noticed that a few packages are being called up
 for removal:

 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?

If you add --tree to your emerge command you can see what's pulling it
in. I think it might be a dependency of kdevelop.

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

[netfab]

Le 02/02/11 à 01:23, Dale a tapoté :
 Is this a bug or am I missing something, again.  ;-)
 

 Bug #353362 : http://bugs.gentoo.org/353362

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

[Dale]

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

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

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 kB

Nothing to merge; would you like to auto-clean packages? [Yes/No] y
 Auto-cleaning packages...

 No outdated packages were found on your system.
root@fireball / #

So, nothing needs to be updated but yet --depclean complains about the 
package not being installed.  Here is the kicker:


root@fireball / # emerge -pv media-sound/phonon x11-libs/qt-webkit

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

Calculating dependencies... done!
[ebuild   R   ] media-sound/phonon-4.4.4  USE=vlc -debug -gstreamer 
-pulseaudio -xine 0 kB
[ebuild   R   ] x11-libs/qt-webkit-4.7.1-r1  USE=dbus exceptions jit 
kde (-aqua) -debug -pch 0 kB


Total: 2 packages (2 reinstalls), Size of downloads: 0 kB
root@fireball / #

Yep, it's installed.  Just for good measure, I rebuilt them with -1 and 
it installed them just fine.  Same message as before tho.  Still 
complains that a package is not installed.


Is this a bug or am I missing something, again.  ;-)

Dale

:-)  :-)

Re: [gentoo-user] depclean wants to remove hal, which kills xdm

[Allan Gottlieb]

Dale rdalek1...@gmail.com writes:

 Le 20 décembre à 15:12 Allan Gottlieb a écrit
  
 Something seems wrong.
 Yesterday depclean removed hal and then xdm wouldn't run.
 Re-merging hal (with -1) fixed this, but again today depclean wants to
 remove it.

 I'm running amd64 here but xdm doesn't show it needing hal here.  It's
 not even in the USE flags and I did a emerge -epv xdm and it still
 didn't show it.  It did pull in policykit tho.

 Could it be that it doesn't use hal anymore and you need to figure out
 what it is using?  I know hal is going away but I haven't read that it
 already was.  That said, I did notice that policykit was pulled in
 yesterday.  Of course, xdm doesn't show it needs it either.  Could it
 be udev?

To summarize

1.  All is running fine but.

2.  deplcean wants to remove hal and when it does xdm will not run.

3.  I have run emerge world with --newuse, and have run revdep-rebuild,
and have remerged xdm.

4.  Currently I just refuse depclean's offer to remove hal, halinfo, and
dmidecode.

My plan is to stay like this until xorg 1.9 hits ~amd64 since I believe
at that time hal is going away and hence xdm won't need it.

Does this sound reasonable?

allan

PS  Why is no one else having this problem?

Re: [gentoo-user] depclean wants to remove hal, which kills xdm

[Mark Knecht]

On Tue, Dec 21, 2010 at 6:41 AM, Allan Gottlieb gottl...@nyu.edu wrote:
SNIP

 To summarize

 1.  All is running fine but.

 2.  deplcean wants to remove hal and when it does xdm will not run.

 3.  I have run emerge world with --newuse, and have run revdep-rebuild,
    and have remerged xdm.

 4.  Currently I just refuse depclean's offer to remove hal, halinfo, and
    dmidecode.

 My plan is to stay like this until xorg 1.9 hits ~amd64 since I believe
 at that time hal is going away and hence xdm won't need it.

 Does this sound reasonable?


To me, yes. If you make a mistake and depclean hal by mistake then it
seems you can get it back in.

 allan

 PS  Why is no one else having this problem?

I don't use xdm?

Granted, it seems my current state is a bit strange. There is a lot of
stuff on my system that says it depends on hal, but then again i don't
start it explicitly. Other things apparently do however:

c2stable ~ # equery depends hal
[ Searching for packages depending on hal... ]
app-cdr/k3b-2.0.0 (sys-apps/hal)
app-emulation/vmware-workstation-7.1.2.301548 (sys-apps/hal)
app-misc/hal-info-20090716 (=sys-apps/hal-0.5.10)
gnome-base/gnome-applets-2.30.0-r1 (battstat  hal? =sys-apps/hal-0.5.3)
gnome-base/gnome-vfs-2.24.3-r1 (hal? =sys-apps/hal-0.5.7)
gnome-base/gvfs-1.6.4-r2 (hal? =sys-apps/hal-0.5.10)
gnome-extra/gnome-power-manager-2.30.1 (hal? =sys-apps/hal-0.5.9)
kde-base/solid-4.4.5 (hal? sys-apps/hal)
media-libs/libgphoto2-2.4.9 (hal? =sys-apps/hal-0.5)
x11-base/xorg-server-1.7.7-r1 (hal? sys-apps/hal)
x11-drivers/xf86-input-virtualbox-3.2.12 (hal? sys-apps/hal)
xfce-base/exo-0.3.107 (hal? sys-apps/hal)
xfce-base/thunar-1.0.2 (hal? sys-apps/hal)
c2stable ~ # rc-update show
bootmisc | boot
 checkfs | boot
   checkroot | boot
   clock | boot
 consolefont | boot
dbus |  default
hostname | boot
 keymaps | boot
   local |  default nonetwork
  localmount | boot
 modules | boot
net.eth0 |  default
  net.lo | boot
netmount |  default
  ntp-client |  default
ntpd |  default
   rmnologin | boot
sshd |  default
   syslog-ng |  default
  udev-postmount |  default
 urandom | boot
  vixie-cron |  default
  vmware |  default
 xdm |  default
c2stable ~ # /etc/init.d/hald status
 * status:  started
c2stable ~ #

   I sort of figure that one of these days I'll see what I can build
that uses it today without it and then see how things go. In the short
terms it's sort of 'it ain't broke so...'

Note that I don't 'try' to use hal. It just shows up. I don't ask for
it in package.use and it's supposedly disabled in make.conf. Ah, the
mysteries of Life... ;-)

c2stable ~ # cat /etc/portage/package.use | grep hal
c2stable ~ # cat /etc/make.conf | grep hal
USE=nptl nptlonly -ipv6 fortran unicode -hal dbus X -bluetooth
-esound -timidity -cups -java gnome gstreamer kde qt4 qt3support -arts
-eds pngi policykit
c2stable ~ #

Cheers,
Mark

Re: [gentoo-user] depclean wants to remove hal, which kills xdm

[Dale]

Allan Gottlieb wrote:

Dalerdalek1...@gmail.com  writes:

   

Le 20 décembre à 15:12 Allan Gottlieb a écrit

 

Something seems wrong.
Yesterday depclean removed hal and then xdm wouldn't run.
Re-merging hal (with -1) fixed this, but again today depclean wants to
remove it.
   

I'm running amd64 here but xdm doesn't show it needing hal here.  It's
not even in the USE flags and I did a emerge -epv xdm and it still
didn't show it.  It did pull in policykit tho.

Could it be that it doesn't use hal anymore and you need to figure out
what it is using?  I know hal is going away but I haven't read that it
already was.  That said, I did notice that policykit was pulled in
yesterday.  Of course, xdm doesn't show it needs it either.  Could it
be udev?
 

To summarize

1.  All is running fine but.

2.  deplcean wants to remove hal and when it does xdm will not run.

3.  I have run emerge world with --newuse, and have run revdep-rebuild,
 and have remerged xdm.

4.  Currently I just refuse depclean's offer to remove hal, halinfo, and
 dmidecode.

My plan is to stay like this until xorg 1.9 hits ~amd64 since I believe
at that time hal is going away and hence xdm won't need it.

Does this sound reasonable?

allan

PS  Why is no one else having this problem?

   


Well, if it helps any, I'm already running xorg 1.9.  Here is my list:

[I--] [ ~] x11-base/xorg-drivers-1.9 (0)
[I--] [ ~] x11-base/xorg-server-1.9.2.902 (0)

They are working fine here so you may want to just go ahead and 
upgrade.  This is the settings for mine here:


[ebuild   R   ] x11-base/xorg-server-1.9.2.902  USE=ipv6 nptl udev xorg 
-dmx -doc -kdrive -minimal -static-libs -tslib 0 kB


It uses udev instead of hal.  I didn't have to run a unstable version of 
udev either.


I'm sure it is some sort of setting somewhere but no idea why you are 
the only one running into this.


Dale

:-)  :-)

Re: [gentoo-user] depclean wants to remove hal, which kills xdm

[Helmut Jarausch]

On 12/21/10 15:41:20, Allan Gottlieb wrote:
 My plan is to stay like this until xorg 1.9 hits ~amd64 since I

It is already unmasked in ~amd64 (It's running just fine here)

Helmut.

Re: [gentoo-user] depclean wants to remove hal, which kills xdm

[Mike Edenfield]

On 12/21/2010 9:41 AM, Allan Gottlieb wrote:

 To summarize
 
 1.  All is running fine but.
 
 2.  deplcean wants to remove hal and when it does xdm will not run.

Is it just xdm that doesn't run?  That is, if you disable xdm and log in
via the console, can you run startx?

It's possible that your Xorg configuration is relying on some device or
setting that HAL is providing for you but udev itself isn't.  (Can't
think of anything specific offhand, though).  If this were the case,
trying to run X by itself as root should also fail.  You would also see
the errors in your Xorg.0.log file, pointing to whichever device is the
problem.

To fix this, you'd need to find and remove the offending device
reference.  A good first start is to try simply removing any xorg.conf
you happen to have lying around and let X try to find everything itself
(without HAL).

--Mike

Re: [gentoo-user] depclean wants to remove hal, which kills xdm

[Allan Gottlieb]

Helmut Jarausch jarau...@igpm.rwth-aachen.de writes:

 On 12/21/10 15:41:20, Allan Gottlieb wrote:
 My plan is to stay like this until xorg 1.9 hits ~amd64 since I

 It is already unmasked in ~amd64 (It's running just fine here)

Bingo.  There was a mesa problem a while ago (7.8.2) that caused me to
mask =media-libs/mesa-7.8.2.  This caused me to mask xorg-server above
the current running one.  I didn't notice that mesa did advance and I am
running 7.9-r1.  So I just now unmasked both mesa and xorg-server and
update world updated xorg-server and xinit.

Let's see if this now permits me to let depclean remove hal.

thank you all for your help!

allan

[gentoo-user] depclean wants to remove hal, which kills xdm

[Allan Gottlieb]

Something seems wrong.
Yesterday depclean removed hal and then xdm wouldn't run.
Re-merging hal (with -1) fixed this, but again today depclean wants to
remove it.

I can easily add hal to world, but should xdm depend on it?

allan

Re: [gentoo-user] depclean wants to remove hal, which kills xdm

[Vincent-Xavier JUMEL]

Le 20 décembre à 15:12 Allan Gottlieb a écrit
 Something seems wrong.
 Yesterday depclean removed hal and then xdm wouldn't run.
 Re-merging hal (with -1) fixed this, but again today depclean wants to
 remove it.
 
Have you look on how X.org packages are built on your computer. You should build
it with udev support.

 I can easily add hal to world, but should xdm depend on it?
 
 allan
 

-- 
Vincent-Xavier JUMEL GPG Id: 0x2E14CE70 http://thetys-retz.net

Rejoignez les 5312 adhérents de l'April http://www.april.org/adherer
Parinux, logiciel libre à Paris : http://www.parinux.org

Re: [gentoo-user] depclean wants to remove hal, which kills xdm

[Allan Gottlieb]

Vincent-Xavier JUMEL endymion+gen...@thetys-retz.net writes:

 Le 20 décembre à 15:12 Allan Gottlieb a écrit
 Something seems wrong.
 Yesterday depclean removed hal and then xdm wouldn't run.
 Re-merging hal (with -1) fixed this, but again today depclean wants to
 remove it.
 
 Have you look on how X.org packages are built on your computer. You
 should build it with udev support.

I think it is enabled for xorg-server

gottl...@ajglap ~ $ eix xorg-server
[I] x11-base/xorg-server
 Available versions:  1.7.6 1.7.7-r1 [m](~)1.8.2 [m](~)1.9.2 
[m](~)1.9.2.902 {debug dmx doc hal ipv6 kdrive minimal nptl sdl static-libs 
tslib +udev xorg}
 Installed versions:  1.7.7-r1(09:59:41 AM 12/19/2010)(ipv6 kdrive nptl sdl 
xorg -debug -dmx -hal -minimal -tslib)
 Homepage:http://xorg.freedesktop.org/
 Description: X.Org X servers

To be sure I temporarily added it to make.conf but an emerge update
world did not want to merge any packages

 I can easily add hal to world, but should xdm depend on it?

I still wonder why xdm, which claims to need hal doesn't depend on it
and why suddenly depclean wants to remove it.

allan

Re: [gentoo-user] depclean wants to remove hal, which kills xdm

[J. Roeleveld]

On Monday 20 December 2010 15:55:40 Allan Gottlieb wrote:
 Vincent-Xavier JUMEL endymion+gen...@thetys-retz.net writes:
  Le 20 décembre à 15:12 Allan Gottlieb a écrit
  
  Something seems wrong.
  Yesterday depclean removed hal and then xdm wouldn't run.
  Re-merging hal (with -1) fixed this, but again today depclean wants to
  remove it.
  
  Have you look on how X.org packages are built on your computer. You
  should build it with udev support.
 
 I think it is enabled for xorg-server
 
 gottl...@ajglap ~ $ eix xorg-server
 [I] x11-base/xorg-server
  Available versions:  1.7.6 1.7.7-r1 [m](~)1.8.2 [m](~)1.9.2
 [m](~)1.9.2.902 {debug dmx doc hal ipv6 kdrive minimal nptl sdl
 static-libs tslib +udev xorg} Installed versions:  1.7.7-r1(09:59:41 AM
 12/19/2010)(ipv6 kdrive nptl sdl xorg -debug -dmx -hal -minimal -tslib)
 Homepage:http://xorg.freedesktop.org/
  Description: X.Org X servers

**
Installed versions:  1.7.7-r1(09:59:41 AM 12/19/2010)(ipv6 kdrive nptl sdl 
xorg -debug -dmx -hal -minimal -tslib)
**

It's installed with hal disabled.

 To be sure I temporarily added it to make.conf but an emerge update
 world did not want to merge any packages

Add --newuse to the flags and it should pick it up:
emerge -vauD --newuse world

  I can easily add hal to world, but should xdm depend on it?
 
 I still wonder why xdm, which claims to need hal doesn't depend on it
 and why suddenly depclean wants to remove it.

See above, hal isn't added to the installed xorg-server use-flags

--
Joost

Re: [gentoo-user] depclean wants to remove hal, which kills xdm

[Dale]

Allan Gottlieb wrote:

Vincent-Xavier JUMELendymion+gen...@thetys-retz.net  writes:

   

Le 20 décembre à 15:12 Allan Gottlieb a écrit
 

Something seems wrong.
Yesterday depclean removed hal and then xdm wouldn't run.
Re-merging hal (with -1) fixed this, but again today depclean wants to
remove it.

   

Have you look on how X.org packages are built on your computer. You
should build it with udev support.
 

I think it is enabled for xorg-server

gottl...@ajglap ~ $ eix xorg-server
[I] x11-base/xorg-server
  Available versions:  1.7.6 1.7.7-r1 [m](~)1.8.2 [m](~)1.9.2 
[m](~)1.9.2.902 {debug dmx doc hal ipv6 kdrive minimal nptl sdl static-libs 
tslib +udev xorg}
  Installed versions:  1.7.7-r1(09:59:41 AM 12/19/2010)(ipv6 kdrive nptl 
sdl xorg -debug -dmx -hal -minimal -tslib)
  Homepage:http://xorg.freedesktop.org/
  Description: X.Org X servers

To be sure I temporarily added it to make.conf but an emerge update
world did not want to merge any packages

   

I can easily add hal to world, but should xdm depend on it?
   

I still wonder why xdm, which claims to need hal doesn't depend on it
and why suddenly depclean wants to remove it.

allan

   


I'm running amd64 here but xdm doesn't show it needing hal here.  It's 
not even in the USE flags and I did a emerge -epv xdm and it still 
didn't show it.  It did pull in policykit tho.


Could it be that it doesn't use hal anymore and you need to figure out 
what it is using?  I know hal is going away but I haven't read that it 
already was.  That said, I did notice that policykit was pulled in 
yesterday.  Of course, xdm doesn't show it needs it either.  Could it be 
udev?


I hope this gives you ideas.

Dale

:-)  :-)

Re: [gentoo-user] depclean wants to remove hal, which kills xdm

[Mike Edenfield]

On 12/20/2010 10:04 AM, J. Roeleveld wrote:

 Le 20 décembre à 15:12 Allan Gottlieb a écrit

 Something seems wrong.
 Yesterday depclean removed hal and then xdm wouldn't run.
 Re-merging hal (with -1) fixed this, but again today depclean wants to
 remove it.

 Installed versions:  1.7.7-r1(09:59:41 AM 12/19/2010)(ipv6 kdrive nptl sdl 
 xorg -debug -dmx -hal -minimal -tslib)
 **
 
 It's installed with hal disabled.

And, you should probably leave it that way.  HAL is going away, so
there's no point in rebuilding X just to get HAL support now.  You
should start by just rebuilding XDM and see if it's HAL requirement goes
away.  You could also try a good revdep-rebuild, though I'm not sure HAL
is a link-time dependency that will get picked up that way.

--Mike

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

[Neil Bothwick]

On Sat, 31 Oct 2009 16:42:49 -0700, Mark Knecht wrote:

Earlier today emerge --depclean wouldn't remove db because 3
 programs needed it so I rebuilt the 3 programs but it's still
 complaining about php. Sometimes I'll just remove the problem package
 - like db in this case - and then let an emerge -DuN @world /
 revdep-rebuild fix it, but I wanted to be careful with db as it might
 be important to portage or eix.
 
What's the right way to fix this?

The way you normally do, unmerge that specific db package then re-emerge
the packages that depended on it. Or, as suggested elsewhere, get rid of
the berkdb USE flag.


-- 
Neil Bothwick

Voting Democrat or Republican is like choosing a cabin in the Titanic.


signature.asc
Description: PGP signature

[gentoo-user] depclean / db php loop

[Mark Knecht]

Hi,
   Earlier today emerge --depclean wouldn't remove db because 3
programs needed it so I rebuilt the 3 programs but it's still
complaining about php. Sometimes I'll just remove the problem package
- like db in this case - and then let an emerge -DuN @world /
revdep-rebuild fix it, but I wanted to be careful with db as it might
be important to portage or eix.

   What's the right way to fix this?

   If it matters this is a PPC Mac Mini used as a MythTV backend
server. revdep-rebuild -ip says everything is clean and emerge -DuN
@system @world is finished.

Thanks in advance,
Mark


 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-4.6.21_p4 pulled in by:
 * dev-lang/php-5.2.11 needs libdb-4.6.so
 *
 Adding lib providers to graph...   |
Calculating dependencies... done!
 No packages selected for removal by depclean
 To see reverse dependencies, use --verbose
Packages installed:   353
Packages in world:35
Packages in system:   52
Required packages:353
Number to remove: 0
MacMini ~ # emerge -pv php

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

Calculating dependencies... done!
[ebuild   R   ] dev-lang/php-5.2.11  USE=apache2 berkdb bzip2 cgi cli
crypt gd gdbm iconv ldap mysql mysqli ncurses nls pcre posix readline
reflection session spell spl ssl truetype unicode xml zlib (-adabas)
-bcmath (-birdstep) -calendar -cdb -cjk -concurrentmodphp -ctype -curl
-curlwrappers (-db2) -dbase (-dbmaker) -debug -discard-path -doc
(-empress) (-empress-bcs) (-esoob) -exif -fastbuild (-fdftk) -filter
(-firebird) -flatfile -force-cgi-redirect (-frontbase) -ftp
-gd-external -gmp -hash -imap -inifile (-interbase) -iodbc -ipv6
(-java-external) -json -kerberos -kolab -ldap-sasl -libedit -mcve
-mhash -msql -mssql (-oci8) (-oci8-instant-client) -odbc -pcntl -pdo
-pic -postgres -qdbm -recode -sapdb -sharedext -sharedmem -simplexml
-snmp -soap -sockets (-solid) -sqlite -suhosin (-sybase) (-sybase-ct)
-sysvipc -threads -tidy -tokenizer -wddx -xmlreader -xmlrpc -xmlwriter
-xpm -xsl -yaz -zip 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB
MacMini ~ #

[gentoo-user] depclean wants to remove xorg-server and xf86-video-intel

[Grant]

depclean wants to remove xorg-server and xf86-video-intel and I'm a
bit scared to do that.  Does anyone know what might be going on there?

 x11-base/xorg-server
selected: 1.6.3.901-r2
   protected: none
 omitted: none

 x11-drivers/xf86-video-intel
selected: 2.7.1
   protected: none
 omitted: none

- Grant

Re: [gentoo-user] depclean wants to remove xorg-server and xf86-video-intel

[Mark Knecht]

What's listed in /var/lib/portage/world?

On Tue, Oct 27, 2009 at 11:39 AM, Grant emailgr...@gmail.com wrote:
 depclean wants to remove xorg-server and xf86-video-intel and I'm a
 bit scared to do that.  Does anyone know what might be going on there?

  x11-base/xorg-server
    selected: 1.6.3.901-r2
   protected: none
     omitted: none

  x11-drivers/xf86-video-intel
    selected: 2.7.1
   protected: none
     omitted: none

 - Grant

Re: [gentoo-user] depclean wants to remove xorg-server and xf86-video-intel

[Dirk Heinrichs]

Am Dienstag 27 Oktober 2009 19:39:01 schrieb Grant:
 depclean wants to remove xorg-server and xf86-video-intel and I'm a
 bit scared to do that.  Does anyone know what might be going on there?
 
  x11-base/xorg-server
 selected: 1.6.3.901-r2
protected: none
  omitted: none
 
  x11-drivers/xf86-video-intel
 selected: 2.7.1
protected: none
  omitted: none

Looks like you don't have anything installed which needs them. If you really 
need xorg-server (means: if this is a desktop machine), you should add the 
package to your world file.

HTH...

Dirk


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

Re: [gentoo-user] depclean wants to remove xorg-server and xf86-video-intel

[Crístian Viana]

do you have xorg-server on /var/lib/portage/world?

On Tue, Oct 27, 2009 at 4:39 PM, Grant emailgr...@gmail.com wrote:

 depclean wants to remove xorg-server and xf86-video-intel and I'm a
 bit scared to do that.  Does anyone know what might be going on there?

  x11-base/xorg-server
selected: 1.6.3.901-r2
   protected: none
 omitted: none

  x11-drivers/xf86-video-intel
selected: 2.7.1
   protected: none
 omitted: none

 - Grant




-- 
Crístian Deives dos Santos Viana [aka CD1]

Re: [gentoo-user] depclean wants to remove xorg-server and xf86-video-intel

[Grant]

 depclean wants to remove xorg-server and xf86-video-intel and I'm a
 bit scared to do that.  Does anyone know what might be going on there?

  x11-base/xorg-server
     selected: 1.6.3.901-r2
    protected: none
      omitted: none

  x11-drivers/xf86-video-intel
     selected: 2.7.1
    protected: none
      omitted: none

 Looks like you don't have anything installed which needs them. If you really
 need xorg-server (means: if this is a desktop machine), you should add the
 package to your world file.

 HTH...

        Dirk

Don't most (all?) X apps depend on xorg-server?  I have many of them
in /var/lib/portage/world.  For example, abiword, gnucash, and
gnumeric.

- Grant

Re: [gentoo-user] depclean wants to remove xorg-server and xf86-video-intel

[Dirk Heinrichs]

Am Dienstag 27 Oktober 2009 20:00:57 schrieb Grant:
 Don't most (all?) X apps depend on xorg-server?

Nope. No X app depends on the server, because the server could be running on 
another machine.

Bye...

Dirk


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