Notes on Yum Changes

Tue Sep 7 12:32:53 UTC 2004

On Tue, 2004-09-07 at 14:05 +0200, Leonard den Ottolander wrote:
> On Tue, 2004-09-07 at 09:21, Rui Miguel Seabra wrote:
> > What do you think of a security update that doesn't update because
> > there's a bug in an unrelated package?
> 
> Firstly the fact that it interferes makes it related. Secondly it was
> pointed out by more than one user that hiding details about conflicts
> from the user (by skipping such packages) is probably worse than
> erroring out with a message.

I never mentioned hiding, nor was that the intention.

> > How "potentially serious" a problem would that be?
> 
> The user should have noticed there's a problem from the warnings (s)he
> received. If (s)he can't deal with those (s)he shouldn't be using
> multiple repos in the first place.

What multiple repos? Why do you suppose there have to be multiple repos
for this to happen?

The latest problem of barfing due to obsolete packages happened recently
with xorg.

> > The job of a metapackager is making updating easier, not harder just as
> > hard as if it wasn't there.
> As pointed out the metapackager can not be expected to handle conflicts
> if no standard on which all the repositories (and users) agree is
> defined on how to do so.

There's nothing about solving conflicts. Just not letting a conflict on
some packages affect the other unrelated (ie, those that do not depend
on them).

> In case of your above example, how should yum know it needs to skip the
> package that holds the obsoletes, and not the package for which a
> security update is released?

Huh? You're not understanding:
   yum barfed because of obsolete packages.
   if there was an unrelated security package, it wouldn't be applied
because yum barfed.
   if, since there was a problem with some packages, it offered to
install the other unrelated ones, the problem would be minimized and
life would be made easier for the end user.

> > There would be a resemblance if I was saying to install even if it
> > screamed of a problem...
> 
> Well that is sort of what you suggest above. Install security update
> even though there is a conflict and skip the other package. I still
> don't see how that could solve a circular obsoletes by the way.

No. You're misreading. Read again. I'm talking about a problem on an
unrelated package preventing an update, because obsoletes is not on by
default.

Imagine there was a bug with mount (which is suid root).
An update for util-linux wouldn't be upgraded on one of the last update
batches because some xorg-x11 packages obsoleted others, halting the
process.

As you can see, there is no X here:
[rms at roque ~]$ rpm -q util-linux --requires
/bin/sh
/bin/sh
/etc/pam.d/system-auth
/sbin/install-info
config(util-linux) = 2.12a-6
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.3)
libc.so.6(GLIBC_2.3.3)
libcrypt.so.1
libcrypt.so.1(GLIBC_2.0)
libdl.so.2
libncurses.so.5
libpam.so.0
libpam_misc.so.0
libpopt.so.0
libtermcap.so.2
libutil.so.1
libutil.so.1(GLIBC_2.0)
libuuid.so.1
libz.so.1
pam >= 0.66-4
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1

> > Yum doesn't prompt. Barfs. You could be right if it did, but
> > _it_doesn't_.
> 
> Seth already pointed out developer time is limited. Would you be so kind
> to provide patches for more user friendly messages?

I'm not demaning it to be solved, I wondered why something wsn't the
default and I don't see any answer with a sensible reason. Just
"NOTABUG" or "WONTFIX".

All I read were excuses. I can understand limited time, not bad and
arrogant statements, like expecting a newbie to be able to solve yum
dependency problems.

> > > you write up the process for what has to occur and get EVERYONE to agree
> > > on it and I'll write the code.
> > In a very highlevel way, I already did, wouldn't you say so?
> 
> No. You might have indicated a problem that you perceive,

Not perceive. Exists. A newbie user is placed with a "difficult"
challenge unecessarily, and important packages may not be upgraded due
to certain bugs in unrelated packages.

And the excuse for not solving is not "limited time" (which I would
understand) but "WONTFIX" (not how the replies were written, but how
they "sounded" to my "ears").

>  but you have
> neither described a standard on how to handle it, nor have you got
> everyone to agree on your solution.

I don't need to describe in detail what's taught on classes about
finding paths on mazes without getting lost on loops, do I?
You mark where you have been, so that if you find it again, you know
you've been there.
You mark obsolete "paths" until you find one that's already registered
(a loop).

Anyway, I'm not complaining my self. I just think this is a bad thing
for newbie users. For me? It's just a minute (or so) more.

> Leonard "you may feel a slight sting, that's pride fuckin' wit ya. Fuck
> pride!" den Ottolander.

I only hope this is a random quote or else, it is a very innadequate
one, I think.

Rui
-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040907/6216db04/attachment.sig>