[gentoo-user] This nite's switch to "full multilib"

[gentoo-user] This nite's switch to "full multilib"

[Yanestra]

Hi,

just one question: I had a working system yesterday afternoon, but after
the latest eix-sync my mask settings get ignored and the whole system is
about to be updated.

I have read the news message, and I am baffled. What can I do to keep my
working system as it is?

Regards,

A Humble User<tm>

Yanestra

Re: [gentoo-user] This nite's switch to "full multilib"

[Rich Freeman]

On Sun, Mar 29, 2015 at 5:58 AM, Yanestra <wysiwyg@seismic.de> wrote:
>
> just one question: I had a working system yesterday afternoon, but after
> the latest eix-sync my mask settings get ignored and the whole system is
> about to be updated.
>
> I have read the news message, and I am baffled. What can I do to keep my
> working system as it is?
>

If you want more specific instructions than provided by the news item,
you'll need to provide more specific details about what is happening
to you and what you want to have happen.

If your goal is to keep running on the old emul-linux-x86-* packages,
then you'll have to maintain them and anything that uses them in your
own overlay, which will be a lot of work.  Support for them in-tree is
being dropped.

If you just want to keep your system working using x86 support in the
native packages then you probably need to let emerge update your
config files to add about 100 use flag accepts.  You might also have a
package or two which stubbornly refused to do the right thing (wine
had the wrong defaults in the tree, and it looks like
android-sdk-update-manager needs some love as well which I'll take
care of once I confirm how it should act).  There are probably other
packages in the tree with problems.

-- 
Rich

Re: [gentoo-user] This nite's switch to "full multilib"

[wabenbau]

Yanestra <wysiwyg@seismic.de> wrote:

> Hi,
> 
> just one question: I had a working system yesterday afternoon, but
> after the latest eix-sync my mask settings get ignored and the whole
> system is about to be updated.
> 
> I have read the news message, and I am baffled. What can I do to keep
> my working system as it is?

I'm using grub so I had to add these two lines to packages.use

sys-libs/ncurses abi_x86_32
sys-libs/gpm abi_x86_32

and after that doing the following commands:

emerge -av -C 'app-emulation/emul-linux-x86*'
emerge @preserved-rebuild

That was all I had to do and it worked for me without problems.

If you have installed more packages depending on 32bit support you
probably need more entries in packages.use (emerge should tell you what
packages that are).

The news item said:

