dnf even allows to uninstall RPM and systemd without warnings

[Pete Travis]

On Jun 23, 2014 4:55 PM, "Gerald B. Cox" <gbcox at bzb.us> wrote:
>
> First of all thank you for your reasoned response.  I simply disagree.
>
> I understand the fact about require bugs, and the tons of dependent
packages.  I've seen that also when I've tried to remove a package and
noticed it had a myriad of dependencies which would also be removed.
 However, when I see this, I simply respond "N" when I'm asked if it is OK
to proceed.  I also cringe when I see the "-y or --assumeyes" option
mentioned.  IMO that is just inviting disaster.  I'm surprised no one is
"demanding" that be removed.  It is dangerous.
>
> Regarding your kernel comment, I've been using Fedora since Redhat 6.2
and DNF since it first came out and I've never encountered this.  When I
update the kernel, it leaves the prior two on my system for rollback, so I
have no idea what you're talking about.  Yes, if you manually enter "dnf
remove kernel" it will come back with a list of all your installed kernels,
but again, you have to tell it "YES" to proceed.
>
> That said, my concern is that valuable developer time be devoted to
something which basically is to assist a small fraction of people who are
careless, can't be bothered to read or both.
>
>
> On Mon, Jun 23, 2014 at 12:26 PM, Przemek Klosowski <
przemek.klosowski at nist.gov> wrote:
>>
>> On 06/23/2014 11:51 AM, Gerald B. Cox wrote:
>>>
>>> This has got to be the silliest thing I've ever seen, but whatever.
You enter the command dnf remove dnf, and guess what?  It removes dnf.  You
enter the command dnf remove kernel, and guess what, it removes the
kernel.  What a concept, it does what you tell it to do.
>>
>> You present it as simple, but it's really trickier than you imply for
several reasons. We discussed several special cases, which you must have
missed so let me recall those for your benefit.
>>
>> First, the dependencies. Updates often involve chains of those, and I've
seen cases, e.g. caused by a require bugs, where
>> suddenly some system libraries end up scheduled for removal, dragging
along tons of dependent packages. Yes, 'yum update' will then ask for
confirmation, but it just isn't scalable---the equivalent of 'yum -y
update' must be reliable and recoverable even if things go wobbly.
>>
>> Second, kernel updates deleting all old kernels can delete the only
running kernel. You can't just say "don't ship broken kernel upgrades"
because it's a per-system problem---new ones work for most people but if
you are the unlucky person for whom it
>> doesn't work, you are in a bind:
>>
>>  - you must upgrade because otherwise you will never get a fix
>>  - you can't upgrade because it'll delete the only running kernel, and
the new one might not work
>>
>> It just makes a lot of sense to identify and protect a subset of
packages whose removal is potentially irreversible.
>>
>> --

So, there are actually two overlapping discussions here:
- upstream features
- distribution defaults for protected packages

We can talk about them at the same time *here* because the upstream
developers also happen to maintain the distribution package.  Nobody around
here likes to mandate other people do work, so we often say "this is
upstream's choice, we can't force them to do anything." That's how it
should be, and the way the dnf developers are reaching out for feedback is
an admirable exception to the rule.

(So please, don't pull the "upstream's discretion" card on people who
participate in an open, invited discussion)

The other side of the coin is distribution defaults.  Would Fedora use dnf
without the ability to define protected packages? Maybe, some seem to like
that, some say we have no other choice.  Would any other distro take on
such a casually destructive solution for their default?  Not so likely.

That said, it is clear that people have different opinions on the ideal
behavior of dnf, and future adopting distros will be the same.  The dnf
developers are doing a commendable job allowing for everyone to be
accommodated via the plugin structure.  The Fedora community is doing a
good job of communicating expectations, and upstream is listening. The dnf
threads lately are great examples of collaboration we could be proud of.

... Except for the unnecessarily tense disagreements between Fedora
voices.  That's not the point I started out to make, but damn does it ever
taint a good thing.

Anyway, Jan & company, I think it would be great if protected package
functionality were available for those who chose to use it, whether that's
Fesco, some other distro, or an admin out in the wild.  I know a few people
with root passwords to machines where I wouldn't ask them to even dust the
thing unless times were desperate...

--Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140623/061ea42d/attachment.html>