Arch Linux

There is a rationale for --needed when installing packages, since you don't want to reinstall the ones you already have installed with the right versions, but you do want to make sure they are installed. This is useful for things like handling dependencies, or makepkg -i. There are many instances where you might want to assert that a package is or will be installed.

The rationale for removing packages you don't know you have installed, is a bit harder to see... when do you need to assert that a package is *not* installed? If it is about cleaning up unneeded packages, you can pipe the list from pacman -Qqdt or other, directly to pacman -R without having any not-installed packages to handle.

For example, imagine we want to make a script for substituting common utils of a particular desktop environment for others we find better.

The point is there is no warrant that the removed utils will be in any target system or in a future desktop environment setup.

Furthermore if the goal of stopping a process is to prevent further mistakes, this particular stop really isn't preventing any.

https://image.slidesharecdn.com/leansixsigmamistakeproofing-goleansixsigma-150320144606-conversion-gate01/95/lean-six-sigma-mistake-proofing-goleansixsigmacom-2-638.jpg?cb=1426864779

Sure it prevents mistakes. It prevents me typoing and attempting to pacman -Rns foopkg, but having it succeed without doing anything because I typoed it and accidentally did pacman -Rns foopg.

In the -S--needed case, there is a strong assertion that the package name was not typoed -- it is a package that really does exist, and it's more likely that having the package installed is the end goal than that I actually wanted to perform a reinstall OR that I actually wanted a second package that is spelled almost like one I have installed, and which I typoed.

When the input is provided by a human, it's better having a hard poka joke, so they can fix the error right away.

But when the input is machine made, there's no warranty that there would be a human operating the process. So the activity shall be resilient to failure, not crash, and provide a warning instead.

If the argument "--noconfirm" is used, the user is implicitly telling that we are in this second case.

Why is it better for pacman to ignore an invalid package than for the script to check if the package is valid before trying to remove it?

Input shall only be strict to the extend it prevents errors. Being lax in any other case eases composition, systemic resilience, and ease of use.

Why does catching incorrect package names not qualify as preventing an error?

Alberto, you cannot adequately describe a rationale for this, and you have since then engaged in divisive forum threads about running makepkg as root!

Ultimately, you submitted a thread in which you seem to have basically decided to quit our community?: https://bbs.archlinux.org/viewtopic.php?id=243545

I'm getting mixed messages about your intentions here.

And you've also been quite unconvincing about multiple changes you wish to see in pacman/makepkg. I... strongly encourage you to begin providing reasoned arguments.

So far you're just repeating your initial premise that "this should only prevent errors", but you've been quite vague on what that actually means in the here and now. Waxing vaguely philosophical about "easing composition" is not a productive discussion -- I have no idea what that is supposed to mean.

Please be direct about your desires and how this corresponds to the issue you have opened.

@Andrew

If the "--noconfirm" argument is used, we can asume that the list is entered by another program. That it's there because it worked for the developer for a particular system in a particular moment in time, but for the rest of situations the list will be non exhaustive.

The list is of potential candidates, but having some of those already not installed will equally result in the desired operation: them not being in the system.

More broadly:
- Expect the output of every operation to become the input to another, yet unknown, operation.
- Don't insist on that operation be handled by a human, except only if a human would be able to handle it.
- Hand handled operations shall crash as soon as possible, to encourage correction. Automated operations shall crash only as last resort.

@ Eli

If you understand this isn't about who's more right or not, we can address those issues in private on email.

I see no reason why automated operations should only crash as a "last resort". pacman has no way of knowing if the package provided simply isn't installed or if the name is incorrect. If the name is incorrect and the script requires that the package be removed to continue its work, all we've done is push the error down the line to potentially disastrous results because the state of the system no longer matches what the script thinks it is. What constitutes a significant error is heavily context dependent, and I'm still not seeing any real justification for universally declaring that trying to remove an invalid package isn't a significant error.

I could imagine adding an option to selectively enable this behavior. I'd be more inclined to add it to pacutils, though, which is specifically intended to be more script-friendly than pacman and is better suited to the example you gave because it can do the entire replacement in a single transaction.