"In most of the cases, Portage will be able to deliver correct
suggestions for that when using the --autounmask feature. However, some
users may prefer setting ABI_X86 globally to enable 32-bit libraries
in all packages that support building them. This can be done using
the following package.use entry:

    */* abi_x86_32
"

However I hadn't tested this as I have no need for it.

I think the best insurance against a broken system is a complete
backup. I'm doing this every week anyway but always before a
potential risky update procedure.

--
Regards
wabe

Re: [gentoo-user] This nite's switch to "full multilib"

[Peter Humphrey]

On Sunday 29 March 2015 17:03:50 wabenbau@gmail.com wrote:

> I'm using grub so I had to add these two lines to packages.use
> 
> sys-libs/ncurses abi_x86_32
> sys-libs/gpm abi_x86_32

I don't know how grub is connected, but I had to add those two as well.

> and after that doing the following commands:
> 
> emerge -av -C 'app-emulation/emul-linux-x86*'
> emerge @preserved-rebuild

Both unnecessary. Portage removes emul-linux-x86 itself in a world update 
and leaves everything tickety-boo. At least, it did here.

-- 
Rgds
Peter.

Re: [gentoo-user] This nite's switch to "full multilib"

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 12022 bytes --]

On Sunday 29 Mar 2015 16:20:31 Peter Humphrey wrote:
> On Sunday 29 March 2015 17:03:50 wabenbau@gmail.com wrote:
> > I'm using grub so I had to add these two lines to packages.use
> > 
> > sys-libs/ncurses abi_x86_32
> > sys-libs/gpm abi_x86_32
> 
> I don't know how grub is connected, but I had to add those two as well.
> 
> > and after that doing the following commands:
> > 
> > emerge -av -C 'app-emulation/emul-linux-x86*'
> > emerge @preserved-rebuild
> 
> Both unnecessary. Portage removes emul-linux-x86 itself in a world update
> and leaves everything tickety-boo. At least, it did here.

If definitely did NOT play nicely here.  :-(

I have some hard blocks with qt:

[blocks B      ] <dev-qt/qtdeclarative-4.8.6:4 ("<dev-
qt/qtdeclarative-4.8.6:4" is blocking dev-qt/qtchooser-0_p20150102)
[blocks B      ] dev-qt/qttranslations:4 ("dev-qt/qttranslations:4" is 
blocking dev-qt/qtcore-4.8.5-r2)
[blocks B      ] <dev-qt/qtcore-4.8.6:4 ("<dev-qt/qtcore-4.8.6:4" is blocking 
dev-qt/qtchooser-0_p20150102)
[blocks B      ] <dev-qt/qtscript-4.8.6:4 ("<dev-qt/qtscript-4.8.6:4" is 
blocking dev-qt/qtchooser-0_p20150102)
[blocks B      ] <dev-qt/qtopengl-4.8.6:4 ("<dev-qt/qtopengl-4.8.6:4" is 
blocking dev-qt/qtchooser-0_p20150102)
[blocks B      ] <dev-qt/designer-4.8.6:4 ("<dev-qt/designer-4.8.6:4" is 
blocking dev-qt/qtchooser-0_p20150102)
[blocks B      ] <dev-qt/qttest-4.8.6:4 ("<dev-qt/qttest-4.8.6:4" is blocking 
dev-qt/qtchooser-0_p20150102)
[blocks B      ] <dev-qt/qtxmlpatterns-4.8.6:4 ("<dev-
qt/qtxmlpatterns-4.8.6:4" is blocking dev-qt/qtchooser-0_p20150102)
[blocks B      ] <dev-qt/qtsql-4.8.6:4 ("<dev-qt/qtsql-4.8.6:4" is blocking 
dev-qt/qtchooser-0_p20150102)
[blocks B      ] <dev-qt/qtsvg-4.8.6:4 ("<dev-qt/qtsvg-4.8.6:4" is blocking 
dev-qt/qtchooser-0_p20150102)
[blocks B      ] <dev-qt/qtgui-4.8.6:4 ("<dev-qt/qtgui-4.8.6:4" is blocking 
dev-qt/qtchooser-0_p20150102)
[blocks B      ] <dev-qt/qt3support-4.8.6:4 ("<dev-qt/qt3support-4.8.6:4" is 
blocking dev-qt/qtchooser-0_p20150102)
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
dev-qt/qtcore:4
  (dev-qt/qtcore-4.8.5-r2:4/4::gentoo, installed) pulled in by
    ~dev-qt/qtcore-4.8.5[aqua=,debug=] required by (dev-
qt/qtsvg-4.8.5:4/4::gentoo, ebuild scheduled for merge)
    ^              ^^^^^                                                                                                                                              
    (and 9 more with the same problem)
  (dev-qt/qtcore-4.8.6-r1:4/4::gentoo, ebuild scheduled for merge) pulled in 
by
    dev-qt/qtcore:4[abi_x86_32(-)] required by (net-im/skype-4.3.0.37-
r5:0/0::gentoo, ebuild scheduled for merge)
                                                                                                                                  
    ~dev-
qt/qtcore-4.8.6[aqua=,debug=,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] 
required by (dev-qt/qtscript-4.8.6-r1:4/4::gentoo, ebuild scheduled for merge)
    ^              ^^^^^                                                                                                                                                                                                                                                                                                                   
    (and 7 more with the same problems)
dev-qt/qtgui:4
  (dev-qt/qtgui-4.8.5-r4:4/4::gentoo, installed) pulled in by
    ~dev-qt/qtgui-4.8.5[accessibility=,aqua=,debug=,qt3support=] required by 
(dev-qt/qtdeclarative-4.8.5:4/4::gentoo, ebuild scheduled for merge)
    ^             ^^^^^                                                                                                                                                                                 
    (and 5 more with the same problem)
  (dev-qt/qtgui-4.8.6-r2:4/4::gentoo, ebuild scheduled for merge) pulled in by
    dev-qt/qtgui:4[accessibility,abi_x86_32(-)] required by (net-
im/skype-4.3.0.37-r5:0/0::gentoo, ebuild scheduled for merge)
                                                                                                                                               
    ~dev-
qt/qtgui-4.8.6[aqua=,debug=,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] 
required by (dev-qt/qtwebkit-4.8.6-r1:4/4::gentoo, ebuild scheduled for merge)
    ^             ^^^^^                                                                                                                                                                                                                                                                                                                   
    (and 2 more with the same problems)
dev-qt/qtxmlpatterns:4
  (dev-qt/qtxmlpatterns-4.8.5:4/4::gentoo, installed) pulled in by
    ~dev-qt/qtxmlpatterns-4.8.5[aqua=,debug=] required by (dev-
qt/qtdeclarative-4.8.5:4/4::gentoo, ebuild scheduled for merge)
    ^                     ^^^^^                                                                                                                                                      
  (dev-qt/qtxmlpatterns-4.8.6-r1:4/4::gentoo, ebuild scheduled for merge) 
pulled in by
    ~dev-
qt/qtxmlpatterns-4.8.6[aqua=,debug=,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] 
required by (dev-qt/qtwebkit-4.8.6-r1:4/4::gentoo, ebuild scheduled for merge)
    ^                     ^^^^^                                                                                                                                                                                                                                                                                                                   
dev-qt/qtscript:4
  (dev-qt/qtscript-4.8.5:4/4::gentoo, installed) pulled in by
    ~dev-qt/qtscript-4.8.5[aqua=,debug=] required by (dev-
qt/designer-4.8.5:4/4::gentoo, ebuild scheduled for merge)
    ^                ^^^^^                                                                                                                                                 
    (and 2 more with the same problem)
  (dev-qt/qtscript-4.8.6-r1:4/4::gentoo, ebuild scheduled for merge) pulled in 
by
    ~dev-
qt/qtscript-4.8.6[aqua=,debug=,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] 
required by (dev-qt/qtgui-4.8.6-r2:4/4::gentoo, ebuild scheduled for merge)
    ^                ^^^^^                                                                                                                                                                                                                                                                                                                
dev-qt/qt3support:4
  (dev-qt/qt3support-4.8.5:4/4::gentoo, installed) pulled in by
    ~dev-qt/qt3support-4.8.5[aqua=,debug=] required by (dev-qt/qtgui-4.8.5-
r4:4/4::gentoo, installed)
    ^                  ^^^^^                                                                                                                                
    (and 2 more with the same problem)
  (dev-qt/qt3support-4.8.6-r1:4/4::gentoo, ebuild scheduled for merge) pulled 
in by
    ~dev-
qt/qt3support-4.8.6[aqua=,debug=,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] 
required by (dev-qt/qtgui-4.8.6-r2:4/4::gentoo, ebuild scheduled for merge)
    ^                  ^^^^^                                                                                                                                                                                                                                                                                                                
dev-qt/qtsql:4
  (dev-qt/qtsql-4.8.5:4/4::gentoo, installed) pulled in by
    ~dev-qt/qtsql-4.8.5[aqua=,debug=,qt3support=] required by (dev-
qt/qtdeclarative-4.8.5:4/4::gentoo, ebuild scheduled for merge)
    ^             ^^^^^                                                                                                                                                                  
    (and 1 more with the same problem)
  (dev-qt/qtsql-4.8.6-r1:4/4::gentoo, ebuild scheduled for merge) pulled in by
    ~dev-
qt/qtsql-4.8.6[aqua=,debug=,qt3support,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] 
required by (dev-qt/qt3support-4.8.6-r1:4/4::gentoo, ebuild scheduled for 
merge)
    ^             ^^^^^                                                                                                                                                                                                                                                                                                                                
It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously.  If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously. You may want to try a larger value of
the --backtrack option, such as --backtrack=30, in order to see if
that will solve this conflict automatically.
For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.
 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.
  (dev-qt/designer-4.8.5:4/4::gentoo, ebuild scheduled for merge) pulled in by
    >=dev-qt/designer-4.8.5:4[-phonon] required by (kde-base/print-
manager-4.14.3:4/4.14::gentoo, ebuild scheduled for merge)
    >=dev-qt/designer-4.8.5:4[-phonon] required by (kde-
base/kscreensaver-4.11.14:4/4.11::gentoo, installed)
    >=dev-qt/designer-4.8.5:4[-phonon] required by (kde-
base/libkdepim-4.4.11.1-r1:4/4.4::gentoo, ebuild scheduled for merge)
    >=dev-qt/designer-4.8.5:4[-phonon] required by (kde-
base/drkonqi-4.14.3:4/4.14::gentoo, installed)
    >=dev-qt/designer-4.8.5:4[-phonon] required by (kde-
base/kcalc-4.14.3:4/4.14::gentoo, installed)
    >=dev-qt/designer-4.8.5:4[-phonon] required by (kde-base/phonon-
kde-4.14.3:4/4.14::gentoo, installed)
    >=dev-qt/designer-4.8.5:4[-phonon] required by (kde-
base/kmix-4.14.3:4/4.14::gentoo, installed)
    >=dev-qt/designer-4.8.5:4[-phonon] required by (kde-base/kdebase-
desktoptheme-4.14.3:4/4.14::gentoo, installed)
    >=dev-qt/designer-4.8.5:4[-phonon] required by (kde-
base/kcheckpass-4.11.14:4/4.11::gentoo, installed)
    >=dev-qt/designer-4.8.5:4[-phonon] required by (kde-
base/krfb-4.14.3:4/4.14::gentoo, installed)
    >=dev-qt/designer-4.8.5:4[-phonon] required by (kde-base/kurifilter-
plugins-4.14.3:4/4.14::gentoo, installed)
    >=dev-qt/designer-4.8.5:4[-phonon] required by (kde-
base/systemsettings-4.11.14:4/4.11::gentoo, installed)
    >=dev-qt/designer-4.8.5:4[-phonon] required by (kde-
base/kabcclient-4.4.11.1:4/4::gentoo, installed)
[snip ...]

I am manually removing qt 4.8.5 packages to see if I can overcome the 
blockers, but I'm not out of the woods yet.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] This nite's switch to "full multilib"

[Yanestra]

On 03/29/2015 05:03 PM, wabenbau@gmail.com wrote:
> "In most of the cases, Portage will be able to deliver correct
> suggestions for that when using the --autounmask feature.
The first thing what happens here is that kde wants to upgrade because
qtchooser's mask miraculously becomes ignored. And qtchooser itself
doesn't install together with the libraries it pretends to control
because there masses of conflicts, no matter what combination (qt4, qt5)
I try.

It has taken months of experimentation to get all the software to work
which I need. It was tricky, because in many places only particular
versions do.

All that dissolves in a giant pile of rubbish...

Regards,
Yanestra

Re: [gentoo-user] This nite's switch to "full multilib"

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 994 bytes --]

On Sunday 29 Mar 2015 17:08:32 Yanestra wrote:
> On 03/29/2015 05:03 PM, wabenbau@gmail.com wrote:
> > "In most of the cases, Portage will be able to deliver correct
> > suggestions for that when using the --autounmask feature.
> 
> The first thing what happens here is that kde wants to upgrade because
> qtchooser's mask miraculously becomes ignored. And qtchooser itself
> doesn't install together with the libraries it pretends to control
> because there masses of conflicts, no matter what combination (qt4, qt5)
> I try.
> 
> It has taken months of experimentation to get all the software to work
> which I need. It was tricky, because in many places only particular
> versions do.
> 
> All that dissolves in a giant pile of rubbish...
> 
> Regards,
> Yanestra

I've also ended up with qt blockers, that I do not seem capable to overcome 
yet.  KDE wants qt 4.8.5 installed which is blocking qt 4.8.6.  How did you go 
about overcoming this?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] This nite's switch to "full multilib"

[wabenbau]

Mick <michaelkintzios@gmail.com> wrote:

> On Sunday 29 Mar 2015 17:08:32 Yanestra wrote:
> > On 03/29/2015 05:03 PM, wabenbau@gmail.com wrote:
> > > "In most of the cases, Portage will be able to deliver correct
> > > suggestions for that when using the --autounmask feature.
> > 
> > The first thing what happens here is that kde wants to upgrade
> > because qtchooser's mask miraculously becomes ignored. And
> > qtchooser itself doesn't install together with the libraries it
> > pretends to control because there masses of conflicts, no matter
> > what combination (qt4, qt5) I try.
> > 
> > It has taken months of experimentation to get all the software to
> > work which I need. It was tricky, because in many places only
> > particular versions do.
> > 
> > All that dissolves in a giant pile of rubbish...
> > 
> > Regards,
> > Yanestra
> 
> I've also ended up with qt blockers, that I do not seem capable to
> overcome yet.  KDE wants qt 4.8.5 installed which is blocking qt
> 4.8.6.  How did you go about overcoming this?
> 

I also have dev-qt/qtcore-4.8.5-r2 and some other qt packages installed
but I had no problems with that.

I'm on gentoo stable (not ~amd64) and I don't use KDE.

--
Regards
wabe

Re: [gentoo-user] This nite's switch to "full multilib"

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 640 bytes --]

On Sunday 29 Mar 2015 17:43:42 wabenbau@gmail.com wrote:
> Mick <michaelkintzios@gmail.com> wrote:

> > I've also ended up with qt blockers, that I do not seem capable to
> > overcome yet.  KDE wants qt 4.8.5 installed which is blocking qt
> > 4.8.6.  How did you go about overcoming this?
> 
> I also have dev-qt/qtcore-4.8.5-r2 and some other qt packages installed
> but I had no problems with that.
> 
> I'm on gentoo stable (not ~amd64) and I don't use KDE.
> 
> --
> Regards
> wabe

I only use some KDE apps, not the full meta.  There seems to be a problem with 
dev-qt/qtchooser and <qt-4.8.6

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] This nite's switch to "full multilib"

[wabenbau]

Mick <michaelkintzios@gmail.com> wrote:

> On Sunday 29 Mar 2015 17:43:42 wabenbau@gmail.com wrote:
> > Mick <michaelkintzios@gmail.com> wrote:
> 
> > > I've also ended up with qt blockers, that I do not seem capable to
> > > overcome yet.  KDE wants qt 4.8.5 installed which is blocking qt
> > > 4.8.6.  How did you go about overcoming this?
> > 
> > I also have dev-qt/qtcore-4.8.5-r2 and some other qt packages
> > installed but I had no problems with that.
> > 
> > I'm on gentoo stable (not ~amd64) and I don't use KDE.
> > 
> > --
> > Regards
> > wabe
> 
> I only use some KDE apps, not the full meta.  There seems to be a
> problem with dev-qt/qtchooser and <qt-4.8.6

dev-qt/qtchooser isn't installed on my system. Some days ago I wanna
try out lxqt, but the attempted installation of qt5 (and therefore
qtchooser) gives me so much blockers that I decided to wait until the
whole thing hits the stable tree.

--
Regards
wabe

Re: [gentoo-user] This nite's switch to "full multilib"

[Peter Humphrey]

On Sunday 29 March 2015 17:58:46 Mick wrote:
> On Sunday 29 Mar 2015 17:43:42 wabenbau@gmail.com wrote:
> > Mick <michaelkintzios@gmail.com> wrote:
> > > I've also ended up with qt blockers, that I do not seem capable to
> > > overcome yet.  KDE wants qt 4.8.5 installed which is blocking qt
> > > 4.8.6.  How did you go about overcoming this?
> > 
> > I also have dev-qt/qtcore-4.8.5-r2 and some other qt packages installed
> > but I had no problems with that.
> > 
> > I'm on gentoo stable (not ~amd64) and I don't use KDE.
> 
> I only use some KDE apps, not the full meta.  There seems to be a problem
> with dev-qt/qtchooser and <qt-4.8.6

Ah, that explains it. I haven't been adventurous enough to try qt5 yet, so 
no need for qtchooser. Thank goodness for the quiet life!

-- 
Rgds
Peter.

[gentoo-user] Re: This nite's switch to "full multilib"

[Michael Palimaka]

On 30/03/15 03:43, wabenbau@gmail.com wrote:
> Mick <michaelkintzios@gmail.com> wrote:
> 
>> On Sunday 29 Mar 2015 17:08:32 Yanestra wrote:
>>> On 03/29/2015 05:03 PM, wabenbau@gmail.com wrote:
>>>> "In most of the cases, Portage will be able to deliver correct
>>>> suggestions for that when using the --autounmask feature.
>>>
>>> The first thing what happens here is that kde wants to upgrade
>>> because qtchooser's mask miraculously becomes ignored. And
>>> qtchooser itself doesn't install together with the libraries it
>>> pretends to control because there masses of conflicts, no matter
>>> what combination (qt4, qt5) I try.
>>>
>>> It has taken months of experimentation to get all the software to
>>> work which I need. It was tricky, because in many places only
>>> particular versions do.
>>>
>>> All that dissolves in a giant pile of rubbish...
>>>
>>> Regards,
>>> Yanestra
>>
>> I've also ended up with qt blockers, that I do not seem capable to
>> overcome yet.  KDE wants qt 4.8.5 installed which is blocking qt
>> 4.8.6.  How did you go about overcoming this?
>>
> 
> I also have dev-qt/qtcore-4.8.5-r2 and some other qt packages installed
> but I had no problems with that.
> 
> I'm on gentoo stable (not ~amd64) and I don't use KDE.

If you're on stable, you'll need to keyword qt-4.8.6 in its entirety.
You can't mix and match versions, and 4.8.6 is the only one that
supports multilib.

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Yanestra]

On 03/29/2015 07:27 PM, Michael Palimaka wrote:
> If you're on stable, you'll need to keyword qt-4.8.6 in its entirety.
> You can't mix and match versions, and 4.8.6 is the only one that
> supports multilib. 
Hm, a little documentation wouldn't hurt, don't you think?

This guy has written a whole article about his trouble, and that was
months ago...:

https://lwn.net/Articles/605540/

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Rich Freeman]

(crossposting to -dev since this is fairly high-impact)

On Sun, Mar 29, 2015 at 1:27 PM, Michael Palimaka <kensington@gentoo.org> wrote:
> On 30/03/15 03:43, wabenbau@gmail.com wrote:
>>
>> I also have dev-qt/qtcore-4.8.5-r2 and some other qt packages installed
>> but I had no problems with that.
>>
>> I'm on gentoo stable (not ~amd64) and I don't use KDE.
>
> If you're on stable, you'll need to keyword qt-4.8.6 in its entirety.
> You can't mix and match versions, and 4.8.6 is the only one that
> supports multilib.

I think we really need to either stabilize 4.8.6, or backport
qtchooser/multilib/etc to the current stable version.

qt is a pretty significant package to have break with multilib, and
trying to run qt-5 on a stable system is already a nightmare with the
qtchooser switch (in my case I ended up abandoning qt5 as I didn't
need it that badly).

-- 
Rich

Re: [gentoo-user] This nite's switch to "full multilib"

[Alan McKinnon]

On 29/03/2015 18:21, Mick wrote:
> On Sunday 29 Mar 2015 17:08:32 Yanestra wrote:
>> On 03/29/2015 05:03 PM, wabenbau@gmail.com wrote:
>>> "In most of the cases, Portage will be able to deliver correct
>>> suggestions for that when using the --autounmask feature.
>>
>> The first thing what happens here is that kde wants to upgrade because
>> qtchooser's mask miraculously becomes ignored. And qtchooser itself
>> doesn't install together with the libraries it pretends to control
>> because there masses of conflicts, no matter what combination (qt4, qt5)
>> I try.
>>
>> It has taken months of experimentation to get all the software to work
>> which I need. It was tricky, because in many places only particular
>> versions do.
>>
>> All that dissolves in a giant pile of rubbish...
>>
>> Regards,
>> Yanestra
> 
> I've also ended up with qt blockers, that I do not seem capable to overcome 
> yet.  KDE wants qt 4.8.5 installed which is blocking qt 4.8.6.  How did you go 
> about overcoming this?
> 


I went through that exercise about a month ago, and I needed this:

/etc/portage/package.use/abi_x86_32:

>=dev-qt/qtwebkit-4.8.6-r1:4 abi_x86_32
>=dev-qt/qtgui-4.8.6-r1:4 abi_x86_32
>=dev-qt/qtdbus-4.8.6-r1:4 abi_x86_32
>=dev-qt/qtscript-4.8.6-r1:4 abi_x86_32
>=dev-qt/qtcore-4.8.6-r1:4 abi_x86_32
>=dev-qt/qtxmlpatterns-4.8.6-r1:4 abi_x86_32
>=dev-qt/qt3support-4.8.6-r1 abi_x86_32
>=dev-qt/qtsql-4.8.6-r1:4 abi_x86_32



Apparently I have some 32-bit app that uses Qt, and wine is also in the
mix. I imagine the number of possibilities and complications about this
can be huge and many folks will need to make their own unique tweaks to
package.use, and it'll take a while to shake out all the cruft in the tree


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] This nite's switch to "full multilib"

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2360 bytes --]

On Sunday 29 Mar 2015 18:07:50 Alan McKinnon wrote:
> On 29/03/2015 18:21, Mick wrote:
> > On Sunday 29 Mar 2015 17:08:32 Yanestra wrote:
> >> On 03/29/2015 05:03 PM, wabenbau@gmail.com wrote:
> >>> "In most of the cases, Portage will be able to deliver correct
> >>> suggestions for that when using the --autounmask feature.
> >> 
> >> The first thing what happens here is that kde wants to upgrade because
> >> qtchooser's mask miraculously becomes ignored. And qtchooser itself
> >> doesn't install together with the libraries it pretends to control
> >> because there masses of conflicts, no matter what combination (qt4, qt5)
> >> I try.
> >> 
> >> It has taken months of experimentation to get all the software to work
> >> which I need. It was tricky, because in many places only particular
> >> versions do.
> >> 
> >> All that dissolves in a giant pile of rubbish...
> >> 
> >> Regards,
> >> Yanestra
> > 
> > I've also ended up with qt blockers, that I do not seem capable to
> > overcome yet.  KDE wants qt 4.8.5 installed which is blocking qt 4.8.6. 
> > How did you go about overcoming this?
> 
> I went through that exercise about a month ago, and I needed this:
> 
> /etc/portage/package.use/abi_x86_32:
> >=dev-qt/qtwebkit-4.8.6-r1:4 abi_x86_32
> >=dev-qt/qtgui-4.8.6-r1:4 abi_x86_32
> >=dev-qt/qtdbus-4.8.6-r1:4 abi_x86_32
> >=dev-qt/qtscript-4.8.6-r1:4 abi_x86_32
> >=dev-qt/qtcore-4.8.6-r1:4 abi_x86_32
> >=dev-qt/qtxmlpatterns-4.8.6-r1:4 abi_x86_32
> >=dev-qt/qt3support-4.8.6-r1 abi_x86_32
> >=dev-qt/qtsql-4.8.6-r1:4 abi_x86_32
> 
> Apparently I have some 32-bit app that uses Qt, and wine is also in the
> mix. I imagine the number of possibilities and complications about this
> can be huge and many folks will need to make their own unique tweaks to
> package.use, and it'll take a while to shake out all the cruft in the tree

Thanks Alan, after keywording:

=dev-qt/qtopengl-4.8.6-r1 ~amd64
=dev-qt/qtscript-4.8.6-r1 ~amd64
=dev-qt/qtsql-4.8.6-r1 ~amd64
=dev-qt/qtsvg-4.8.6-r1 ~amd64
=dev-qt/qttest-4.8.6-r1 ~amd64
=dev-qt/qttranslations-4.8.6-r1 ~amd64
=dev-qt/qtwebkit-4.8.6-r1 ~amd64
=dev-qt/qtxmlpatterns-4.8.6-r1 ~amd64

and adding abi_x86_32 on many packages that emerge asked me to, I am now able 
to progress with 'emerge -a @preserved-rebuild'.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] This nite's switch to "full multilib"

[Stefan G. Weichinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 29.03.2015 19:30, Mick wrote:

>> I went through that exercise about a month ago, and I needed
>> this:
>> 
>> /etc/portage/package.use/abi_x86_32:
>>> =dev-qt/qtwebkit-4.8.6-r1:4 abi_x86_32 =dev-qt/qtgui-4.8.6-r1:4
>>> abi_x86_32 =dev-qt/qtdbus-4.8.6-r1:4 abi_x86_32 
>>> =dev-qt/qtscript-4.8.6-r1:4 abi_x86_32 
>>> =dev-qt/qtcore-4.8.6-r1:4 abi_x86_32 
>>> =dev-qt/qtxmlpatterns-4.8.6-r1:4 abi_x86_32 
>>> =dev-qt/qt3support-4.8.6-r1 abi_x86_32 =dev-qt/qtsql-4.8.6-r1:4
>>> abi_x86_32

I have to do that for 195 ebuilds here and really wonder if that is
correct in the end ....



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVGDwOAAoJEClcuD1V0PzmeWIP/3dMSW72SLuUGHdI538zT+Pd
LePwUP4JBlee5zfzwVdCtjFqeY25LThwOHf4PYRtvAVAt9HD/x3ZQFkjTnCffHt2
o9by5eqUyJ7omh5sFIhcBmlwBF2mMCFYWWH9n3X7rJT9W6nvHYL9jz6GxZIANtAE
35qmLom+rl7MBDd3kweUnVx1jQ2jw3NIk2oxlgQv6emyoaQ2v/1WxKWI8xtigbsH
4zlLBGJBtsayVeRyx+nraVa4IyALW+mhFSXoSEzAKQTzlJskn5FhpM0RAomBJomK
wjrhqpOYAPQTgkZ5wtqnkIcEvlE6BOx6vlu6Goh4pSmfFkanWSA8uC+LJVKuyklB
RvDmMuAs+NMxDAPnHeVX3moN/4KCGB0avyHRNAceFgVkWqo+cDjyCPw33YfPWd2i
96q4NPxrElQkPyF2FB9hT4zB5sF/66psJe17nrScUiYF4nUYMLTlRQ4SJpdC7wNi
CQZ5mcBN7kRxrQWEx52AkKi0BTt6O0Aayhn5wgKJqDln9tNql7fLvBXNcxCwl1Rq
zc242XzyE4m7hGVXLD3MiXgIeH62nurlyAqKzEuFYsO0BDA63bSwuP1lLJygGmkq
EhvG7fDwEK2oCI+cj2jmSMhP4Ij1n0K2nFbDP6y/j9s9wAm/xKJc0thG1eE3+4Xs
f3WRliv7KOfAaE9YcRGV
=Wpyd
-----END PGP SIGNATURE-----

Re: [gentoo-user] This nite's switch to "full multilib"

[Alan McKinnon]

On 29/03/2015 19:53, Stefan G. Weichinger wrote:
> On 29.03.2015 19:30, Mick wrote:
> 
>>> I went through that exercise about a month ago, and I needed
>>> this:
>>>
>>> /etc/portage/package.use/abi_x86_32:
>>>> =dev-qt/qtwebkit-4.8.6-r1:4 abi_x86_32 =dev-qt/qtgui-4.8.6-r1:4
>>>> abi_x86_32 =dev-qt/qtdbus-4.8.6-r1:4 abi_x86_32
>>>> =dev-qt/qtscript-4.8.6-r1:4 abi_x86_32
>>>> =dev-qt/qtcore-4.8.6-r1:4 abi_x86_32
>>>> =dev-qt/qtxmlpatterns-4.8.6-r1:4 abi_x86_32
>>>> =dev-qt/qt3support-4.8.6-r1 abi_x86_32 =dev-qt/qtsql-4.8.6-r1:4
>>>> abi_x86_32
> 
> I have to do that for 195 ebuilds here and really wonder if that is
> correct in the end ....



It's a horrible solution, you are right. The problem is that it's not
your 32 bit apps that have to be listed, it's all the libs and deps they
have that need 32 bit versions to be built.

If you have a fast cpu, much disk space and don't care about using some
extra resources, you can always add USE="abi_xx86_32" to make.conf and
make it global. Every package that supports building 32 bit versions
will then be recompiled.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] This nite's switch to "full multilib"

[Stefan G. Weichinger]

Am 29.03.2015 um 20:16 schrieb Alan McKinnon:

>> I have to do that for 195 ebuilds here and really wonder if that is
>> correct in the end ....
> 
> 
> 
> It's a horrible solution, you are right. The problem is that it's not
> your 32 bit apps that have to be listed, it's all the libs and deps they
> have that need 32 bit versions to be built.
> 
> If you have a fast cpu, much disk space and don't care about using some
> extra resources, you can always add USE="abi_xx86_32" to make.conf and
> make it global. Every package that supports building 32 bit versions
> will then be recompiled.

Is that as it is meant to be or some not-so-ideal-switch that will soon
get some polishing?

IMO I shouldn't have to list hundreds of packages (I had to add more and
more) in some non-default-list ... even when I decide to run unstable
(~amd64).

My main system isn't that special at all, gnome, systemd, libreoffice,
thunderbird, some browsers ...

Stuff like that makes me really wonder if I spend too much of my life
time struggling with doing *updates*

I like Gentoo, you all know, but things like that scare me off a bit.

Stefan

Re: [gentoo-user] This nite's switch to "full multilib"

[Yanestra]

On 03/30/2015 12:10 AM, Stefan G. Weichinger wrote:
> My main system isn't that special at all, gnome, systemd, libreoffice,
> thunderbird, some browsers ... Stuff like that makes me really wonder
> if I spend too much of my life time struggling with doing *updates* I
> like Gentoo, you all know, but things like that scare me off a bit.
> Stefan 
Yes, actually it can be time consuming to have - and keep - a running
Gentoo system.

To me, it's something like a life insurance having btrfs on my system
disk. So I can step back when I discover something important stopped
working without me having noticed immediately.

Re: [gentoo-user] This nite's switch to "full multilib"

[Alan McKinnon]

On 30/03/2015 00:10, Stefan G. Weichinger wrote:
> Am 29.03.2015 um 20:16 schrieb Alan McKinnon:
> 
>>> I have to do that for 195 ebuilds here and really wonder if that is
>>> correct in the end ....
>>
>>
>>
>> It's a horrible solution, you are right. The problem is that it's not
>> your 32 bit apps that have to be listed, it's all the libs and deps they
>> have that need 32 bit versions to be built.
>>
>> If you have a fast cpu, much disk space and don't care about using some
>> extra resources, you can always add USE="abi_xx86_32" to make.conf and
>> make it global. Every package that supports building 32 bit versions
>> will then be recompiled.
> 
> Is that as it is meant to be or some not-so-ideal-switch that will soon
> get some polishing?
> 
> IMO I shouldn't have to list hundreds of packages (I had to add more and
> more) in some non-default-list ... even when I decide to run unstable
> (~amd64).
> 
> My main system isn't that special at all, gnome, systemd, libreoffice,
> thunderbird, some browsers ...
> 
> Stuff like that makes me really wonder if I spend too much of my life
> time struggling with doing *updates*
> 
> I like Gentoo, you all know, but things like that scare me off a bit.

This is Gentoo, it's all about choice. Sometimes there's a downside,
like a very long package.use to define to Portage exactly what your
choice really is.

Setting the flag globally is covered in today's news item on the matter,
so I assume the devs are supporting it


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] This nite's switch to "full multilib"

[Stefan G. Weichinger]

On 30.03.2015 00:51, Alan McKinnon wrote:

>> I like Gentoo, you all know, but things like that scare me off a bit.
> 
> This is Gentoo, it's all about choice. Sometimes there's a downside,
> like a very long package.use to define to Portage exactly what your
> choice really is.

I don't really know what to decide here ....

> Setting the flag globally is covered in today's news item on the matter,
> so I assume the devs are supporting it

Did that now, yes ...

Re: [gentoo-user] This nite's switch to "full multilib"

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1088 bytes --]

On Monday 30 Mar 2015 09:58:37 Stefan G. Weichinger wrote:
> On 30.03.2015 00:51, Alan McKinnon wrote:
> >> I like Gentoo, you all know, but things like that scare me off a bit.
> > 
> > This is Gentoo, it's all about choice. Sometimes there's a downside,
> > like a very long package.use to define to Portage exactly what your
> > choice really is.
> 
> I don't really know what to decide here ....

Portage ought to ask you to add abi_x86_32 in package.use for the packages 
that need it.


> > Setting the flag globally is covered in today's news item on the matter,
> > so I assume the devs are supporting it
> 
> Did that now, yes ...

Hmm ... I don't think setting abi_x86_32 globally is necessary, unless you 
want to have 32bit libs for ALL packages that these exist for, whether you use 
them or not.  I mean that for Skype you have no alternative at present, but if 
you don't use Skype then you would not need the 32bit versions of Skype's 
dependencies.  If my understanding is wrong, Alan will soon put me right on 
this.  :-)

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] This nite's switch to "full multilib"

[Alan McKinnon]

On 30/03/2015 11:23, Mick wrote:
> Hmm ... I don't think setting abi_x86_32 globally is necessary, unless you 
> want to have 32bit libs for ALL packages that these exist for, whether you use 
> them or not.  I mean that for Skype you have no alternative at present, but if 
> you don't use Skype then you would not need the 32bit versions of Skype's 
> dependencies.  If my understanding is wrong, Alan will soon put me right on 
> this.  :-)


You understand it just fine.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] This nite's switch to "full multilib"

[Stefan G. Weichinger]

On 30.03.2015 11:39, Alan McKinnon wrote:
> On 30/03/2015 11:23, Mick wrote:
>> Hmm ... I don't think setting abi_x86_32 globally is necessary, unless you 
>> want to have 32bit libs for ALL packages that these exist for, whether you use 
>> them or not.  I mean that for Skype you have no alternative at present, but if 
>> you don't use Skype then you would not need the 32bit versions of Skype's 
>> dependencies.  If my understanding is wrong, Alan will soon put me right on 
>> this.  :-)
> 
> 
> You understand it just fine.

OK, then so why do I have to edit files to tell the system to USE this
and that after the system tells me it needs that ... ?

Why isn't this taken care of within portage itself?

I don't *want* to decide 32bit or not ... (I like that I *can* ...)

I want a (mostly) stable and current linux system with the necessary
choices done by the maintainers ... if Skype needs it ... ok, then make
that a dependency/requirement somewhere ... but why force me to set that
(for so many packages) ?

-

I removed the global flag now again and only had to add that flag for a
few packages now ... maybe because others have been rebuilt already?

Maybe it isn't as bad as I thought in the first place.

I hope that this is a desktop/GUI-issue mostly? Having to do that on
dozens of customer servers is not on my wishlist right now :-)

Stefan

Re: [gentoo-user] This nite's switch to "full multilib"

[Alan McKinnon]

On 30/03/2015 12:02, Stefan G. Weichinger wrote:
> On 30.03.2015 11:39, Alan McKinnon wrote:
>> On 30/03/2015 11:23, Mick wrote:
>>> Hmm ... I don't think setting abi_x86_32 globally is necessary, unless you 
>>> want to have 32bit libs for ALL packages that these exist for, whether you use 
>>> them or not.  I mean that for Skype you have no alternative at present, but if 
>>> you don't use Skype then you would not need the 32bit versions of Skype's 
>>> dependencies.  If my understanding is wrong, Alan will soon put me right on 
>>> this.  :-)
>>
>>
>> You understand it just fine.
> 
> OK, then so why do I have to edit files to tell the system to USE this
> and that after the system tells me it needs that ... ?
> 
> Why isn't this taken care of within portage itself?
> 
> I don't *want* to decide 32bit or not ... (I like that I *can* ...)
> 
> I want a (mostly) stable and current linux system with the necessary
> choices done by the maintainers ... if Skype needs it ... ok, then make
> that a dependency/requirement somewhere ... but why force me to set that
> (for so many packages) ?


OK, think it through first.

You want skype. Skype is 32bit. So far, we're good. You put an entry in
package.use to enable abi_x86_32 for skype.

But that's not the end of the story, because *every*single*lib* skype
uses now needs a 32 bit, and the skype ebuild cannot change that. That
part should be obvious - the skype ebuild cannot make changes to how the
qt ebuilds behave, only you can do that. And you do it either with a
global flag or by listing what you want in package.use - none of this
has changed, you've been doing exactly this for years.

The next problem is the sheer number of libs that now have to be tagged
as needing 32 bit versions to be built. It's not like deciding you want
ffmpeg and now a few odd things need to be rebuilt with ffmpeg support;
if you don't rebuild all dep libs with 32 bit versions, then skype does
not work at all.

You've never had to do this before as we had emul-linux-x86 to provide
the needed versions, now we have to do that part ourselves. Ans it's a
long list, no getting around that.

> 
> -
> 
> I removed the global flag now again and only had to add that flag for a
> few packages now ... maybe because others have been rebuilt already?

Possibly, I'm not sure what steps you already took

> 
> Maybe it isn't as bad as I thought in the first place.
> 
> I hope that this is a desktop/GUI-issue mostly? Having to do that on
> dozens of customer servers is not on my wishlist right now :-)


Well, there is legacy grub, that's a 32 bit app and needs to be dealt with.

Otherwise in practice it is mostly GUI apps and then mostly only
proprietary bundles (skype, flash, and friends). All the regular open
source apps you run have been fully 64 bit for ages.

It's entirely possible there is some niche app for server situations
that is also 32 bit, but I have not come across any yet.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: This nite's switch to "full multilib"

[Holger Hoffstätte]

On Mon, 30 Mar 2015 12:14:29 +0200, Alan McKinnon wrote:

>> OK, then so why do I have to edit files to tell the system to USE this
>> and that after the system tells me it needs that ... ?
>> 
>> Why isn't this taken care of within portage itself?
>> 
>> I don't *want* to decide 32bit or not ... (I like that I *can* ...)
>> 
>> I want a (mostly) stable and current linux system with the necessary
>> choices done by the maintainers ... if Skype needs it ... ok, then make
>> that a dependency/requirement somewhere ... but why force me to set that
>> (for so many packages) ?
> 
> OK, think it through first.

Sure thing.

> You want skype. Skype is 32bit. So far, we're good. You put an entry in
> package.use to enable abi_x86_32 for skype.

Except..at that point you would have already failed.

There is no good reason whatsoever why portage shouldn't be able to treat
this like a transitive required USE flag requirement, percolating through
all libs from the toplevel requirement's dependency tree.

In fact it should do so automatically when the ebuild declares the abi_x86_32
constraint from the start, without requiring the user to do anything.

There are other reasons why coupling the native and 32-bit worlds together is
a bad idea in the long-term, regardless of understandable technical reasons
and good intentions.

So yeah: think it through first.

-h

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Alan McKinnon]

On 30/03/2015 12:42, Holger Hoffstätte wrote:
> On Mon, 30 Mar 2015 12:14:29 +0200, Alan McKinnon wrote:
> 
>>> OK, then so why do I have to edit files to tell the system to USE this
>>> and that after the system tells me it needs that ... ?
>>>
>>> Why isn't this taken care of within portage itself?
>>>
>>> I don't *want* to decide 32bit or not ... (I like that I *can* ...)
>>>
>>> I want a (mostly) stable and current linux system with the necessary
>>> choices done by the maintainers ... if Skype needs it ... ok, then make
>>> that a dependency/requirement somewhere ... but why force me to set that
>>> (for so many packages) ?
>>
>> OK, think it through first.
> 
> Sure thing.
> 
>> You want skype. Skype is 32bit. So far, we're good. You put an entry in
>> package.use to enable abi_x86_32 for skype.
> 
> Except..at that point you would have already failed.

That does not compute. Please explain.


> 
> There is no good reason whatsoever why portage shouldn't be able to treat
> this like a transitive required USE flag requirement, percolating through
> all libs from the toplevel requirement's dependency tree.

Correct, there is no good reason why portage *can't* do that.
There is a very good reason why portage *won't* do that, it is not the
gentoo way and it goes against gentoo's social contract.

Portage does not override your choices, and it certainly does not allow
one single ebuild to automagically change the behaviour of multiple
other ebuilds. The correct way to bring about changes in behaviour is to
add your global choices to make.conf (which is outside the control of
the tree), or to add your explicit changes to package.*

Portage's default behaviour when confronted with incompatible settings
has always been to detect them, and print the output to the console
telling you what to do. Now, there is a helper function that you as the
system owner can enable if you trust portage and the tree to always make
the correct decision - autounmask. You can run it with -p to get a full
list that you can edit before running it for real, or you can just let
portage go ahead and make the changes it feels are correct. But this is
not default behaviour and for very good reason.

I get the sense that those who are complaining about abi_x86_32 in this
thread are mostly not complaining about what portage does, they are
complaining about the number of entries they have to make to portage.use

I don't understand why you are advocating a dramatic change in portage's
behaviour from what it has done for years. Yes, this latest feature does
require some work from you. You have been doing this same work for ages,
the main difference being that this time it's a large amount of once-off
work.


> 
> In fact it should do so automatically when the ebuild declares the abi_x86_32
> constraint from the start, without requiring the user to do anything.

So you want a single ebuild to trigger a tree-wide change in behaviour?

I don't think that's a good idea

> 
> There are other reasons why coupling the native and 32-bit worlds together is
> a bad idea in the long-term, regardless of understandable technical reasons
> and good intentions.
> 
> So yeah: think it through first.


I already did. Refer this post. I think I thought about it in ways that
you have not considered yet.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: This nite's switch to "full multilib"

[Holger Hoffstätte]

On Mon, 30 Mar 2015 13:14:55 +0200, Alan McKinnon wrote:

> On 30/03/2015 12:42, Holger Hoffstätte wrote:
>>> You want skype. Skype is 32bit. So far, we're good. You put an entry in
>>> package.use to enable abi_x86_32 for skype.
>> 
>> Except..at that point you would have already failed.
> 
> That does not compute. Please explain.

That was my somewhat categorical way of saying that you'd be repeating
yourself with no benefit. The ebuild already knows that it's 32-bit only,
so making e.g. the user declare the same thing again would be wrong to begin
with. I realize of course that's not how it is done, and that the abi
constraint is a required part of the ebuild for precisely that reason.

That the current transitional situation is a bit messy - fine.

>> There is no good reason whatsoever why portage shouldn't be able to treat
>> this like a transitive required USE flag requirement, percolating through
>> all libs from the toplevel requirement's dependency tree.
> 
> Correct, there is no good reason why portage *can't* do that.
> There is a very good reason why portage *won't* do that, it is not the
> gentoo way and it goes against gentoo's social contract.

That sounds great until you realize that selective capability configuration
(aka USE flags, which I love and agree with!) is not the same as multilib
profile selection.

I really do understand the *idea* of strictly driving system capabilities
from user-defined USE flags, so when you say:

> Portage does not override your choices, and it certainly does not allow
> one single ebuild to automagically change the behaviour of multiple
> other ebuilds. The correct way to bring about changes in behaviour is to
> add your global choices to make.conf (which is outside the control of
> the tree), or to add your explicit changes to package.*

..that just shows the root of the problem: the ABI is not handled
consistently, but rather as a per-package configuration choice.

I already *collectively opted into* the 32-bit parallel universe by
*choosing multilib*. All the current way is doing is repeating that choice
without accomplishing anything, esp. since I cannot reasonably NOT make that
choice. It's a hard requirement if I want to run a certain application.

It's great that Gentoo "gives me choice", but I hope you can see how
not having a certain capability or not runnig an application at all are
two very different shoes.

> I get the sense that those who are complaining about abi_x86_32 in this
> thread are mostly not complaining about what portage does, they are
> complaining about the number of entries they have to make to portage.use

No, they are complaining about the effects of the conflation of concepts,
which ends up first in their config file (either manually or by portage),
and eventually in their face, increasing the possibility of making completely
unrelated mistakes later on.

It also gives the false impression that this is a configuration choice, which
it really isn't (see above).

This also alludes to the secondary aspect I mentioned. Tightly coupling
configuration choices possible in one world to the parallel world is going
to be a real problem moving forward, precisely for the same reason:
conflating a single mechanism for two different worlds with possibly
different hard requirements.

>> In fact it should do so automatically when the ebuild declares the abi_x86_32
>> constraint from the start, without requiring the user to do anything.
> 
> So you want a single ebuild to trigger a tree-wide change in behaviour?

Yes, *because I chose multilib*. That is *exactly* what I want, and - judging
by some of the posts here and in the forums - also what most people seem to
expect.

I'm starting to wonder if it wouldn't be much more economical to provide
prebuilt stacked layers of Docker images for 32-bit compatibility.
That would solve several classes of problems at once, and not pollute the
native Gentoo way with ultimately unsolvable problems.

-h

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Neil Bothwick]

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

On Mon, 30 Mar 2015 12:15:01 +0000 (UTC), Holger Hoffstätte wrote:

> > Portage does not override your choices, and it certainly does not
> > allow one single ebuild to automagically change the behaviour of
> > multiple other ebuilds. The correct way to bring about changes in
> > behaviour is to add your global choices to make.conf (which is
> > outside the control of the tree), or to add your explicit changes to
> > package.*  
> 
> ..that just shows the root of the problem: the ABI is not handled
> consistently, but rather as a per-package configuration choice.

The news item also showed how to make it a global choice, avoiding the
need to multiple per-package directories.
 
> I already *collectively opted into* the 32-bit parallel universe by
> *choosing multilib*. All the current way is doing is repeating that
> choice without accomplishing anything, esp. since I cannot reasonably
> NOT make that choice. It's a hard requirement if I want to run a
> certain application.

That's a fair point. Maybe multilib should default to ABI_X86="64 32"


-- 
Neil Bothwick

To the optimist, the glass is half full. To the pessimist, the glass is
half empty. To the engineer, the glass is twice as big as it needs to be.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[gentoo-user] Re: This nite's switch to "full multilib"

[Holger Hoffstätte]

On Mon, 30 Mar 2015 13:44:59 +0100, Neil Bothwick wrote:

> On Mon, 30 Mar 2015 12:15:01 +0000 (UTC), Holger Hoffstätte wrote:
> 
>> > Portage does not override your choices, and it certainly does not
>> > allow one single ebuild to automagically change the behaviour of
>> > multiple other ebuilds. The correct way to bring about changes in
>> > behaviour is to add your global choices to make.conf (which is
>> > outside the control of the tree), or to add your explicit changes to
>> > package.*  
>> 
>> ..that just shows the root of the problem: the ABI is not handled
>> consistently, but rather as a per-package configuration choice.
> 
> The news item also showed how to make it a global choice, avoiding the
> need to multiple per-package directories.

I'm not sure that's a solution to the problem at all (which is why I
didn't do it on my machines either). Apart from always wasting much more
work & resources than necessary for no good reason it doesn't answer the
question what happens as soon as I want to build a package that is
64-bit-only - in which case you'd end up in the same situation we have
now, just mirrored.

-h

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Neil Bothwick]

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

On Mon, 30 Mar 2015 13:04:47 +0000 (UTC), Holger Hoffstätte wrote:

> > The news item also showed how to make it a global choice, avoiding the
> > need to multiple per-package directories.  
> 
> I'm not sure that's a solution to the problem at all (which is why I
> didn't do it on my machines either). Apart from always wasting much more
> work & resources than necessary for no good reason it doesn't answer the
> question what happens as soon as I want to build a package that is
> 64-bit-only - in which case you'd end up in the same situation we have
> now, just mirrored.

Yes, the only question is would it be a better or worse situation. From a
pragmatic point of view it would be better, since the only inconvenience
would be in extra builds, nothing would stop working in the meantime and
you are far less likely to get blockers.

Neither solution is ideal, but the change from the old binary packages had
to be made at some point. At least we will now be spared the messages
from revdep-rebuild and perl-cleaner about binary packages that won't
change no matter how many time we reinstall them.


-- 
Neil Bothwick

Processor: (n.) a device for converting sense to nonsense at the speed
           of electricity, or (rarely) the reverse.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Peter Humphrey]

On Monday 30 March 2015 15:34:55 Neil Bothwick wrote:

> At least we will now be spared the messages from [...] perl-cleaner about
> binary packages that won't change no matter how many time we reinstall
> them.

That certainly is an improvement, yes. I was always unsure how safe I was in 
ignoring those messages.

-- 
Rgds
Peter.

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Alan McKinnon]

On 30/03/2015 15:04, Holger Hoffstätte wrote:
> On Mon, 30 Mar 2015 13:44:59 +0100, Neil Bothwick wrote:
> 
>> On Mon, 30 Mar 2015 12:15:01 +0000 (UTC), Holger Hoffstätte wrote:
>>
>>>> Portage does not override your choices, and it certainly does not
>>>> allow one single ebuild to automagically change the behaviour of
>>>> multiple other ebuilds. The correct way to bring about changes in
>>>> behaviour is to add your global choices to make.conf (which is
>>>> outside the control of the tree), or to add your explicit changes to
>>>> package.*  
>>>
>>> ..that just shows the root of the problem: the ABI is not handled
>>> consistently, but rather as a per-package configuration choice.
>>
>> The news item also showed how to make it a global choice, avoiding the
>> need to multiple per-package directories.
> 
> I'm not sure that's a solution to the problem at all (which is why I
> didn't do it on my machines either). Apart from always wasting much more
> work & resources than necessary for no good reason it doesn't answer the
> question what happens as soon as I want to build a package that is
> 64-bit-only - in which case you'd end up in the same situation we have
> now, just mirrored.


Maybe it's time we asked the multilib devs how they intended to deal
with these questions you raise.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Fernando Rodriguez]

On Monday, March 30, 2015 9:09:14 PM Alan McKinnon wrote:
> On 30/03/2015 15:04, Holger Hoffstätte wrote:
> > On Mon, 30 Mar 2015 13:44:59 +0100, Neil Bothwick wrote:
> > 
> >> On Mon, 30 Mar 2015 12:15:01 +0000 (UTC), Holger Hoffstätte wrote:
> >>
> >>>> Portage does not override your choices, and it certainly does not
> >>>> allow one single ebuild to automagically change the behaviour of
> >>>> multiple other ebuilds. The correct way to bring about changes in
> >>>> behaviour is to add your global choices to make.conf (which is
> >>>> outside the control of the tree), or to add your explicit changes to
> >>>> package.*  
> >>>
> >>> ..that just shows the root of the problem: the ABI is not handled
> >>> consistently, but rather as a per-package configuration choice.
> >>
> >> The news item also showed how to make it a global choice, avoiding the
> >> need to multiple per-package directories.
> > 
> > I'm not sure that's a solution to the problem at all (which is why I
> > didn't do it on my machines either). Apart from always wasting much more
> > work & resources than necessary for no good reason it doesn't answer the
> > question what happens as soon as I want to build a package that is
> > 64-bit-only - in which case you'd end up in the same situation we have
> > now, just mirrored.
> 
> 
> Maybe it's time we asked the multilib devs how they intended to deal
> with these questions you raise.

I don't have a problem with the way it is, but I think something like the 
following would be nice: instead of just supporting use_flag and -use_flag you 
could add something like @use_flag (auto-use flag) that automatically builds the 
feature only if needed to satisfy a dependency. That way you're not changing 
anything with existing configuration and still got full control over it.

-- 
Fernando Rodriguez

[gentoo-user] Re: This nite's switch to "full multilib"

[Grant Edwards]

On 2015-03-30, Fernando Rodriguez <frodriguez.developer@outlook.com> wrote:
> On Monday, March 30, 2015 9:09:14 PM Alan McKinnon wrote:
>
>> Maybe it's time we asked the multilib devs how they intended to deal
>> with these questions you raise.
>
> I don't have a problem with the way it is, but I think something like
> the following would be nice: instead of just supporting use_flag and
> -use_flag you could add something like @use_flag (auto-use flag) that
> automatically builds the feature only if needed to satisfy a
> dependency. That way you're not changing anything with existing
> configuration and still got full control over it.

That could be pretty handy in cases like this.

I was also wondering if there might a way for emerge to show you which
packages have USE flags enabled that aren't required by any dependent
package: it would be sort of like "emerge --depclean" but for USE
flags instead of packages themselves.

-- 
Grant Edwards               grant.b.edwards        Yow! The PILLSBURY DOUGHBOY
                                  at               is CRYING for an END to
                              gmail.com            BURT REYNOLDS movies!!

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Chris Camisa]

On 03/30/2015 02:52 PM, Grant Edwards wrote:
> 
> I was also wondering if there might a way for emerge to show you which
> packages have USE flags enabled that aren't required by any dependent
> package: it would be sort of like "emerge --depclean" but for USE
> flags instead of packages themselves.
> 

Hi Grant,

    You are probably looking for enalyze from app-portage/gentookit.
    Presently it will rebuild your package.accept_keywords and
package.use files after analyzing them.

    Its pretty darn helpful and only needs a little massaging after its
done to be perfectly useful as a drop-in replacement file.

Kind Regards,
-Camisa

[gentoo-user] Re: This nite's switch to "full multilib"

[Grant Edwards]

On 2015-03-30, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 30/03/2015 15:04, Holger Hoffstätte wrote:
>> On Mon, 30 Mar 2015 13:44:59 +0100, Neil Bothwick wrote:
>>> On Mon, 30 Mar 2015 12:15:01 +0000 (UTC), Holger Hoffstätte wrote:
>>>
>>>>> Portage does not override your choices, and it certainly does not
>>>>> allow one single ebuild to automagically change the behaviour of
>>>>> multiple other ebuilds. The correct way to bring about changes in
>>>>> behaviour is to add your global choices to make.conf (which is
>>>>> outside the control of the tree), or to add your explicit changes to
>>>>> package.* 
>>>>
>>>> ..that just shows the root of the problem: the ABI is not handled
>>>> consistently, but rather as a per-package configuration choice.
>>>
>>> The news item also showed how to make it a global choice, avoiding the
>>> need to multiple per-package directories.
>> 
>> I'm not sure that's a solution to the problem at all (which is why I
>> didn't do it on my machines either).

If the problem is that you don't want things to be inconsistent, then
it _does_ solve the problem.

>> Apart from always wasting much more work & resources than necessary
>> for no good reason

The reason is that somebody wanted their system to be "consistent." I
don't think that's a particulary good reason, but that's the nice
thing aboug Gentoo.  Everybody gets to decide what is important to
them, and build their system accordingly.

>> it doesn't answer the question what happens as soon as I want to
>> build a package that is 64-bit-only - in which case you'd end up in
>> the same situation we have now, just mirrored.

You can have your system be consistent by setting up everything using
global values in make.conf, or you can choose to override that
consistency by manually enabling/disabling USE variables on a
per-package basis.  That's how Gentoo works and how Gentoo has always
worked.  I don't how this is any different.

> Maybe it's time we asked the multilib devs how they intended to deal
> with these questions you raise.

It seems there are two options:

  1) Add abi_x86_32 on a package-by-package basis (or let emerge do it
     for you when you tell it to install something with 32-bit
     requirements like acroread).

  2) Add ABI_X86="64 32" to make.conf, and then add -abi_x86_32 on a
     package-by-package basis if/when you want to build something
     64-bit-only.

It looks like they intended for you to choose whether you want 32 bit
versions built as the exception or as the rule.  For the former, you
do 1). For the latter, you do 2).  

So far, I'm going with 1).  When I decided to install acroread this
morning, emerge added abi_x86_32 flags to package.use for about 80
packages.  The other option would have re-built about 200 packages.

Either way would have worked, but I wanted to see if emerge really was
able to selectively rebuild the subset of packages required by
acroread.  AFAICT, it did just fine.

-- 
Grant Edwards               grant.b.edwards        Yow! Yes, but will I
                                  at               see the EASTER BUNNY in
                              gmail.com            skintight leather at an
                                                   IRON MAIDEN concert?

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Neil Bothwick]

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

On Mon, 30 Mar 2015 19:46:54 +0000 (UTC), Grant Edwards wrote:

> >>> The news item also showed how to make it a global choice, avoiding
> >>> the need to multiple per-package directories.
> >> 
> >> I'm not sure that's a solution to the problem at all (which is why I
> >> didn't do it on my machines either).
> 
> If the problem is that you don't want things to be inconsistent, then
> it _does_ solve the problem.
> 
> >> Apart from always wasting much more work & resources than necessary
> >> for no good reason
> 
> The reason is that somebody wanted their system to be "consistent." I
> don't think that's a particulary good reason, but that's the nice
> thing aboug Gentoo.  Everybody gets to decide what is important to
> them, and build their system accordingly.

It's also practical as it requires no other changes to get your system
working. However, it is even less efficient than I had envisaged.

ABI_X86="64 32"  emerge --update --deep --changed-use --with-bdeps y
-pv @world

gives

Total: 237 packages (237 reinstalls),

Whereas:

grep -cv '^#' /etc/portage/package.use/abi_x86_32 

gives 119 packages.

So setting it globally would require three times as many packages to be
rebuilt on this KDE system.


-- 
Neil Bothwick

You are a completely unique individual, just like everybody else.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[gentoo-user] Re: This nite's switch to "full multilib"

[Grant Edwards]

On 2015-03-30, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Mon, 30 Mar 2015 19:46:54 +0000 (UTC), Grant Edwards wrote:
>
>> The reason is that somebody wanted their system to be "consistent." I
>> don't think that's a particulary good reason, but that's the nice
>> thing aboug Gentoo.  Everybody gets to decide what is important to
>> them, and build their system accordingly.
>
> It's also practical as it requires no other changes to get your system
> working. However, it is even less efficient than I had envisaged.
>
> ABI_X86="64 32"  emerge --update --deep --changed-use --with-bdeps y
> -pv @world
>
> gives
>
> Total: 237 packages (237 reinstalls),
>
> Whereas:
>
> grep -cv '^#' /etc/portage/package.use/abi_x86_32 
>
> gives 119 packages.
>
> So setting it globally would require three times as many packages to be
> rebuilt on this KDE system.

That's roughly what I came up with this morning when I decided to try
installing acroread on one of my XFCE boxes: 81 rebuilds one way, a
handful over 200 the other.

And I think it's at least the third time in the past few months I've
looked up llvm to see what it is and why it's getting built -- I keep
getting it confused with lvm.

-- 
Grant Edwards               grant.b.edwards        Yow! Jesuit priests are
                                  at               DATING CAREER DIPLOMATS!!
                              gmail.com            

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Róbert Čerňanský]

On Mon, 30 Mar 2015 13:14:55 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 30/03/2015 12:42, Holger Hoffstätte wrote:
> > On Mon, 30 Mar 2015 12:14:29 +0200, Alan McKinnon wrote:
> > 
> >>> OK, then so why do I have to edit files to tell the system to USE
> >>> this and that after the system tells me it needs that ... ?
> >>>
> >>> Why isn't this taken care of within portage itself?
> >>>
> >>> I don't *want* to decide 32bit or not ... (I like that I
> >>> *can* ...)
> >>>
> >>> I want a (mostly) stable and current linux system with the
> >>> necessary choices done by the maintainers ... if Skype needs
> >>> it ... ok, then make that a dependency/requirement somewhere ...
> >>> but why force me to set that (for so many packages) ?
[...]
> > There is no good reason whatsoever why portage shouldn't be able to
> > treat this like a transitive required USE flag requirement,
> > percolating through all libs from the toplevel requirement's
> > dependency tree.
> 
> Correct, there is no good reason why portage *can't* do that.
> There is a very good reason why portage *won't* do that, it is not the
> gentoo way and it goes against gentoo's social contract.
> 
> Portage does not override your choices, and it certainly does not
> allow one single ebuild to automagically change the behaviour of
> multiple other ebuilds. The correct way to bring about changes in
> behaviour is to add your global choices to make.conf (which is
> outside the control of the tree), or to add your explicit changes to
> package.*

It depends what you see as a user choice.  In my opinion by writing
'emerge skype' to the console the user clearly states his choice to
install skype.  If he actually cares what that would mean for
his system he can use --pretend or --ask option together with --verbose
and tweak USE flags if and only if he does not like it.  So user has
still full control over his system.

> Portage's default behaviour when confronted with incompatible settings
> has always been to detect them, and print the output to the console
> telling you what to do. Now, there is a helper function that you as

We could declare USE settings e.g. in make.conf as overridable by
automatic USE dependencies so portage would not see it as incompatible.
On the other hand package.use could be non-overridable thus allowing
the user to have control over portage choices.

> the system owner can enable if you trust portage and the tree to
> always make the correct decision - autounmask. You can run it with -p

Big advantage of automatic deps over --autounmask is that auto deps
would not mess with user configuration files in /etc.  Changed USE
flags would be stored internally by portage.

Robert


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

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Sebastian Beßler]

On 01.04.2015 19:28, Róbert Čerňanský wrote:

> Big advantage of automatic deps over --autounmask is that auto deps
> would not mess with user configuration files in /etc.  Changed USE
> flags would be stored internally by portage.


Ok, but then you need a database (another file in /etc/portage/) for all 
of the active use flags that are set by the installed packages. That or 
every emerge has to scan and parse every ebuild of all installed 
packages, adding a high delay.

The way as it is now is just fine, but always remember:
"With great power comes great responsibility"

Greetings

Sebastian

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Róbert Čerňanský]

On Thu, 02 Apr 2015 06:42:49 +0200
Sebastian Beßler <sebastian@darkmetatron.de> wrote:

> On 01.04.2015 19:28, Róbert Čerňanský wrote:
> 
> > Big advantage of automatic deps over --autounmask is that auto deps
> > would not mess with user configuration files in /etc.  Changed USE
> > flags would be stored internally by portage.
> 
> 
> Ok, but then you need a database (another file in /etc/portage/) for
> all of the active use flags that are set by the installed packages.
> That or every emerge has to scan and parse every ebuild of all
> installed packages, adding a high delay.

Of course you'll need a database (but not in /etc!).  It might
be /var/db/pkg or separate one, that is an implementation detail which
I am not able to tell without knowledge of portage implementation.

Besides there is such database now - it is your (abused) package.use!
You have to manually add entries to it and I do not know any database
slower than human typing to a text file ;-) (There is autounmask option
of course but then you allow portage to mess with your files which is
not a good thing.)

Robert 


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

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Neil Bothwick]

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

On Thu, 2 Apr 2015 07:21:01 +0200, Róbert Čerňanský wrote:

> Besides there is such database now - it is your (abused) package.use!
> You have to manually add entries to it and I do not know any database
> slower than human typing to a text file ;-) (There is autounmask option
> of course but then you allow portage to mess with your files which is
> not a good thing.)

Portage doesn't change your package.use file, it creates a new one using
the standard CONFIG_PROTECT process. Then you use etc-update or similar
to view and verify the changes.


-- 
Neil Bothwick

Get your grubby hands off my tagline! I stole it first!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Róbert Čerňanský]

On Thu, 2 Apr 2015 09:41:10 +0100
Neil Bothwick <neil@digimed.co.uk> wrote:

> On Thu, 2 Apr 2015 07:21:01 +0200, Róbert Čerňanský wrote:
> 
> > Besides there is such database now - it is your (abused)
> > package.use! You have to manually add entries to it and I do not
> > know any database slower than human typing to a text file ;-)
> > (There is autounmask option of course but then you allow portage to
> > mess with your files which is not a good thing.)
> 
> Portage doesn't change your package.use file, it creates a new one
> using the standard CONFIG_PROTECT process. Then you use etc-update or
> similar to view and verify the changes.

What I am trying to tell is that portage manages its stuff (USE
dependencies), through you, in your configuration files.  It is nice
that it does not overwrite them directly without asking ;-) but in the
end the content ends up there one way or other.  Portage should have
its own internal database for USE deps and manage it like it manages db
of standard package dependencies.

Robert


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

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Neil Bothwick]

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

On Thu, 2 Apr 2015 11:29:33 +0200, Róbert Čerňanský wrote:

> > Portage doesn't change your package.use file, it creates a new one
> > using the standard CONFIG_PROTECT process. Then you use etc-update or
> > similar to view and verify the changes.  
> 
> What I am trying to tell is that portage manages its stuff (USE
> dependencies), through you, in your configuration files.  It is nice
> that it does not overwrite them directly without asking ;-) but in the
> end the content ends up there one way or other.  Portage should have
> its own internal database for USE deps and manage it like it manages db
> of standard package dependencies.

I'm coming round to that way of thinking too. I was simply pointing out
that the autounmask feature doesn't clobber existing configs, so people
weren't put off using it by the implication that it did.

A mechanism for portage to manage this outside of /etc/portage would help
separate portage's decisions and requirements from those of the user


-- 
Neil Bothwick

X-Modem- A device on the losing end of an encounter with lightning.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[gentoo-user] Re: This nite's switch to "full multilib"

[Grant Edwards]

On 2015-04-02, Róbert Čerňanský <openhs@tightmail.com> wrote:
> On Thu, 2 Apr 2015 09:41:10 +0100
> Neil Bothwick <neil@digimed.co.uk> wrote:
>
>> On Thu, 2 Apr 2015 07:21:01 +0200, Róbert Čerňanský wrote:
>> 
>> > Besides there is such database now - it is your (abused)
>> > package.use! You have to manually add entries to it and I do not
>> > know any database slower than human typing to a text file ;-)
>> > (There is autounmask option of course but then you allow portage to
>> > mess with your files which is not a good thing.)
>> 
>> Portage doesn't change your package.use file, it creates a new one
>> using the standard CONFIG_PROTECT process. Then you use etc-update or
>> similar to view and verify the changes.
>
> What I am trying to tell is that portage manages its stuff (USE
> dependencies), through you, in your configuration files.  It is nice
> that it does not overwrite them directly without asking ;-) but in the
> end the content ends up there one way or other.  Portage should have
> its own internal database for USE deps and manage it like it manages db
> of standard package dependencies.

I prefer it this way.  I do not want all the nice easy-to read/edit
configuration stuff in /etc/portage encrypted some Windows Registry
break-alike.

-- 
Grant Edwards               grant.b.edwards        Yow! Were these parsnips
                                  at               CORRECTLY MARINATED in
                              gmail.com            TACO SAUCE?

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Rich Freeman]

On Thu, Apr 2, 2015 at 11:37 AM, Grant Edwards
<grant.b.edwards@gmail.com> wrote:
>
> I prefer it this way.  I do not want all the nice easy-to read/edit
> configuration stuff in /etc/portage encrypted some Windows Registry
> break-alike.

Nobody is proposing any changes to the format of package.use.

The only proposal is that users shouldn't HAVE to specify every
individual package use flag there if they just want the defaults.

You do realize that this is EXACTLY how portage already behaves for
installed packages, right?  Portage keeps track of what is installed,
and it doesn't go into the nice easy-to read/edit
/var/lib/portage/world file.  You tell portage what you want, and
portage gives it to you.  That is all that is being suggested here.
If you want libxml2 built with USE=icu, go ahead and put that in
/etc/portage/package.use.  If you don't know what libxml2 is, or what
icu is, then don't do anything and portage will install libxml2 with
USE=icu if it needs to.

The alternative is what I have now - a 1200 line package.keywords file
that tells portage to build half the system 32-bit, when I could care
less about all that stuff being 32-bit once I uninstall whatever
package is making it that way, but portage will continue to build it
all 32-bit because there is no in-between.

-- 
Rich

Re: [gentoo-user] This nite's switch to "full multilib"

[Stroller]

On Thu, 2 April 2015, at 5:24 pm, Rich Freeman <rich0@gentoo.org> wrote:
> 
> The alternative is what I have now - a 1200 line package.keywords file
> that tells portage to build half the system 32-bit, when I could care
> less … 

Slightly OT, but are there any tools for cleaning out old entries?

I could write a script to go through package.keywords line by line and, for packages where the entry is =package-version.1.2.3, delete those lines where a newer version of the package is now installed on the system.

Has anyone done this already?

Stroller.

Re: [gentoo-user] This nite's switch to "full multilib"

[Dale]

Stroller wrote:
> On Thu, 2 April 2015, at 5:24 pm, Rich Freeman <rich0@gentoo.org> wrote:
>> The alternative is what I have now - a 1200 line package.keywords file
>> that tells portage to build half the system 32-bit, when I could care
>> less … 
> Slightly OT, but are there any tools for cleaning out old entries?
>
> I could write a script to go through package.keywords line by line and, for packages where the entry is =package-version.1.2.3, delete those lines where a newer version of the package is now installed on the system.
>
> Has anyone done this already?
>
> Stroller.
>
>

I think this will do what you want.

eix-test-obsolete 

Dale

:-)  :-) 

Re: [gentoo-user] This nite's switch to "full multilib"

[Stroller]

On Fri, 3 April 2015, at 9:30 am, Dale <rdalek1967@gmail.com> wrote:
>> 
>> Slightly OT, but are there any tools for cleaning out old entries?
> 
> I think this will do what you want.
> 
> eix-test-obsolete 

Many thanks, it certainly seems to.

It seems to do a bit more besides, unruly in its verboseness, but I won't bother trying to interpret the rest of its output.

Stroller.

Re: [gentoo-user] This nite's switch to "full multilib"

[Dale]

Stroller wrote:
> On Fri, 3 April 2015, at 9:30 am, Dale <rdalek1967@gmail.com> wrote:
>>> Slightly OT, but are there any tools for cleaning out old entries?
>> I think this will do what you want.
>>
>> eix-test-obsolete 
> Many thanks, it certainly seems to.
>
> It seems to do a bit more besides, unruly in its verboseness, but I won't bother trying to interpret the rest of its output.
>
> Stroller.
>
>
>


It's one reason I don't use it much.  It spits out so much, it's about
overwhelming.  Then again, it is usually pointing out the stuff that is
no longer needed in some file somewhere.  Also, the longer you wait
between runs, the more it spits out. 

It seems you can't win with that thing.  LOL 

Dale

:-)  :-) 

Re: [gentoo-user] This nite's switch to "full multilib"

[Neil Bothwick]

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

On Sat, 04 Apr 2015 07:33:06 -0500, Dale wrote:

> >> eix-test-obsolete   
> > Many thanks, it certainly seems to.
> >
> > It seems to do a bit more besides, unruly in its verboseness, but I
> > won't bother trying to interpret the rest of its output.

> It's one reason I don't use it much.  It spits out so much, it's about
> overwhelming.  Then again, it is usually pointing out the stuff that is
> no longer needed in some file somewhere.  Also, the longer you wait
> between runs, the more it spits out. 
> 
> It seems you can't win with that thing.  LOL 

You can win, by running it reasonably often and actually doing something
about the output. Ignore a few lines and they soon become a few more, and
then a few more still...


-- 
Neil Bothwick

"We demand rigidly defined areas of doubt and uncertainty!"

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] This nite's switch to "full multilib"

[Dale]

Neil Bothwick wrote:
> On Sat, 04 Apr 2015 07:33:06 -0500, Dale wrote:
>
>>>> eix-test-obsolete   
>>> Many thanks, it certainly seems to.
>>>
>>> It seems to do a bit more besides, unruly in its verboseness, but I
>>> won't bother trying to interpret the rest of its output.
>> It's one reason I don't use it much.  It spits out so much, it's about
>> overwhelming.  Then again, it is usually pointing out the stuff that is
>> no longer needed in some file somewhere.  Also, the longer you wait
>> between runs, the more it spits out. 
>>
>> It seems you can't win with that thing.  LOL 
> You can win, by running it reasonably often and actually doing something
> about the output. Ignore a few lines and they soon become a few more, and
> then a few more still...
>
>

Thing is, it seems to grow faster than I can clean up.  I'm scared to
even run it now.  It would likely take me a week to get a clean output. 
ROFL  It's been a long time since I ran it.  I may be better off to move
the files, see what emerge wants to change and add stuff back.  Just
saying. 

One thing tho, having fewer stuff in those files may speed emerge up
just a tiny amount.  ;-) 

Dale

:-)  :-)

Re: [gentoo-user] This nite's switch to "full multilib"

[Neil Bothwick]

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

On Sun, 05 Apr 2015 02:24:13 -0500, Dale wrote:

> >> It seems you can't win with that thing.  LOL   
> > You can win, by running it reasonably often and actually doing
> > something about the output. Ignore a few lines and they soon become a
> > few more, and then a few more still...

> Thing is, it seems to grow faster than I can clean up.  I'm scared to
> even run it now.  It would likely take me a week to get a clean output. 
> ROFL  It's been a long time since I ran it.  I may be better off to move
> the files, see what emerge wants to change and add stuff back.  Just
> saying. 

I got into that situation once, you just need to bite the bullet and work
through the output. It's not as bad as it looks as the same entry can
cause multiple reports, so once you clean up a couple of entries the
output can get significantly shorter.

It's like being a teenager again, the longer you leave tidying your room,
the longer it takes when your mum makes you do it :)


-- 
Neil Bothwick

Member, National Association For Tagline Assimilators (NAFTA)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] This nite's switch to "full multilib"

[Dale]

Neil Bothwick wrote:
> On Sun, 05 Apr 2015 02:24:13 -0500, Dale wrote:
>
>>>> It seems you can't win with that thing.  LOL   
>>> You can win, by running it reasonably often and actually doing
>>> something about the output. Ignore a few lines and they soon become a
>>> few more, and then a few more still...
>> Thing is, it seems to grow faster than I can clean up.  I'm scared to
>> even run it now.  It would likely take me a week to get a clean output. 
>> ROFL  It's been a long time since I ran it.  I may be better off to move
>> the files, see what emerge wants to change and add stuff back.  Just
>> saying. 
> I got into that situation once, you just need to bite the bullet and work
> through the output. It's not as bad as it looks as the same entry can
> cause multiple reports, so once you clean up a couple of entries the
> output can get significantly shorter.
>
> It's like being a teenager again, the longer you leave tidying your room,
> the longer it takes when your mum makes you do it :)
>
>

Well, just for giggles I ran it.  Ain't no way I got time to go through
all that right now.  Heck, it took several minutes for it to just to go
through all that stuff.  O_O 

Maybe one day.  Maybe. 

Dale

:-)  :-) 

Re: [gentoo-user] This nite's switch to "full multilib"

[Neil Bothwick]

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

On Sun, 05 Apr 2015 04:41:33 -0500, Dale wrote:

> > I got into that situation once, you just need to bite the bullet and
> > work through the output. It's not as bad as it looks as the same
> > entry can cause multiple reports, so once you clean up a couple of
> > entries the output can get significantly shorter.
> >
> > It's like being a teenager again, the longer you leave tidying your
> > room, the longer it takes when your mum makes you do it :)
> >
> >  
> 
> Well, just for giggles I ran it.  Ain't no way I got time to go through
> all that right now.  Heck, it took several minutes for it to just to go
> through all that stuff.  O_O 

Then don't. Just clean up the output from one of the tests, the one with
the shortest output if you prefer.

Or leave /etc/portage full of cruft and crap and fix any problem it may
cause later on, when you have even less time ;-)


-- 
Neil Bothwick

Secret hacker rule #11: hackers read manuals.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] This nite's switch to "full multilib"

[Rich Freeman]

On Sun, Apr 5, 2015 at 8:09 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
>
> Or leave /etc/portage full of cruft and crap and fix any problem it may
> cause later on, when you have even less time ;-)
>

Hmm, have an hour of free time now, at the cost of maybe having an
hour less of free time a year from now, maybe.  That's a hard choice.
:)

-- 
Rich

Re: [gentoo-user] This nite's switch to "full multilib"

[Neil Bothwick]

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

On 5 April 2015 14:27:27 BST, Rich Freeman <rich0@gentoo.org> wrote:
> On Sun, Apr 5, 2015 at 8:09 AM, Neil Bothwick <neil@digimed.co.uk>
> wrote:
> >
> > Or leave /etc/portage full of cruft and crap and fix any problem it
> may
> > cause later on, when you have even less time ;-)
> >
> 
> Hmm, have an hour of free time now, at the cost of maybe having an
> hour less of free time a year from now, maybe.  That's a hard choice.
> :)
> 
> -- 
> Rich

Give up 20 minutes when I can afford it or maybe lose a couple of hours and my remaining hair if it goes tits up later,  that's an interesting gamble :) 
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 1082 bytes --]

Re: [gentoo-user] This nite's switch to "full multilib"

[Rich Freeman]

On Sun, Apr 5, 2015 at 5:07 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> It's like being a teenager again, the longer you leave tidying your room,
> the longer it takes when your mum makes you do it :)
>

Don't want to harp on it, but I almost never have to clean my world
file, and when I do I don't need any tools at all to make it happen.
This is because the world file revolves around me and my true
requirements, and not an endless list of hints to try to get the
package manager to do what I want it to do.

I think we need to get away from solutions that clutter up
configuration in the first place.  I'm not under any illusions that
this will ever be perfect, but I do think we can do better.

-- 
Rich

Re: [gentoo-user] This nite's switch to "full multilib"

[Neil Bothwick]

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

On Sun, 5 Apr 2015 07:21:01 -0400, Rich Freeman wrote:

> > It's like being a teenager again, the longer you leave tidying your
> > room, the longer it takes when your mum makes you do it :)
> >  
> 
> Don't want to harp on it, but I almost never have to clean my world
> file, and when I do I don't need any tools at all to make it happen.
> This is because the world file revolves around me and my true
> requirements, and not an endless list of hints to try to get the
> package manager to do what I want it to do.

We're talking about /etc/portage/package.* here. not @world. I too rarely
need to touch world.

> I think we need to get away from solutions that clutter up
> configuration in the first place.  I'm not under any illusions that
> this will ever be perfect, but I do think we can do better.

Agreed, but this is about managing the options we have now. Like it or
not, we need to put extra entries in package.use and eix-test-obsolete is
the best current way of removing them when they're no longer needed, as
portage's autounmask facility only adds to the file, it never cleans up
after itself.


-- 
Neil Bothwick

Oxymoron: Reagan memoirs.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[gentoo-user] Re: This nite's switch to "full multilib"

[James]

Neil Bothwick <neil <at> digimed.co.uk> writes:


> > I think we need to get away from solutions that clutter up
> > configuration in the first place.  I'm not under any illusions that
> > this will ever be perfect, but I do think we can do better.

Amen.


> Agreed, but this is about managing the options we have now. Like it or
> not, we need to put extra entries in package.use and eix-test-obsolete is
> the best current way of removing them when they're no longer needed, as
> portage's autounmask facility only adds to the file, it never cleans up
> after itself.

And Amen, brother. As stated before, it reminds one of parenting where
teenagers must take responsibility to clean up after themselves. GLEP 64
will go a long way to providing the framework for tool/code creation
to clean up many, many errant files on gentoo. In fact if one were
to desire building a system that is fully verified, you'd need something
like GLEP-64 as the beginning or organization and tracking of what
it's installed. Granted EAPI-5 is moving in the right direction, and it
looks like we are moving to make that a requirement for all packages on gentoo.

 On my journey to learn more deeply about gentoo, I have looked closely
at dozens and dozens of packages, maybe over 100. It is a freaking mess.
Little consistency or structure or requirements from long ago, still
have their remnants of effects.

I find eix-test-obsolete (ETO) only produces valid things to address, at the
lower end of the 20% mark. There is no way to 'tame the best' on it's sputum
so I do not use it.  The best ETO can do is suggest a list of things to look
at (manually) for possible need of attention. If folks  are really concerned
about efficiency; it is quite easy to "prune" portage manually.  I use
scripts based on size or date, when I feel the need. Remove something
important?: just --sync and download again; no worries. After all one can
--sync to get something back if it is lost and of value.  As I find
attachment to codes that I want some permanency, I just replicate them into
/usr/local/portage. I  often like to keep old codes around (a very valid
reason for 2T drives) to look at various codes and how they evolved. The
various eclasses one package uses versus the eclasses chosen by another dev
to package up a code. ETO thinks old codes and old kernels are cruft. I
think the myriad of files spewed when some ebuilds are installed are cruft
and they are often not accounted for when packages are removed. 

So let's all get behind GLEP-64 so folks can build some real tools
for cleaning up and maintaining gentoo based systems.  If you
really want to "get up" on this issue, read up on "Directed Graphs",
particularly DAGs, and you'll begin to understand  what is possible
if GLEP-64 is *pushed* via the user base as a demand for those motivated
devs to move us to a GLEP-64 compliant gentoo. 

Currently, unless you manually groom your gentoo system(s), you end up with
a pig_sty as remnants of  codes, installs, configs etc etc just pile up and
it takes a "one off" inspection to filter many files as to "should I stay or
should I go now" (old punk lyrics....).


It is way past time for gentoo to offer robust tools for monitoring
and cleaning out cruft. What is cruft, needs to definable by the system
owner. So the codes and tools will need to be flexible to fit the needs and
desires of the user base, and therein we have much work to do, imho.


hth,
James

Re: [gentoo-user] This nite's switch to "full multilib"

[Graham Murray]

Neil Bothwick <neil@digimed.co.uk> writes:

> You can win, by running it reasonably often and actually doing something
> about the output. Ignore a few lines and they soon become a few more, and
> then a few more still...

One thing I have noticed in its output is where it lists "installed
packages with a version not in the database (or masked)", this is often
(in my case) due to slotted packages where portage has only kept the
'highest numbered' slot updated. Is there any magic incantation to emerge
which would make it keep all installed slots updated? 

Re: [gentoo-user] This nite's switch to "full multilib"

[Neil Bothwick]

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

On Sat, 4 Apr 2015 10:39:18 +0100, Stroller wrote:

> > eix-test-obsolete   
> 
> Many thanks, it certainly seems to.
> 
> It seems to do a bit more besides, unruly in its verboseness, but I
> won't bother trying to interpret the rest of its output.

eix-test-obsolete is only a shell script that calls eix in test mode
several times, with different options. Make a copy of the script that
includes only the tests you want.


-- 
Neil Bothwick

Fer sail cheep, Windows spel chekcer, wurks grate

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] This nite's switch to "full multilib"

[Neil Bothwick]

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

On Fri, 3 Apr 2015 09:00:52 +0100, Stroller wrote:

> Slightly OT, but are there any tools for cleaning out old entries?
> 
> I could write a script to go through package.keywords line by line and,
> for packages where the entry is =package-version.1.2.3, delete those
> lines where a newer version of the package is now installed on the
> system.
> 
eix-test-obsolete will do this, but it won't handle all cases. If foo
requires libbar to have a particular USE flag and you unmerge foo, but
libbar is still needed by something else, it will continue to be built
with the unnecessary flag.


-- 
Neil Bothwick

- We are but packets in the internet of Life-

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] This nite's switch to "full multilib"

[Stroller]

On Thu, 2 April 2015, at 4:37 pm, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> 
> I prefer it this way.  I do not want all the nice easy-to read/edit
> configuration stuff in /etc/portage encrypted some Windows Registry
> break-alike.

What's bad about the Windows registry is that its proprietary file format is both poorly constructed (or, rather "lacking design") and obscure, and its reputation was for brittleness was built when it was stored on FAT file systems and corrupted when Windows crashed and had to be hard rebooted.

If you want to store a lot of stuff, then databases are a valid solution. If there's something wrong with sqlite or BerkeleyDB then argue against them, but don't base your objections on a strawman.

Stroller.

Re: [gentoo-user] This nite's switch to "full multilib"

[Fernando Rodriguez]

On Friday, April 03, 2015 8:52:18 AM Stroller wrote:
> 
> On Thu, 2 April 2015, at 4:37 pm, Grant Edwards <grant.b.edwards@gmail.com> 
wrote:
> > 
> > I prefer it this way.  I do not want all the nice easy-to read/edit
> > configuration stuff in /etc/portage encrypted some Windows Registry
> > break-alike.
> 
> What's bad about the Windows registry is that its proprietary file format is 
both poorly constructed (or, rather "lacking design") and obscure, and its 
reputation was for brittleness was built when it was stored on FAT file systems 
and corrupted when Windows crashed and had to be hard rebooted.

And that it became a central repository for *everything*, it wasn't too bad as 
just a COM registry on Windows 3.11. Microsoft's been pushing developers to 
use config files for years but they themselves keep using the registry poorly. 
Install the latest visual studio, then uninstall it and search your registry. 
You will find over 20,000 registry entries left behind.

> If you want to store a lot of stuff, then databases are a valid solution. If 
there's something wrong with sqlite or BerkeleyDB then argue against them, but 
don't base your objections on a strawman.

I agree that a binary db for portage is a good idea, only because it's 
ridiculous how long it takes portage to resolve dependencies. It could be just 
a cache that gets rebuilt after syncing or updating config files.

-- 
Fernando Rodriguez

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Rich Freeman]

On Thu, Apr 2, 2015 at 12:42 AM, Sebastian Beßler
<sebastian@darkmetatron.de> wrote:
> On 01.04.2015 19:28, Róbert Čerňanský wrote:
>
>> Big advantage of automatic deps over --autounmask is that auto deps
>> would not mess with user configuration files in /etc.  Changed USE
>> flags would be stored internally by portage.
>
> Ok, but then you need a database (another file in /etc/portage/) for all of
> the active use flags that are set by the installed packages. That or every
> emerge has to scan and parse every ebuild of all installed packages, adding
> a high delay.

This is what portage already has to do with the list of installed
packages.  Doing it for installed USE flags is just more of the same.
I suspect that portage has to do this anyway just to make sure that
the current config is still valid, or to see if --newuse should cause
a change, and so on.

-- 
Rich

Re: [gentoo-user] This nite's switch to "full multilib"

[Neil Bothwick]

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

On Mon, 30 Mar 2015 12:02:23 +0200, Stefan G. Weichinger wrote:

> >> Hmm ... I don't think setting abi_x86_32 globally is necessary,
> >> unless you want to have 32bit libs for ALL packages that these exist
> >> for, whether you use them or not.  I mean that for Skype you have no
> >> alternative at present, but if you don't use Skype then you would
> >> not need the 32bit versions of Skype's dependencies.  If my
> >> understanding is wrong, Alan will soon put me right on this.  :-)  
> > 
> > 
> > You understand it just fine.  
> 
> OK, then so why do I have to edit files to tell the system to USE this
> and that after the system tells me it needs that ... ?
> 
> Why isn't this taken care of within portage itself?

Because this is Gentoo and you are in charge of portage, not the other
way around. Portage goes as far as it can without trampling over your
choices by saying "these are the changes I need you to make, press Y to
accept them". It's not like you have to add one atom to package.use
manually, run emerge again, add another etc.


-- 
Neil Bothwick

Why is the word abbreviation so long?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] This nite's switch to "full multilib"

[Róbert Čerňanský]

On Mon, 30 Mar 2015 11:31:15 +0100
Neil Bothwick <neil@digimed.co.uk> wrote:

> On Mon, 30 Mar 2015 12:02:23 +0200, Stefan G. Weichinger wrote:
> 
> > >> Hmm ... I don't think setting abi_x86_32 globally is necessary,
> > >> unless you want to have 32bit libs for ALL packages that these
> > >> exist for, whether you use them or not.  I mean that for Skype
> > >> you have no alternative at present, but if you don't use Skype
> > >> then you would not need the 32bit versions of Skype's
> > >> dependencies.  If my understanding is wrong, Alan will soon put
> > >> me right on this.  :-)  
> > > 
> > > 
> > > You understand it just fine.  
> > 
> > OK, then so why do I have to edit files to tell the system to USE
> > this and that after the system tells me it needs that ... ?
> > 
> > Why isn't this taken care of within portage itself?
> 
> Because this is Gentoo and you are in charge of portage, not the other
> way around. Portage goes as far as it can without trampling over your
> choices by saying "these are the changes I need you to make, press Y
> to accept them". It's not like you have to add one atom to package.use
> manually, run emerge again, add another etc.

With --pretend and --ask options you would still be in charge.  Execute
'emerge -pv foo', if you do not like the changes then tweak USE
settings in package.use.  I would not feel any less in control if I
could see changes that portage wants to do and could force my USE
settings in package.use.

Robert


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

Re: [gentoo-user] This nite's switch to "full multilib"

[Rich Freeman]

On Wed, Apr 1, 2015 at 1:50 PM, Róbert Čerňanský <openhs@tightmail.com> wrote:
> On Mon, 30 Mar 2015 11:31:15 +0100
> Neil Bothwick <neil@digimed.co.uk> wrote:
>
>> On Mon, 30 Mar 2015 12:02:23 +0200, Stefan G. Weichinger wrote:
>>
>> > >> Hmm ... I don't think setting abi_x86_32 globally is necessary,
>> > >> unless you want to have 32bit libs for ALL packages that these
>> > >> exist for, whether you use them or not.  I mean that for Skype
>> > >> you have no alternative at present, but if you don't use Skype
>> > >> then you would not need the 32bit versions of Skype's
>> > >> dependencies.  If my understanding is wrong, Alan will soon put
>> > >> me right on this.  :-)
>> > >
>> > >
>> > > You understand it just fine.
>> >
>> > OK, then so why do I have to edit files to tell the system to USE
>> > this and that after the system tells me it needs that ... ?
>> >
>> > Why isn't this taken care of within portage itself?
>>
>> Because this is Gentoo and you are in charge of portage, not the other
>> way around. Portage goes as far as it can without trampling over your
>> choices by saying "these are the changes I need you to make, press Y
>> to accept them". It's not like you have to add one atom to package.use
>> manually, run emerge again, add another etc.
>
> With --pretend and --ask options you would still be in charge.  Execute
> 'emerge -pv foo', if you do not like the changes then tweak USE
> settings in package.use.  I would not feel any less in control if I
> could see changes that portage wants to do and could force my USE
> settings in package.use.
>

Honestly, I tend to agree with this approach.

Imagine if when you typed "emerge kde-meta" the emerge program told
you that you need to add the following 400 lines to your package
installation list.  Then we create a install-list-cleanup program that
looks at your world file and determines what stuff you have in your
package installation list that aren't needed any longer.

When it comes to what packages are installed the design is to have the
user stick the stuff they really care about in the world file and let
the PM figure out how to make it happen.  You can override masks in
config files, but the general intent is that you don't have to do this
most of the time.  Why not make USE flags work the same way?

Why can't emerge steam figure out that half the system needs to be
rebuilt with 32-bit support, and then later emerge --depclean steam
figures out that half the system can be rebuilt without 32-bit
support?  You could still specify global or package.use settings when
you have specific preferences, of course.  However, you wouldn't have
to do that just to satisfy dependencies unless there is a blocker that
portage can't figure out itself.  That is also analogous to what
happens when virtuals today - sometimes you have to manually
uninstall/install something to get portage past a block, and maybe
that will be needed with USE flags too.

I think we've just gotten into a mode where we automate user
configuration instead of eliminating the need for it.

-- 
Rich

Re: [gentoo-user] This nite's switch to "full multilib"

[Róbert Čerňanský]

On Wed, 1 Apr 2015 14:05:28 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Wed, Apr 1, 2015 at 1:50 PM, Róbert Čerňanský
> <openhs@tightmail.com> wrote:
> > On Mon, 30 Mar 2015 11:31:15 +0100
> > Neil Bothwick <neil@digimed.co.uk> wrote:
> >
> >> On Mon, 30 Mar 2015 12:02:23 +0200, Stefan G. Weichinger wrote:
> >>
> >> > >> Hmm ... I don't think setting abi_x86_32 globally is
> >> > >> necessary, unless you want to have 32bit libs for ALL
> >> > >> packages that these exist for, whether you use them or not.
> >> > >> I mean that for Skype you have no alternative at present, but
> >> > >> if you don't use Skype then you would not need the 32bit
> >> > >> versions of Skype's dependencies.  If my understanding is
> >> > >> wrong, Alan will soon put me right on this.  :-)
> >> > >
> >> > >
> >> > > You understand it just fine.
> >> >
> >> > OK, then so why do I have to edit files to tell the system to USE
> >> > this and that after the system tells me it needs that ... ?
> >> >
> >> > Why isn't this taken care of within portage itself?
> >>
> >> Because this is Gentoo and you are in charge of portage, not the
> >> other way around. Portage goes as far as it can without trampling
> >> over your choices by saying "these are the changes I need you to
> >> make, press Y to accept them". It's not like you have to add one
> >> atom to package.use manually, run emerge again, add another etc.
> >
> > With --pretend and --ask options you would still be in charge.
> > Execute 'emerge -pv foo', if you do not like the changes then tweak
> > USE settings in package.use.  I would not feel any less in control
> > if I could see changes that portage wants to do and could force my
> > USE settings in package.use.
> >
> 
> Honestly, I tend to agree with this approach.
> 
> Imagine if when you typed "emerge kde-meta" the emerge program told
> you that you need to add the following 400 lines to your package
> installation list.  Then we create a install-list-cleanup program that
> looks at your world file and determines what stuff you have in your
> package installation list that aren't needed any longer.

Very good analogy.  Except that for current USE flag situation we do not
and even can not provide such install-list-cleanup program.  There is
no way to tell whether an entry in package.use is a user choice or it
is there just to satisfy some dependency.  Therefore no program can
tell if it can be cleaned or not.  Which is another manifestation why
current approach is fundamentally wrong.

> When it comes to what packages are installed the design is to have the
> user stick the stuff they really care about in the world file and let
> the PM figure out how to make it happen.  You can override masks in
> config files, but the general intent is that you don't have to do this
> most of the time.  Why not make USE flags work the same way?
> 
> Why can't emerge steam figure out that half the system needs to be
> rebuilt with 32-bit support, and then later emerge --depclean steam
> figures out that half the system can be rebuilt without 32-bit
> support?  You could still specify global or package.use settings when
> you have specific preferences, of course.  However, you wouldn't have
> to do that just to satisfy dependencies unless there is a blocker that
> portage can't figure out itself.  That is also analogous to what
> happens when virtuals today - sometimes you have to manually
> uninstall/install something to get portage past a block, and maybe
> that will be needed with USE flags too.
> 
> I think we've just gotten into a mode where we automate user
> configuration instead of eliminating the need for it.
> 


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

Re: [gentoo-user] This nite's switch to "full multilib"

[Neil Bothwick]

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

On Wed, 1 Apr 2015 14:05:28 -0400, Rich Freeman wrote:

> I think we've just gotten into a mode where we automate user
> configuration instead of eliminating the need for it.

That's a good way of looking at it.

Most USE flags are not set by the user by by the profile. By selecting a
particular profile you are telling portage to set up suitable defaults
for, say, a KDE desktop. Portage should be able to continue to manage
that situation and, if a different USE setting is required for a
particular situation, and nothing in the user's own settings overrides
it, portage should be able to take the appropriate action.

The other way of looking at it, from this particular situation, is that
maybe he USE system is being forced to take care of more than it was
supposed to. Should ABI_* settings even be part of USE?


-- 
Neil Bothwick

A friend in need may turn out to be a nuisance.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] This nite's switch to "full multilib"

[Rich Freeman]

On Mon, Mar 30, 2015 at 6:02 AM, Stefan G. Weichinger <lists@xunil.at> wrote:
>
> OK, then so why do I have to edit files to tell the system to USE this
> and that after the system tells me it needs that ... ?
>
> Why isn't this taken care of within portage itself?
>
> I don't *want* to decide 32bit or not ... (I like that I *can* ...)
>

This goes way beyond 32-bit.

The way things work in Gentoo right now is that portage can decide to
install a package at any time without any config file changes (unless
it is keyword/package masked).  However, it can't change the USE
configuration of a package unless this ends up in a config file.

In a sense I think giving portage more freedom to do this would be
better.  It does increase the likelihood of blockers, but we already
deal with those for package blocks.  It would also mean that a proper
depclean might actually involve package rebuilds (unless we make
depclean just remove stuff, and an emerge -N rebuild stuff).

I'm trying to think of what the downside is to just letting portage
set the flags however seems best unless a flag is explicitly set or
unset in configuration.  I can't think of any issues offhand - I think
that most of the work that needs to be done by emerge to calculate
deps needs to be done anyway.  Obviously it would take effort to do.

I ended up with 800 lines being added to my package.use, which now
constitutes 2/3rds of the file.  Granted, most of those are comments.

Some of the comments are also less than ideal, like:
# required by media-libs/libgphoto2-2.5.7
# required by kde-base/kamera-4.14.3
# required by kde-base/kdegraphics-meta-4.14.3
# required by kde-base/kde-meta-4.14.3
# required by @selected
# required by @world (argument)
>=virtual/libusb-1-r1 abi_x86_32

This tends to imply that kde-meta needs 32-bit libusb.  I suspect that
some other package does need 32-bit libgphoto2, which then needs
32-bit libusb, but kde-meta shows up in the comment instead.

The packages that gave me the most trouble were wine and steam.  I
don't think there were any problems with them - they just pull in a
lot of 32-bit deps.

-- 
Rich

Re: [gentoo-user] This nite's switch to "full multilib"

[Frank Steinmetzger]

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

On Mon, Mar 30, 2015 at 10:23:21AM +0100, Mick wrote:

> Hmm ... I don't think setting abi_x86_32 globally is necessary, unless you 
> want to have 32bit libs for ALL packages that these exist for, whether you use 
> them or not.  I mean that for Skype you have no alternative at present, but if 
> you don't use Skype then you would not need the 32bit versions of Skype's 
> dependencies.  If my understanding is wrong, Alan will soon put me right on 
> this.  :-)


I used this opportunity to finally rid myself of Skype entirely. Nobody
knows how it’s still possible to use that Microsoft infested spyware on Linux
anway, and unless I install pulseaudio, it doesn’t give me any more features
than Kopete already does. Once I did emerge -C skype, there even weren’t any
blockers left or remerges with x32 abi¹. Packages to install for -uD world
went from 117 to 41. So good riddance.

¹ That is on my small laptop. My big desktop has Wine installed, let’s see
what it says when I’m back home in two days.
-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

Seize the carp.

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

Re: [gentoo-user] This nite's switch to "full multilib"

[Frank Steinmetzger]

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

On Fri, Apr 03, 2015 at 12:40:20AM +0200, me, myself and I wrote:

> I used this opportunity to finally rid myself of Skype entirely. Nobody
> knows how it’s still possible to use that Microsoft infested spyware on Linux
> anway,

how it’s possible → how long it’s still possible

-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

Never trust an atom... they make up everything!

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

Re: [gentoo-user] This nite's switch to "full multilib"

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 565 bytes --]

On Friday 03 Apr 2015 00:08:53 Frank Steinmetzger wrote:
> On Fri, Apr 03, 2015 at 12:40:20AM +0200, me, myself and I wrote:
> > I used this opportunity to finally rid myself of Skype entirely. Nobody
> > knows how it’s still possible to use that Microsoft infested spyware on
> > Linux anway,
> 
> how it’s possible → how long it’s still possible

When people you need to communicate with on MSWindows boxes only know how to 
manage Skype-ware and you don't run a SIP proxy server yourself, your choices 
reduce somewhat.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] This nite's switch to "full multilib"

[Stroller]

On Fri, 3 April 2015, at 12:25 am, Mick <michaelkintzios@gmail.com> wrote:
> 
> When people you need to communicate with on MSWindows boxes only know how to 
> manage Skype-ware and you don't run a SIP proxy server yourself, your choices 
> reduce somewhat.

We'll have to reincarnate Alexander Graham Bell and see if he can come up with a solution.

Stroller.

Re: [gentoo-user] This nite's switch to "full multilib"

[Dale]

Alan McKinnon wrote:
> On 30/03/2015 00:10, Stefan G. Weichinger wrote:
>> Am 29.03.2015 um 20:16 schrieb Alan McKinnon:
>>
>>>> I have to do that for 195 ebuilds here and really wonder if that is
>>>> correct in the end ....
>>>
>>>
>>> It's a horrible solution, you are right. The problem is that it's not
>>> your 32 bit apps that have to be listed, it's all the libs and deps they
>>> have that need 32 bit versions to be built.
>>>
>>> If you have a fast cpu, much disk space and don't care about using some
>>> extra resources, you can always add USE="abi_xx86_32" to make.conf and
>>> make it global. Every package that supports building 32 bit versions
>>> will then be recompiled.
>> Is that as it is meant to be or some not-so-ideal-switch that will soon
>> get some polishing?
>>
>> IMO I shouldn't have to list hundreds of packages (I had to add more and
>> more) in some non-default-list ... even when I decide to run unstable
>> (~amd64).
>>
>> My main system isn't that special at all, gnome, systemd, libreoffice,
>> thunderbird, some browsers ...
>>
>> Stuff like that makes me really wonder if I spend too much of my life
>> time struggling with doing *updates*
>>
>> I like Gentoo, you all know, but things like that scare me off a bit.
> This is Gentoo, it's all about choice. Sometimes there's a downside,
> like a very long package.use to define to Portage exactly what your
> choice really is.
>
> Setting the flag globally is covered in today's news item on the matter,
> so I assume the devs are supporting it
>
>


Dang.  I had to add about 90 packages to my package.use and some more to
the keyword file. 

I wonder if make.conf would be better in my case too?  My use file just
grew my a huge amount. 

Dale

:-)  :-) 

Re: [gentoo-user] This nite's switch to "full multilib"

[Neil Bothwick]

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

On Mon, 30 Mar 2015 04:12:59 -0500, Dale wrote:

> Dang.  I had to add about 90 packages to my package.use and some more to
> the keyword file. 
> 
> I wonder if make.conf would be better in my case too?  My use file just
> grew my a huge amount. 

You package.use has grown by one filesystem block at most, how much extra
disk space and CPU cycles would you use by compiling 32 bit options for
every package that has them?

If you use a single file for package.use, it does make it far more
cumbersome to manage, but that's why I switched to separate files many
years ago.


-- 
Neil Bothwick

Sigh - An amplifier for people who suffer in silence

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] This nite's switch to "full multilib"

[Dale]

Neil Bothwick wrote:
> On Mon, 30 Mar 2015 04:12:59 -0500, Dale wrote:
>
>> Dang.  I had to add about 90 packages to my package.use and some more to
>> the keyword file. 
>>
>> I wonder if make.conf would be better in my case too?  My use file just
>> grew my a huge amount. 
> You package.use has grown by one filesystem block at most, how much extra
> disk space and CPU cycles would you use by compiling 32 bit options for
> every package that has them?


I wasn't worried about disk space, just that I rarely use entries in
that file.  Heck, it's enough to manage the other package.* files already. 


>
> If you use a single file for package.use, it does make it far more
> cumbersome to manage, but that's why I switched to separate files many
> years ago.
>
>

I've tried separate files and having them all in one file.  Either way,
each entry requires a person to manage it.  For me at least, it's six of
one and half a dozen of the other. ;-)

Dale

:-)  :-) 

Re: [gentoo-user] This nite's switch to "full multilib"

[Neil Bothwick]

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

On Mon, 30 Mar 2015 05:59:24 -0500, Dale wrote:

> Neil Bothwick wrote:
> > On Mon, 30 Mar 2015 04:12:59 -0500, Dale wrote:

> >> I wonder if make.conf would be better in my case too?  My use file
> >> just grew my a huge amount. 
> > You package.use has grown by one filesystem block at most, how much
> > extra disk space and CPU cycles would you use by compiling 32 bit
> > options for every package that has them?

> I wasn't worried about disk space, just that I rarely use entries in
> that file.  Heck, it's enough to manage the other package.* files
> already. 

I wonder if it may have been better to update the multilib profiles to
set the flag globally be default, it would make life easier and you could
still turn it off if you wanted to.

> > If you use a single file for package.use, it does make it far more
> > cumbersome to manage, but that's why I switched to separate files many
> > years ago.

> I've tried separate files and having them all in one file.  Either way,
> each entry requires a person to manage it.  For me at least, it's six of
> one and half a dozen of the other. ;-)

Actually, it's one big one vs six small ones :)

I find the separate files much easier to manage as all the settings for
each package are kept separate, and easily removed or changed - for
example when I stop using the package. The alternative would be to
comment every entry in the file so I know why I put it there and whether
I still needed it.


-- 
Neil Bothwick

If a book about failures doesn't sell, is it a success?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] This nite's switch to "full multilib"

[Peter Humphrey]

On Monday 30 March 2015 13:40:12 Neil Bothwick wrote:

[Re package.use]

> I find the separate files much easier to manage as all the settings for
> each package are kept separate, and easily removed or changed - for
> example when I stop using the package. The alternative would be to
> comment every entry in the file so I know why I put it there and whether
> I still needed it.

To each his own, of course, but I find the single file much easier to 
manage. I only ever put things in there if they're required by portage, and 
the occasional eix-test-obsolete checks that I'm still efficient.

-- 
Rgds
Peter.

Re: [gentoo-user] This nite's switch to "full multilib"

[Dale]

Neil Bothwick wrote:
> On Mon, 30 Mar 2015 05:59:24 -0500, Dale wrote:
>
>> Neil Bothwick wrote:
>>> On Mon, 30 Mar 2015 04:12:59 -0500, Dale wrote:
>>>> I wonder if make.conf would be better in my case too?  My use file
>>>> just grew my a huge amount. 
>>> You package.use has grown by one filesystem block at most, how much
>>> extra disk space and CPU cycles would you use by compiling 32 bit
>>> options for every package that has them?
>> I wasn't worried about disk space, just that I rarely use entries in
>> that file.  Heck, it's enough to manage the other package.* files
>> already. 
> I wonder if it may have been better to update the multilib profiles to
> set the flag globally be default, it would make life easier and you could
> still turn it off if you wanted to.

I was wondering the same thing but I guess they have some reason for
doing it this way, that we don't know about it would seem.   ;-)

>>> If you use a single file for package.use, it does make it far more
>>> cumbersome to manage, but that's why I switched to separate files many
>>> years ago.
>> I've tried separate files and having them all in one file.  Either way,
>> each entry requires a person to manage it.  For me at least, it's six of
>> one and half a dozen of the other. ;-)
> Actually, it's one big one vs six small ones :)
>
> I find the separate files much easier to manage as all the settings for
> each package are kept separate, and easily removed or changed - for
> example when I stop using the package. The alternative would be to
> comment every entry in the file so I know why I put it there and whether
> I still needed it.
>
>

What I ran into, I'd update say KDE.  It would need some packages added
to the keyword file.  Some may not be KDE but packages that KDE depends
on.  Well, should those that are KDE go into the KDE file and the ones
that are dependencies but not KDE go into a file of its own or what?  If
I split it, how do I keep up with it?  If I don't split it, then I have
a larger file to deal with.  After running in circles with that for a
while, I just went with one file and hoped for the best.  lol 

Dale

:-)  :-) 

Re: [gentoo-user] This nite's switch to "full multilib"

[Neil Bothwick]

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

On Mon, 30 Mar 2015 08:42:07 -0500, Dale wrote:

> > I find the separate files much easier to manage as all the settings
> > for each package are kept separate, and easily removed or changed -
> > for example when I stop using the package. The alternative would be to
> > comment every entry in the file so I know why I put it there and
> > whether I still needed it.

> What I ran into, I'd update say KDE.  It would need some packages added
> to the keyword file.  Some may not be KDE but packages that KDE depends
> on.  Well, should those that are KDE go into the KDE file and the ones
> that are dependencies but not KDE go into a file of its own or what? 

You put them wherever you want! I put them in kde, because that's what
they are for. That way I know that those entries were required by KDE
without having to fill the single file with comments.


-- 
Neil Bothwick

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] This nite's switch to "full multilib"

[Dale]

Neil Bothwick wrote:
> On Mon, 30 Mar 2015 08:42:07 -0500, Dale wrote:
>
>>> I find the separate files much easier to manage as all the settings
>>> for each package are kept separate, and easily removed or changed -
>>> for example when I stop using the package. The alternative would be to
>>> comment every entry in the file so I know why I put it there and
>>> whether I still needed it.
>> What I ran into, I'd update say KDE.  It would need some packages added
>> to the keyword file.  Some may not be KDE but packages that KDE depends
>> on.  Well, should those that are KDE go into the KDE file and the ones
>> that are dependencies but not KDE go into a file of its own or what? 
> You put them wherever you want! I put them in kde, because that's what
> they are for. That way I know that those entries were required by KDE
> without having to fill the single file with comments.
>
>


Yea.  We just batting ideas around.  For me tho, it just turned into a
nightmare.  If I needed to change something, which file is it in?  At
one time I had a dozen or so files and digging through each one of them
wastes time.  If I have just one file, I open the file and do a ctrl f
and type in what I am looking for.  Of course, some of the script geeks
prolly have a sneaky way of searching and finding out which file it is
in but I'm not one of those, most days for sure. 

Anyway, all the diggin just got old for me.  You likely have a easy way
of finding it whereas I don't.  ;-)

Dale

:-)  :-)

Re: [gentoo-user] This nite's switch to "full multilib"

[Neil Bothwick]

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

On Mon, 30 Mar 2015 19:46:39 -0500, Dale wrote:

> Yea.  We just batting ideas around.  For me tho, it just turned into a
> nightmare.  If I needed to change something, which file is it in?  At
> one time I had a dozen or so files and digging through each one of them
> wastes time.  If I have just one file, I open the file and do a ctrl f
> and type in what I am looking for.  Of course, some of the script geeks
> prolly have a sneaky way of searching and finding out which file it is
> in but I'm not one of those, most days for sure. 


grep :)


-- 
Neil Bothwick

If at first you don't succeed, you'll get a lot of free advice from
folks who didn't succeed either.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] This nite's switch to "full multilib"

[Alan McKinnon]

On 31/03/2015 02:46, Dale wrote:
> Neil Bothwick wrote:
>> On Mon, 30 Mar 2015 08:42:07 -0500, Dale wrote:
>>
>>>> I find the separate files much easier to manage as all the settings
>>>> for each package are kept separate, and easily removed or changed -
>>>> for example when I stop using the package. The alternative would be to
>>>> comment every entry in the file so I know why I put it there and
>>>> whether I still needed it.
>>> What I ran into, I'd update say KDE.  It would need some packages added
>>> to the keyword file.  Some may not be KDE but packages that KDE depends
>>> on.  Well, should those that are KDE go into the KDE file and the ones
>>> that are dependencies but not KDE go into a file of its own or what? 
>> You put them wherever you want! I put them in kde, because that's what
>> they are for. That way I know that those entries were required by KDE
>> without having to fill the single file with comments.
>>
>>
> 
> 
> Yea.  We just batting ideas around.  For me tho, it just turned into a
> nightmare.  If I needed to change something, which file is it in?  At
> one time I had a dozen or so files and digging through each one of them
> wastes time.  If I have just one file, I open the file and do a ctrl f
> and type in what I am looking for.  Of course, some of the script geeks
> prolly have a sneaky way of searching and finding out which file it is
> in but I'm not one of those, most days for sure. 
> 
> Anyway, all the diggin just got old for me.  You likely have a easy way
> of finding it whereas I don't.  ;-)

It's called grep

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] This nite's switch to "full multilib"

[Gevisz]

On Sun, 29 Mar 2015 19:53:18 +0200 "Stefan G. Weichinger" <lists@xunil.at> wrote:
> 
> I have to do that for 195 ebuilds here and really wonder if that is
> correct in the end ....

Have you tried to unmerge all the emulation packages before
updating the system, as advised by the news?

I did it before the full update.

As the result, my system updated/recompiled about 267 packages
(that lasted about 6 hours on my computer) but I had no need
to add any abi_x86_32 USE flags in my package.use, though
I do have wine installed.

Re: [gentoo-user] This nite's switch to "full multilib"

[Alan McKinnon]

On 29/03/2015 19:30, Mick wrote:
> On Sunday 29 Mar 2015 18:07:50 Alan McKinnon wrote:
>> On 29/03/2015 18:21, Mick wrote:
>>> On Sunday 29 Mar 2015 17:08:32 Yanestra wrote:
>>>> On 03/29/2015 05:03 PM, wabenbau@gmail.com wrote:
>>>>> "In most of the cases, Portage will be able to deliver correct
>>>>> suggestions for that when using the --autounmask feature.
>>>>
>>>> The first thing what happens here is that kde wants to upgrade because
>>>> qtchooser's mask miraculously becomes ignored. And qtchooser itself
>>>> doesn't install together with the libraries it pretends to control
>>>> because there masses of conflicts, no matter what combination (qt4, qt5)
>>>> I try.
>>>>
>>>> It has taken months of experimentation to get all the software to work
>>>> which I need. It was tricky, because in many places only particular
>>>> versions do.
>>>>
>>>> All that dissolves in a giant pile of rubbish...
>>>>
>>>> Regards,
>>>> Yanestra
>>>
>>> I've also ended up with qt blockers, that I do not seem capable to
>>> overcome yet.  KDE wants qt 4.8.5 installed which is blocking qt 4.8.6. 
>>> How did you go about overcoming this?
>>
>> I went through that exercise about a month ago, and I needed this:
>>
>> /etc/portage/package.use/abi_x86_32:
>>> =dev-qt/qtwebkit-4.8.6-r1:4 abi_x86_32
>>> =dev-qt/qtgui-4.8.6-r1:4 abi_x86_32
>>> =dev-qt/qtdbus-4.8.6-r1:4 abi_x86_32
>>> =dev-qt/qtscript-4.8.6-r1:4 abi_x86_32
>>> =dev-qt/qtcore-4.8.6-r1:4 abi_x86_32
>>> =dev-qt/qtxmlpatterns-4.8.6-r1:4 abi_x86_32
>>> =dev-qt/qt3support-4.8.6-r1 abi_x86_32
>>> =dev-qt/qtsql-4.8.6-r1:4 abi_x86_32
>>
>> Apparently I have some 32-bit app that uses Qt, and wine is also in the
>> mix. I imagine the number of possibilities and complications about this
>> can be huge and many folks will need to make their own unique tweaks to
>> package.use, and it'll take a while to shake out all the cruft in the tree
> 
> Thanks Alan, after keywording:
> 
> =dev-qt/qtopengl-4.8.6-r1 ~amd64
> =dev-qt/qtscript-4.8.6-r1 ~amd64
> =dev-qt/qtsql-4.8.6-r1 ~amd64
> =dev-qt/qtsvg-4.8.6-r1 ~amd64
> =dev-qt/qttest-4.8.6-r1 ~amd64
> =dev-qt/qttranslations-4.8.6-r1 ~amd64
> =dev-qt/qtwebkit-4.8.6-r1 ~amd64
> =dev-qt/qtxmlpatterns-4.8.6-r1 ~amd64
> 
> and adding abi_x86_32 on many packages that emerge asked me to, I am now able 
> to progress with 'emerge -a @preserved-rebuild'.
> 

Thanks Mick. I think Michael posted the correct cause up-thread:

"If you're on stable, you'll need to keyword qt-4.8.6 in its entirety.
You can't mix and match versions, and 4.8.6 is the only one that
supports multilib."

So you probably want to add all current Qt4 packages to the list.

We should probably start asking all posters with similar problems what
is the output of

grep -ir qt /etc/portage

and help them remove all cruft that's getting in the way of a clean upgrade




-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] This nite's switch to "full multilib"

[Peter Humphrey]

On Sunday 29 March 2015 20:12:45 Alan McKinnon wrote:

> ... I think Michael posted the correct cause up-thread:
> 
> "If you're on stable, you'll need to keyword qt-4.8.6 in its entirety.
> You can't mix and match versions, and 4.8.6 is the only one that
> supports multilib."

Something needs clarifying here. Exactly who will need to keyword qt-4.8.6?

> So you probably want to add all current Qt4 packages to the list.
> 
> We should probably start asking all posters with similar problems what
> is the output of
> 
> grep -ir qt /etc/portage
> 
> and help them remove all cruft that's getting in the way of a clean
> upgrade

Just to get you started, here's my list from a system that upgraded 
smoothly:

$ grep qt /etc/portage/package.use
app-text/poppler                cairo qt4
dev-qt/qtcore                   qt3support
dev-qt/qtdeclarative            qt3support webkit
dev-qt/qtgui                    qt3support
dev-qt/qtopengl                 qt3support
dev-qt/qtsql                    mysql qt3support
dev-qt/qtwebkit                 icu

(Package.use is the only place where qt occurs.)

-- 
Rgds
Peter.

[gentoo-user] Re: This nite's switch to "full multilib"

[James]

Peter Humphrey <peter <at> prh.myzen.co.uk> writes:


> On Sunday 29 March 2015 20:12:45 Alan McKinnon wrote:

> > grep -ir qt /etc/portage
grep qt /etc/portage/package.use | wc -l =11

dev-qt/qt-creator	android autotools cmake python 
dev-qt/qtgui		qt3support
>=dev-qt/qtsql-4.8.5 qt3support
>=dev-qt/qtcore-4.8.5-r1 qt3support
# required by dev-qt/qtcore-4.8.5-r1[qt3support]
>=dev-qt/qtgui-4.8.5-r1 qt3support
# required by dev-qt/qtopengl-4.8.5
>=dev-qt/qtgui-4.8.5-r2 -qt3support
# required by dev-qt/qt3support-4.8.5
>=dev-qt/qtgui-4.8.5-r2 qt3support
# required by dev-qt/qtwebkit-4.8.5[gstreamer]





# grep -ir qt /etc/portage | wc -l  =86

# eselect profile list
Available profile symlink targets:
  [1]   default/linux/amd64/13.0 *


So I am multilib? How/where do I tell, as one reader posted
that the profile is not where we designate if we are multilib
or not (news to me). I am open to edumacation on this aspect.


> and help them remove all cruft that's getting in the way of a clean upgrade

I just ran a 'depclean' a few days ago. Dozens of my java hacks (overlays)
and such got cleaned out and my apache-spark ebuild (hack) does not compile
anymore. No big deal, I get to spend another day learning all the neat
things I do not know about maven......

I Did not even know a cleanup was needed but 'eix-test-obsolete' 
broke me down and kicked me in the teeth. I've got a lot to clean up:

eix-test-obsolete | wc -l =209

emerge -uDNvp world | wc -l =111
emerge -uDNvp world : 
Total: 98 packages (2 upgrades, 2 new, 2 in new slots, 92 reinstalls, 3
uninstalls)


All I have done so far is run emerge --sync. I previously sync'd up on
28mar2015 before that. I do not run KDE, I use lxde + lots of java (hacks)
I refer to 'java(hacks)' because it is mostly a kludge of
old portage packages and overlays.


I have automask automated via make.conf.
EMERGE_DEFAULT_OPTS="--with-bdeps y --autounmask-write y"

 But  before I follow the  path of others:

cat package.use | wc -l   =314

package.use via automask is getting a bit out of hand, already.
Somehow, I do not feel good about the devs solution is to 
munge up something I have already been abusing. So, does
'eix-test-obsolete' have some automated option to clean up
package.use? I think I need to do this before applying
the latest (dev_inspired) kludge to my main workstation....?

Maybe I should BE the chicken that I am, and wait a few days
for others to flush this out a bit more? It's already been a
hell(o)Monday for me..............


On a brighter note, I do feel good that my instincts on kludging
up a gentoo system, seem to be tracking the devs, quite nicely....

Guidance, humor and spankings are all welcome.....


James

Re: [gentoo-user] Re: This nite's switch to "full multilib"

[Peter Humphrey]

On Monday 30 March 2015 22:23:21 James wrote:

> package.use via automask is getting a bit out of hand, already.
> Somehow, I do not feel good about the devs solution is to
> munge up something I have already been abusing. So, does
> 'eix-test-obsolete' have some automated option to clean up
> package.use? I think I need to do this before applying
> the latest (dev_inspired) kludge to my main workstation....?

Someone mentioned enalyze, which I hadn't met before. Maybe that will help.

-- 
Rgds
Peter.