Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 458464 - sys-apps/portage-2.1.11.50: no way to JUST DAMN INSTALL a package
Summary: sys-apps/portage-2.1.11.50: no way to JUST DAMN INSTALL a package
Status: UNCONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Interface (emerge) (show other bugs)
Hardware: All Linux
: Normal major (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-20 14:25 UTC by Walter
Modified: 2013-10-02 10:24 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Walter 2013-02-20 14:25:15 UTC
Hi. This is a re-reporting of the bug https://bugs.gentoo.org/show_bug.cgi?id=294162 as the suggested 'autounmask-write' solution still fails.

Use case: JUST DAMN INSTALL a package. Portage knows what needs to be done, in what sequence, or can at least imagine a series of steps, it just won't do it and demands wasteful manual involvement. I *don't care* about the integrity of /etc/portage/whatever. I just want this package installed! It's the sole purpose of the system in question, which at this iteration of reporting is a dedicated LXC container.

Reproducible: Always

Steps to Reproduce:
1. Have package.
2. Desire reliable automated installation.
3. Somehow various blocking stuff occurs so that 'emerge =category/package-version' doesn't complete.
Actual Results:  
Automated install has failed.

Expected Results:  
Automated install completes if there is any way in hell for portage to make it happen, at all, by hook or by crook. That includes USE flags, conflicts, whatever.

It is extremely reasonable to want a "just make it happen" button.  Otherwise, automating anything with Gentoo becomes impossible to perform reliably without freezing the system at a given portage snapshot, thereby losing many of Gentoo's attractive features.
Comment 1 Zac Medico gentoo-dev 2013-02-20 15:55:32 UTC
(In reply to comment #0)
> Automated install completes if there is any way in hell for portage to make
> it happen, at all, by hook or by crook. That includes USE flags, conflicts,
> whatever.
>
> It is extremely reasonable to want a "just make it happen" button. 

So, it would be acceptable to ignore conflicts, leaving some dependencies unsatisfied? That seems like a recipe for an unreliable system with lots of build-time and run-time failures, even more unreliable than it may be now!

> Otherwise, automating anything with Gentoo becomes impossible to perform
> reliably without freezing the system at a given portage snapshot, thereby
> losing many of Gentoo's attractive features.

Automation is nice, but if it makes the system unreliable then end won't justify the means.
Comment 2 Walter 2013-02-21 00:20:48 UTC
Argh. OK so right now I want to install a package and I get something about disabling bindist on openssl. So I do that, then I get something about a conflict between gentoo-slot openssl and other ssl. Basically I can't get autounmask-write to give me the goods in a single execution.

Instead, I have to have all this manual back-and-forth.

Basically, if autounmask-write did what it said on the cover in a single execution that'd be fine.  (But more suitable for scripting if it supported autounmask-overwrite-with-prejudice and I didn't need to etc-update afterwards)

Current manual process:
 1. emerge blah
 2. problems? if no, go to 6
 3. emerge --autounmask-write blah
 4. etc-update --automode -5
 5. goto 1
 6. OK

Portage should have an option that does all of that.
Comment 3 Walter 2013-02-21 00:26:22 UTC
PS. Please try to think outside of the "portage has to keep functioning and changes cannot affect the future" idea, which it seems is the default approach to portage-related changes.

In this and other automated install use cases, portage might even be removed after installation. It's only there to facilitate reaching a known state in an automated fashion, after which it is not necessarily used again, ever.

As for "does the resulting system work?". Fear not, for that will be caught by testing, and any bugs will be shared with extreme prejudice :)
Comment 4 Walter 2013-02-21 00:32:00 UTC
Maybe the new option could be called 'kamikaze'
Comment 5 Walter 2013-02-21 04:04:32 UTC
I think that the current strategy of portage in this situation is somewhat in conflict with the Gentoo philosophy:

"If the tool forces the user to do things a particular way, then the tool is working against, rather than for, the user. We have all experienced situations where tools seem to be imposing their respective wills on us. This is backwards, and contrary to the Gentoo philosophy."
Comment 6 Zac Medico gentoo-dev 2013-02-26 19:21:03 UTC
*** Bug 459344 has been marked as a duplicate of this bug. ***
Comment 7 Walter 2013-03-02 02:09:29 UTC
Had to post this, as it made me think of this bug immediately.

http://news.ycombinator.com/item?id=5304936

Top comment: "Nothing in computing is worse than software that knows exactly what you want it to do, then gives some shitdick excuse as to why it's not going to do it in an effort to get you to jump through meaningless hoops."
Comment 8 Zac Medico gentoo-dev 2013-03-05 01:57:03 UTC
Dependency conflicts usually are not "meaningless hoops", but require the user to decide upon the specific ways that they want the conflicts resolved (there is often more than one way to resolve any given conflict).
Comment 9 Cedric Sodhi 2013-03-05 16:57:25 UTC
Although I have my share of disagreances with portage myself, I tend to agree with Zac.

Conflicts are not something that may "just be figured out" by portage how to solve. That requires User-Intervention.

The way this bug is phrased, it is invalid.

> It is extremely reasonable to want a "just make it happen" button.

Well, yes, it's equally reasonable to just want a "I want to be given a million dollars" button - it's just not gonna happen.

See Bug 258371 (or, for a short summary, its duplicate Bug 459344) for a valid requirement which does _not_ concern resolving conflicts, because that is not a well-defined requirement.
Comment 10 Walter 2013-03-06 01:42:50 UTC
If there are n paths, they should all be tried until one succeeds.
Comment 11 Cedric Sodhi 2013-03-06 08:33:55 UTC
That's just random and therefore not going to happen. If you want that kind of absurd functionality, you will have to write a wrapper. Something like "sys-apps/random-resolve" or "games-arcarde/portage" seems adequate.
Comment 12 Cedric Sodhi 2013-03-06 08:48:42 UTC
To clarify, I'm talking about conflicts with the *selected* configuration here (selected packages, selected USE-Flags anywhere from the profile through package.use). If there is a solution which includes installing the desired package which does *not* conflict with the selected configuration, I do of course agree with you - but that's not this bug's concern, as I understood.
Comment 13 Walter 2013-03-07 02:50:37 UTC
Why can the developers not see the utility in installing a package?

In the common situation that a single daemon or service is the purpose of a (virtual) machine, that's all the machine is for. Installation is not to be manually achieved, not to be manually dependency resolved, and the post-installation system is never to be maintained. *Simply installation, with no other concerns*.

