pkgin should be able to rm named packages without dependencies about pkgin

[gdt]

What I mean is:

• assume foo and bar are both installed, and bar depends on foo
• I know foo is installed and would prefer to remove it, but don't want to do a recursive rm
• I type "pkgin rm foo"
• I get a prompt about removing bar, and really I would like to type "pkgin --non-interactive rm foo" and have either
  • foo is removed, or
  • an error that foo can't be removed because bar depends on it

except that I don't want --non-interactive but something else. Really I personally would want my behavior to be default and -r if rm should recurse, but I suspect that's a minority opinion.

Once I have my keep flags set, I find pkgin ar does what I want so this isn't so acute. But in general, pkgin is hard to use other than interactively by a human.

[jperkin]

Could you give me an example? I'm not entirely sure what you're asking. Thanks.

[jperkin]

Ok. This is definitely something I do not want pkgin to support, certainly the first behaviour, and absolutely never by default, as it should never knowingly create a broken system. Advanced users who know what they're doing can just use pkg_delete -f and ignore the warnings for that use-case.

I can maybe see some merit in showing if a package to be deleted has any dependents, and maybe if others feel strongly about this I could consider an optional argument to pkgin remove, but again given its advanced nature in knowingly leading to a broken system I'd argue the advanced user can just use pkg_info -qr around whatever tooling they are using instead.

[gdt]

I did not mean leading to a broken system at all. I completely agree that no broken states should ever result. I just mean 'pkgin rm foo' either can safely remove foo without recursing and does so, exiting 0, or cannot safely do so, prints an error, and exits 1.

I guess a more fundamental question might be: is it an error for pkgin to be called from a script, without a human to answer questions, or to be called like [complicated pipeline] | xargs pkgin rm? If that's out of scope, then the docs should say that, because otherwise a reasonable assumption is unix norms. I sort of feel like this is a GUI program only that happens to use the command line sometimes, but I'm not sure that's fair.

[jperkin]

It's reasonably fair. Given that pkgin is primarily a wrapper around pkg_install, it's certainly the case that it is tailored towards interactive use and providing the user options and features that are not supported by pkg_install. For any advanced usage such as pipelines I personally would lean towards using pkg_install (in this case | xargs pkg_delete should do what you want), as trying to make pkgin support many of the same features would just result in a lot of code duplication and even more confusion about which tool to use when.

That said there is some merit in having an option e.g. pkgin remove -o, that will only consider arguments that do not affect other packages. It would be useful for cases such as #42.

[gdt]

On one hand I am sympathetic to the "document that using it non-interactively is a bug", but pkgin also does a lot of cross-pkg dependency management that pkg_install cannot do. After this discussion I lean to:

• have an option that is pkgin-wide, a peer to -n, that means "do it if safe, otherwise error, and do not prompt"
• perhaps default that option to on if stdin is not a tty, or perhaps error out if stdin is not a tty and the option is not given

Right now it feels like one should be able to call it non-interactively, but it doesn't really work.

[jperkin]

Just to be clear that using it non-interactively is emphatically not a bug, the disagreement is only in the behaviour that should occur where the expectation perhaps differs from what regular users would expect. Both apt and yum behave the same way that pkgin does, and will remove all affected packages if you try to remove a dependency. My point was perhaps badly made, I just wanted to emphasise that if you are a user who wants alternative behaviour to the default then you may be better served by using the underlying tools rather than the front-end which tries to be more user friendly and behave in ways that users coming from other systems might expect.

pkgin is used by a number of provisioning / configuration management systems (ansible, salt, etc.) where it is always called non-interactively and we encourage its continued use in those tools.

[gdt]

I guess then my residual issue is that calling it with /dev/null stdin leads to it trying to read to answer questions and printing odd complaints.

So perhaps a way forward is that if stdin is not a tty, then 1) don't ask the question and 2) do what should be done for a script if that is safe. I don't see recursive rm as safe, but I do see "i asked to install foo, and foo and 3 deps are installed" as safe.

That leaves the behavior with a tty the same, and makes it more script friendly.

[gdt]

Or if -n is supposed to be used for this, then not giving -n can be an error if not tty. using pkgin in shell scripts without that has frequently led me to confusion.

[jperkin]

Yeh certainly if there are areas where stdin isn't working then we should fix those.

[gdt]

ok, will file new point bugs as I find it, and thanks for the polite discussion!