Re: [gentoo-dev] Things one could be upset about

[Róbert Čerňanský]

On Tue, 20 Jan 2015 11:08:19 +0300
Andrew Savchenko <bircoph@g.o> wrote:

> On Tue, 20 Jan 2015 07:46:32 +0100 Róbert Čerňanský wrote:
> > On Tue, 20 Jan 2015 00:14:29 +0300
> > Andrew Savchenko <bircoph@g.o> wrote:
> > > On Mon, 19 Jan 2015 21:44:25 +0100 Róbert Čerňanský wrote:
> > > > From my point of view it would do much help if portage resolves
> > > > USE dependencies automatically
[...]
> > > As the user the last thing I want is to have some USE flags
> > > changed without my permission
[...]
> > Is is of course perfectly fine to have that option disabled by
> > default.  But I am afraid that I do not quite understand yours and
> > Daniel's concerns.  If I paraphrase your statement with regards to
> > current dependency handling, it is as if you were saying: "I do not
> > want portage to install any package automatically by its own, I want
> > to install all the dependencies explicitly."
>
> The paraphrasing above is wrong. What I want to say is "I don't want
> portage to automagically change _functionality_ of my packages on
> its own, even in order to solve dependencies."
>
> > Why we allow portage to install dependencies and still have things
> > under control?  Well we have --pretend and --ask options and we can
> > see what would/will be done.  This would be the same with USE flags.
> > You would see in the --pretend output which flags would be changed.
>
> No this wouldn't be the same. USE flags are _not_ equal to package
> dependencies, sometimes they will not trigger dependency change at
> all. USE flags are about _functionality_, dependencies are about
> the _means_ to implement that functionality (as well as base
> functionality of a package).

I see your point about functionality.  There are USE flags that
_changes_ functionality (like threads) and there are others which _adds_
functionality (like for example speex adds possibility to play files in
that particular format in mplayer).  The former I consider similar to
package dependencies because they too can add functionality to the
system (for example if ruby is installed as dependency it adds
possibility to execute ruby scripts) same as those USE flags adds
functionality to an application.

However, even if portage wants me to change USE flag that will change
functionality, in 99% of time I end up adding to my package.use what it
wants, since my goal is to install some application or update my
applications.  So just reviewing the changes that portage wants to do
and hit Y.  And in those rare cases when I really do not want some flag
enabled or some package installed I hit N and tweak things.

> > To match the package dependency handling, there should be also an
> > option equivalent to --depclean.  It would revert the USE changes
> > which were done because of dependencies requirements if no longer
> > needed.
>
> This will dramatically increase complexity of dependencies metadata
> as well as of algorithms to handle it (and they are already slow),
> with no clear benefits therefore. No, thanks.

Are you talking about proposed new USE specific depclean option or
emerge in general?  If it is the new depclean command that would run
slow then I am quite sure it will still be faster than me or anyone else
going manually through package.use and for each and every USE flag there
trying to remove it, run emerge, see if it passes, if not, add it back.

If it is emerge in general that would be slower that it is still better
than run it, see it fail and telling you what USE to change, you making
the change, and run it again.

> > For example, lets have following packages:
> >
> > - libbar
> > - libfoo with IUSE=bar, which depends on: bar? ( libbar )
> > - foo, which depends on: libfoo[bar]
[...]
> > New behaviour with automatic USE dependencies resolution:
> >
> > emerge -av foo
> > [ebuild  N     ] libbar
> > [ebuild  N     ] libfoo +bar
> > [ebuild  N     ] foo
> >
> > Now, you can hit Y if you agree what portage wants to do or N and
> > not to install foo at all.
>
> And if I don't agree? What if for some reason I don't want to
> have libfoo[bar] on my system. What If preferred solution will
> be not to use libbar at all and to use libclue instread?

In this example, if you do not agree, you have no other option how to
install foo (with or without automatic USE deps).  Because foo depends
on libfoo[bar] unconditionally.

If however foo would depend either on libfoo[bar] or libclue then the
portage would do the same thing as today (I guess it would take the
first dependency as mandatory or the one which is already installed if
any.) In this case, yes, your preference might be libclue instead what
portage chooses.  But I see no difference in the way how user choose it
comparing to todays '|| ( libfoo libclue )' -like dependencies.

> World update on my systems usually involves about 2000 of packages.
> It's already hard to read emerge -DNuav output in order to check
> for new packages, dependencies, downgraded and removed packages.
> Automagick dependency change will make this even harder, much
> harder because it will involve multiple additional emerge runs in
> order to deal with issues properly. And each run takes about half
> an hour.

Hmm, mine is about 1700 and on my 10 years old AMD64 it also takes long
time.  But my impression is that when portage resolves USE deps
automatically it will actually decrease the number of emerge runs.
Only in those rare cases when I really do not want some dependency (USE
or package) installed on my system and I am prepared to sacrify some of
the current functionality to get rid of it I need to tweak and re-run
emerge.

Of course there are blockers, like you pointed out in your other mail
with sci-libs/hdf5 and USE flags "cxx threads mpi".  But blockers are
here even today.  And moreover I am not sure what would portage do
today in such case.  Tell you to enable cxx and mpi, you do it and it
will fail again?

> Yet again, Gentoo is all about choise. If someone wants that

I agree, but I must say I am quite stunned that there are strong voices
against it.  I somehow thought that edit the overgrowing package.use
file upon each emerge world annoys anyone the same as me.

How do you handling it?  How do you clean it?  eix-test-obsolete does
not catch unnecessary USE flags there.

Regards,
Robert


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