On Tue, 20 Jan 2015 11:08:19 +0300 Andrew Savchenko <birc...@gentoo.org> 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 <birc...@gentoo.org> 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: ope...@tightmail.com Jabber: h...@jabber.sk
