Hi,
bo0od <bo0od@riseup.net> writes:
> In particular, there are multiple
> profiles, and each of them could contain avahi or a reference to avahi.
That doesnt address the issue im talking about, why guix remove doesnt
recognize the package that number 1 , number 2 if the package will break
something important guix should say that after processing the command
guix remove x package then show warning message this x package is
dependency of xyz which might break your system would you like to
proceed? <- something like that.
This seems to be based on a misunderstanding about what "guix remove" is
intended to do. As Julien indicated, it is _only_ meant to remove the
given packages from the set of *explicitly-requested* packages installed
in your user profile. More precisely, it creates a _new_ user profile
that's the same as the previous one, but with some packages removed from
the set of explicitly-requested packages. It _never_ deletes anything.
You seem to want it to do something different than it was intended to
do, although I'm not precisely sure what that is. Do you want it to try
to purge all copies of the given package from /gnu/store? If so, that
might require deleting (or modifying) older system generations and older
user profiles, which would interfere with rollback functionality. Or
perhaps you want it to automatically update all user profiles, as well
as the system, to avoid depending on that package, directly or
indirectly? If so, there are a couple of problems with that: (1) on
multi-user systems (which is admittedly becoming an edge case) it would
violate the principle that each user should have control over their own
profiles, and (2) it would apparently involve automagically editing your
OS configuration file to remove any packages or services that depend
(directly or indirectly) on the specified packages.
From my perspective, it seems that you have expectations about how
package managers should work based on your experience with traditional
GNU/Linux distributions. Guix is based on a radically different
approach which takes some time to become acquainted with. Perhaps our
documentation needs to be improved to better manage user expectations.
It reminds me of how many developers responded when asked to switch to
Git from CVS or Subversion. Many developers found that transition
difficult, and considered it a flaw in Git that it failed to conform to
their expectations.
Nonetheless, I very much appreciate your feedback. I suspect that many
other people experimenting with Guix feel as you do, but that some of
them are simply walking away in silence. Thanks for making a
constructive effort to engage with us on these issues.
Regards,
Mark