Presently, portage cannot reliably fulfil this job despite knowing potential paths to proceed. This results in extremely bad user experience, because the constantly updating portage tree (Gentoo's great feature) can easily cause emerge to begin spouting any one of a great number of error conditions and failing.

Reliable automation of emerge thus becomes impossible. Quite clearly and simply, emerge is failing the user base, and has been lacking in this regard for years despite users bringing it to developer attention. Developers just reject the need. Why?

I suspect the real reason improvements are not made is that the codebase is too messed up and/or because the developers have not had the experience of attempting to manage Gentoo as a larger scale platform for automated software deployment.

This situation is sad and detracts from Gentoo's other great features as a platform.
Comment 14 Zac Medico gentoo-dev 2013-03-07 03:14:13 UTC
(In reply to comment #13)
> Presently, portage cannot reliably fulfil this job despite knowing potential
> paths to proceed. This results in extremely bad user experience, because the
> constantly updating portage tree (Gentoo's great feature) can easily cause
> emerge to begin spouting any one of a great number of error conditions and
> failing.

It's a constant work in progress. Much of the work that I have done on portage has been to improve the handling of various dependency solving problems. For example, I'm the one who added support for automatic solving of blockers (bug 79606). Before that, every single blocker required user intervention.

> Reliable automation of emerge thus becomes impossible. Quite clearly and
> simply, emerge is failing the user base, and has been lacking in this regard
> for years despite users bringing it to developer attention. Developers just
> reject the need. Why?

I can't speak for any other developers, but I don't rejected this need. Making portage more difficult to use is certainly not one of my goals.

> I suspect the real reason improvements are not made is that the codebase is
> too messed up and/or because the developers have not had the experience of
> attempting to manage Gentoo as a larger scale platform for automated
> software deployment.

As said, I have already done much work. However, it seems to be a constant work in progress, and there's always room for improvement.

> This situation is sad and detracts from Gentoo's other great features as a
> platform.

During the time that I have worked on portage, I have seen it make a lot of progress, but obviously there's still lots of room for improvement.
Comment 15 Walter 2013-03-15 02:57:10 UTC
Thanks a lot Zac. I don't mean to detract from the great work already done.

It just seems very strange to me that this has not been prioritized by developers given that it has been a problem for years now.

Thanks again for your ongoing work and I hope you will find the time to put some more effort in to this area.
Comment 16 Alexander Berntsen (RETIRED) gentoo-dev 2013-10-02 10:03:49 UTC
(In reply to Walter from comment #13)
> Why can the developers not see the utility in installing a package?
Why can the users not see the impossibleness in their suggestions? (Likely because they are not developers...)

What you are suggesting is not only extremely difficult to implement, but also something that would completely ruin a system. As a result it will be a seldom used feature which in turn means that the hardships involved with implementing this feature *fiercely* outweighs the benefits gained from its implementation.

So to sum up: this feature request is unreasonable. It's too hard to implement, and its use case is too rare (and pointless). That said, I would love to play games-arcade/portage, so patches welcome for the lulz. Meanwhile I think we should close this bug as WONTFIX or INVALID.
Comment 17 Walter 2013-10-02 10:24:15 UTC
> > Why can the developers not see the utility in installing a package?
> Why can the users not see the impossibleness in their suggestions? (Likely
> because they are not developers...)

Say what you like, but it's a common case for people not caring how to get from point A to point B and it's a common case that emerge *knows* how to do that, but refuses until basically useless hoops have been jumped through (unmask stuff, whatever).

Recently, it seems like to emerge anything at all you have to unmask stuff. It's getting to the point where it's not the exception, but rather it's the rule. This is a bit ridiculous.

> What you are suggesting is not only extremely difficult to implement, 

Let's start with the low hanging fruit - resolve multi-iteration unmasks in a single execution. That requires almost no new code and would be a massive help.

> but also something that would completely ruin a system.

I thought the Gentoo philosophy was more like "you can't stop a user from ruining their system, so get out of the way and let them do it". It specifically talks about not having people jump through pointless hoops. Sorry, but recently doing anything at all on Gentoo has required lots of essentially pointless hoops that developers probbaly consider highly important but most users probably just ignore and --autounmask-write + retry.

> As a result it will be a
> seldom used feature which in turn means that the hardships involved with
> implementing this feature *fiercely* outweighs the benefits gained from its
> implementation.

Right now I think I'd benefit every time I used emerge, just for the low-hanging fruit stuff. Feel free to leave more complex cases aside for now .. but even single iteration autounmask + execute would be a huge improvement.

> So to sum up: this feature request is unreasonable. 

When a project starts calling its long term, contributing users unreasonable, it starts losing users and contributions.

> It's too hard to
> implement, and its use case is too rare (and pointless). That said, I would
> love to play games-arcade/portage, so patches welcome for the lulz.
> Meanwhile I think we should close this bug as WONTFIX or INVALID.

It's always an exciting moment when a legitimate user query results in a tirade of highly blinkered development logic that ultimately concludes with poorly conceived technical humour interspersed with leetspeak. I mean... really? Is this the best Gentoo can do?