GNU bug report logs - #47748
Packages which cant be find/removed by guix remove

Previous Next

Package: guix;

Reported by: bo0od <bo0od <at> riseup.net>

Date: Tue, 13 Apr 2021 12:47:02 UTC

Severity: normal

Done: Andreas Enge <andreas <at> enge.fr>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: bo0od <bo0od <at> riseup.net>
To: Mark H Weaver <mhw <at> netris.org>, Julien Lepiller <julien <at> lepiller.eu>
Cc: 47748 <at> debbugs.gnu.org
Subject: bug#47748: Packages which cant be find/removed by guix remove
Date: Thu, 15 Apr 2021 09:26:20 +0000
> 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.

Isnt this the standard understanding of deleting a package whether in 
GNU/Linux or Windows or Mac? If user has the root rights he should be 
able to delete software x, otherwise software x just hanging there 
forever and to delete it someone needs a hell of steps to do that and if 
so then this is can have usability issues , and so as security issues. 
usability issues are clear like the example above which i want to delete 
x using package manager (Thats gnu/linux way of deleting packages if 
mistaken correct me) then it wont be deleted. For security issues if x 
package is outdated and/or got widely exploited security vulnerability 
it just wont be gone from the distro (least we can say easily) leading 
to permanent vulnerability in the OS.

> 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.

So you see for example wpa-supplicant is not essential package for an OS 
which doesnt use wifi, Yet in guix i cant just delete it using guix 
remove it or sudo guix remove it, I find this annoying to have something 
like this happening within my OS.

Check main distros like Debian or Fedora and i want to know where is 
that avahi or wpa-supplicant (god know how many more) cant be removed?

Btw even packages which might break the distro you can delete them if 
you have root rights using just the package manager with the same simple 
command.

> 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.

Sure anytime, Thanks to you 2 <f>

Mark H Weaver:
> Hi,
> 
> bo0od <bo0od <at> 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
> 




This bug report was last modified 17 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.