If the "--noconfirm" argument is used, we can assume the package list was tested to work in a particular moment in time with the script. So if the package isn't found in the future, it can only be because it's not longer available on the running system.

Also I cannot think of a context where having a package not remove could have disastrous results. The worst result I can think of is some unused package left installed on the system.

In that case Pacman could simply complete the operation, warn about missing packages, and exit with a status different than success or failure to let know the served program there are some warnings.

The best program isn't the one which has more interesting functionalities, but the one more straightforward on getting the purpose (https://youtu.be/um1Kxewx-_s?t=96).

And, as you said, that depends on context (https://youtu.be/cXdwDrRBD7Q?t=538).

"If the "--noconfirm" argument is used, we can assume the package list was tested to work in a particular moment in time with the script. So if the package isn't found in the future, it can only be because it's not longer available on the running system." I am unwilling to make that assumption. The script could have been tested on a system that used different package names, the package could have been renamed, the list of packages may be built dynamically, etc.

"Also I cannot think of a context where having a package not remove could have disastrous results." Let's take your example of substituting a group of packages. You remove the original set, but one of the names is incorrect, so the package is not removed. You then try to install the new packages, but because the old package is still around there's a conflict and the installation fails. If any of the packages that were successfully removed were critical, you have now rendered your system unusable. Furthermore, because your script has no way of knowing which packages it actually removed, it has no way of reinstalling them after it encounters the error to undo the damage.

Please do not spam the bug tracker with irrelevant youtube videos.

Oh, they aren't irrelevant. In fact people is willing to pay to me for showing them videos like these. It's just that the ones around here aren't that people.

As specimen, answering your latest question:
https://youtu.be/pjvQFtlNQ-M
https://talks.golang.org/2014/gocon-tokyo.slide#25
https://en.wikipedia.org/wiki/Worse_is_better
https://fitnessfia.com/wp-content/uploads/2017/07/perfektionist-skala.jpg
http://www.utica.edu/student-blogs/wp-content/uploads/2014/05/The-Perfectionists-Guide-to-Results-Lo.jpg

> - Expect the output of every operation to become the input to another, yet unknown, operation.

I'm unsure where you're going with this argument.

pacman is not libalpm. libalpm does transactions, pacman provides an interactive UI over those transactions. pacman's output is not scriptable in the general case (-S -R and -U are not) although sometimes (-Sp, -Q, -T) it is.

-R is not one of those things whose output can be fed to an unknown operation. All you get is the human-readable output plus an exit code. The scriptable part is the *input*.

> - Don't insist on that operation be handled by a human, except only if a human would be able to handle it.

This philosophy is at odds with archlinux.org distribution policy that users shall read the output of all pacman transactions in order to receive e.g. post-upgrade messages or check that hooks completed successfully. In many cases these issues are time-sensitive. It's not feasible to do daily updates in an unattended fashion and only check the update logs every other month. It is true that pacman is not archlinux.org specific...

It seems wiser to let pacman *not* go ahead with such a transaction, but return an error for whatever high-level pacman wrapper is in use so that the user can modify their expectations and retry their guided script interaction.

> - Hand handled operations shall crash as soon as possible, to encourage correction. Automated operations shall crash only as last resort.

I agree with agregory that pacutils is a better fit for this, if it belongs anywhere.

> Oh, they aren't irrelevant. In fact people is willing to pay to me for showing them videos like these. It's just that the ones around here aren't that people.

Since we are not that people and won't pay you money to show us videos, can you please acknowledge that this is the wrong way to communicate with us? I for one am not even going to click your links -- I will wait for your technical arguments to appear as words submitted to this technical website, with optionally supporting links that lend weight to but do not replace your words.

Not a technical discussion, we simply disagree on the priorities. For both software design, and how to communicate.

You pursue to attain quality with control, I pursue to attain quality with as less control as posible. To make things work well by themselves, not having to think about details till expressed otherwise.

You want manual control, I want automation. Not as excluding manual operation, but as the default operation. So users only have to worry about the things they choose to.

More broadly I want to be able to start as many systems as possible, both human and not human, with as little cost of supervision from my side as possible. So I can continue creating more ad infinitum.

But lastly it's your choice, independently if I'm right or not. You make your software as you want to.