unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: bo0od <bo0od@riseup.net>
To: Mark H Weaver <mhw@netris.org>, Julien Lepiller <julien@lepiller.eu>
Cc: 47748@debbugs.gnu.org
Subject: bug#47748: Packages which cant be find/removed by guix remove
Date: Thu, 15 Apr 2021 09:26:20 +0000	[thread overview]
Message-ID: <ffa6c5ab-d4e9-1d96-2ee7-fdf8657abe8b@riseup.net> (raw)
In-Reply-To: <87czuwr9l5.fsf@netris.org>

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




  reply	other threads:[~2021-04-15 14:38 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-13 12:46 bug#47748: Packages which cant be find/removed by guix remove bo0od
2021-04-14  0:28 ` Julien Lepiller
2021-04-14  2:44   ` Mark H Weaver
2021-04-14 10:34     ` Julien Lepiller
2021-04-14 16:07       ` Mark H Weaver
2021-04-16 14:52         ` Mark H Weaver
2021-04-14 16:31   ` bo0od
2021-04-14 18:42     ` Mark H Weaver
2021-04-15  9:26       ` bo0od [this message]
2021-04-15 19:34         ` Mark H Weaver
2021-04-16  2:45           ` bo0od
2021-04-14 18:44     ` Maxime Devos
2021-04-15  9:37       ` bo0od
2021-04-15 18:04         ` Maxime Devos
2021-04-16  2:58           ` bo0od
2021-04-14 18:48     ` Julien Lepiller
2021-04-15 10:16       ` bo0od
2021-04-15 11:03         ` Julien Lepiller
2021-04-16  2:11           ` bo0od
2021-04-16  3:41             ` Leo Famulari
2021-04-16  4:37               ` bo0od
2021-04-16  7:23                 ` Leo Famulari

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ffa6c5ab-d4e9-1d96-2ee7-fdf8657abe8b@riseup.net \
    --to=bo0od@riseup.net \
    --cc=47748@debbugs.gnu.org \
    --cc=julien@lepiller.eu \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).