Issues with yum

[elison.niven]

Fedora is a feature rich Linux distribution containing the latest advancements
in open source software and I simply love Fedora.

Why does Fedora still decide to use yum? The package management system of
Fedora is still very primitive.

Here are my reasons why yum needs to go or needs *major* changes:

1) yum's interface (command line) is non-interactive. I always fail to
understand why it is
taking so long. "Setting up update process" stays for more than 1 minute at
times! (On a fairly fast PC with high speed internet connection). Atleast it
should show the user some progress as to what it is doing.

2) Quitting by CTRL-C isn't very easy. Is it?

3) On 64-bit machines, there *always* come up some issues with i686 packages
and protected multilib versions.

4) I have used Fedora for more than 5 years, I have faced "Unable to retreive
repository information repomd.xml" for like infinite times. Yes, the error
eventually gets resolved but it still comes again and again.

5) Need for autocomplete to work properly in package name argument of command
line when pressing TAB. It is painfully slow.

6) yum requires to download repository information separately for each user.

7) yum is strangely clubbed with package-cleanup,
yum-complete-transaction and I don't know what else.

These are my ramblings about yum. I know I could have filed a few of the above
as bugs and may be help to resolve them, But someone really needs to address
the bigger issue that is yum's design philosophy rather than just solve bugs in
yum.

Rather than providing me workarounds or solutions to make it work better,
Fedora needs to recognise that yum is really a huge pain to work with.

I will share one experience I had. Yesterday I did yum --enable-repo=updates
update on Fedora 16. It gave me an error stating protected multi-lib versions
of a dozen or so packages. Running package-cleanup --clean-dupes
removed 691 packages
leaving my system crippled. It removed the entire KDE and also network manager.
Now I unable to login to GNOME shell and not able to connect to any network. I
had to take backup using recovery mode before proceeding to reinstall.

I now need to reinstall my operating system. Reason : yum screwed up.
And these are the issues only regarding to the command line yum, The
GUI front-end to yum has more issues.

I do not intend to criticise any of the developers but only suggest
that yum *really* needs major changes.
Keep up the good work.

Thanks and Best Regards,
Elison

[elison.niven]

On Mon, Feb 27, 2012 at 12:12 PM, elison.niven at gmail.com

Post by elison.niven
Fedora is a feature rich Linux distribution containing the latest advancements
in open source software and I simply love Fedora.
Why does Fedora still decide to use yum? The package management system of
Fedora is still very primitive.
1) yum's interface (command line) is non-interactive. I always fail to
understand why it is
taking so long. "Setting up update process" stays for more than 1 minute at
times! (On a fairly fast PC with high speed internet connection). Atleast it
should show the user some progress as to what it is doing.
2) Quitting by CTRL-C isn't very easy. Is it?
3) On 64-bit machines, there *always* come up some issues with i686 packages
and protected multilib versions.
4) I have used Fedora for more than 5 years, I have faced "Unable to retreive
repository information repomd.xml" for like infinite times. Yes, the error
eventually gets resolved but it still comes again and again.
5) Need for autocomplete to work properly in package name argument of command
line when pressing TAB. It is painfully slow.
6) yum requires to download repository information separately for each user.
7) yum is strangely clubbed with package-cleanup,
yum-complete-transaction and I don't know what else.
These are my ramblings about yum. I know I could have filed a few of the above
as bugs and may be help to resolve them, But someone really needs to address
the bigger issue that is yum's design philosophy rather than just solve bugs in
yum.
Rather than providing me workarounds or solutions to make it work better,
Fedora needs to recognise that yum is really a huge pain to work with.
I will share one experience I had. Yesterday I did yum --enable-repo=updates
update on Fedora 16. It gave me an error stating protected multi-lib versions
of a dozen or so packages. Running package-cleanup --clean-dupes
removed 691 packages
leaving my system crippled. It removed the entire KDE and also network manager.
Now I unable to login to GNOME shell and not able to connect to any network. I
had to take backup using recovery mode before proceeding to reinstall.
I now need to reinstall my operating system. Reason : yum screwed up.
And these are the issues only regarding to the command line yum, The
GUI front-end to yum has more issues.
I do not intend to criticise any of the developers but only suggest
that yum *really* needs major changes.
Keep up the good work.
Thanks and Best Regards,
Elison

I forgot to add:
8) Yum cannot use an iso image as a repo without mounting it.
Yast in suse allows to directly use iso images as repos.

Thanks and Best Regards,
Elison

[Josh Boyer]

Post by elison.niven
8) Yum cannot use an iso image as a repo without mounting it.
Yast in suse allows to directly use iso images as repos.

You also forgot to add:

1) A proposed alternative
2) Patches to fix any of the issues you pointed out
3) Anything constructive at all in your ramblings.

Seriously, if you want yum replaced with something then you need to
show up with an
alternate proposal, how it would work, and people willing to do that
work. Without
those things, this is at best going to be ignored and at works just
turn into a huge "ME
TOO" thread that still winds up generating no change.

josh

[Frank Murphy]

On 27/02/12 12:04, Josh Boyer wrote:
<snippedy snip>

Post by Josh Boyer
1) A proposed alternative
2) Patches to fix any of the issues you pointed out
3) Anything constructive at all in your ramblings.

+ quite a lot.
"Never whine about the darkness, bring a torch"

[Przemek Klosowski]

I forgot to add: 8) Yum cannot use an iso image as a repo without
mounting it. Yast in suse allows to directly use iso images as
repos.

1) A proposed alternative 2) Patches to fix any of the issues you
pointed out 3) Anything constructive at all in your ramblings.
Seriously, if you want yum replaced with something then you need to
show up with an alternate proposal, how it would work, and people
willing to do that work. Without those things, this is at best going
to be ignored and at works just turn into a huge "ME TOO" thread that
still winds up generating no change.

I love yum. I have been using it on dozens of systems for probably
something like 100 system-years. Normally it's rock-solid, but when it
breaks it is something to behold. I had a couple of failures over the
years, and it just so happens that the system I write this on has a
major problem when out of the blue yum just collapsed in a heap:

https://bugzilla.redhat.com/show_bug.cgi?id=796382

Things can happen---I am OK with that. What worries me more is that yum
became a little baroque and non-transparent. There is a litany of
remedies for yum problems:

yum-complete-transaction
rpm --rebuilddb
yum clean all
package-cleanup (--problems/orphans/dupes/leaves)

While I have a general understanding of how yum works, and one or more
of the above always got me out of trouble in the past, this time they
didn't help and I don't know what to do next: which tools to use, what
to look for. Yum-utils has 23 separate executables and 18 manpages that
list a bewildering variety of options and subcommands---intimidating
complexity, which may also be reflected in increasing yum run times for
routine actions like queries and updates.

Of course it's not reasonable to throw yum out and start from scratch.
Given that it almost always works very well, perhaps it's even
reasonable to conclude that it should be left alone. Even if we agree
that something should be done, which of the following ideas are worth
pursuing:

* better diagnostic tools
* more visibility into the yum data and internals
* some refactoring
* documentation for debugging problems

Re-reading what I wrote, I realize that it's not very constructive, as I
don't know what is the right thing to do to improve yum, much less how
to do it. I just want to raise the issues for discussion.

[elison.niven]

Post by Josh Boyer

Post by elison.niven
8) Yum cannot use an iso image as a repo without mounting it.
Yast in suse allows to directly use iso images as repos.

1) A proposed alternative

I am more than happy to propose alternatives.
Alternative 1 : Use a totally different package management system : apt-get
It is mature enough. I know this is going to be rejected totally even
without consideration.

Alternative 2 :
Make the following changes to yum to make yum better:
1) yum should maintain status of installed packages locally. And it
should not need to fetch repository information when user tries
yum info <installed-package>
Reason to have this feature : It seems logical to have information
about an installed package locally.

2) yum is currently downloading repository information separately for each user.
It can use the same downloaded repository information for all users.
For example : root did yum install <some-package> followed by
Non root user did : yum info <same-package>.
yum will currently fetch repo information again for the non root user.
Reason to have this feature : Save time, bandwidth.

3) Show progress in "Setting up update process" or "Setting up install process".
At present, users cannot know that is it working or sleeping.
Reason to have this feature : Better user experience

4) Quit on single CTRL-C. Users expect an application to quit on
pressing CTRL-C.
Reason to have this feature : Better user experience

5) Allow to use iso image as a repo.
baseurl=file:///path/to/iso rather than baseurl=file:///path/to/mounted/iso
Reason to have this feature : Small feature but good to have.

Post by Josh Boyer
2) Patches to fix any of the issues you pointed out

I am not a yum developer at present nor am acquainted with the source.

Post by Josh Boyer
3) Anything constructive at all in your ramblings.

Does the above count now as constructive?

Post by Josh Boyer
Seriously, if you want yum replaced with something then you need to
show up with an
alternate proposal, how it would work, and people willing to do that
work. Without
those things, this is at best going to be ignored and at works just
turn into a huge "ME
TOO" thread that still winds up generating no change.

Your comments on the above proposals?

Best Regards,
Elison

[Frank Murphy]

On 27/02/12 13:52, elison.niven at gmail.com wrote:
<snipped>

Post by elison.niven
1) yum should maintain status of installed packages locally. And it
should not need to fetch repository information when user tries
yum info<installed-package>
Reason to have this feature : It seems logical to have information
about an installed package locally.

try:
yumdb --help

Post by elison.niven
2) yum is currently downloading repository information separately for each user.
It can use the same downloaded repository information for all users.
For example : root did yum install<some-package> followed by
Non root user did : yum info<same-package>.
yum will currently fetch repo information again for the non root user.
Reason to have this feature : Save time, bandwidth.

As above.

Post by elison.niven
3) Show progress in "Setting up update process" or "Setting up install process".
At present, users cannot know that is it working or sleeping.
Reason to have this feature : Better user experience

yum --verbose

Post by elison.niven
4) Quit on single CTRL-C. Users expect an application to quit on
pressing CTRL-C.
Reason to have this feature : Better user experience

never used ctrl-c, normally use "killall yum"
if required.

[Bruno Wolff III]

On Mon, Feb 27, 2012 at 14:00:51 +0000,

Post by Frank Murphy

Post by elison.niven
4) Quit on single CTRL-C. Users expect an application to quit on
pressing CTRL-C.
Reason to have this feature : Better user experience

never used ctrl-c, normally use "killall yum"
if required.

Control C works, but it needs to reach a break point. And once you start
actually doing a transaction you don't normally want control C to work
since it will leave your system in a state where manual cleanup is likely
required.

[John Reiser]

Post by Bruno Wolff III
On Mon, Feb 27, 2012 at 14:00:51 +0000,

Post by Frank Murphy

Post by elison.niven
4) Quit on single CTRL-C. Users expect an application to quit on
pressing CTRL-C.
Reason to have this feature : Better user experience

never used ctrl-c, normally use "killall yum"
if required.

Control C works, but it needs to reach a break point. And once you start
actually doing a transaction you don't normally want control C to work
since it will leave your system in a state where manual cleanup is likely
required.

That behavior (no response to ^C [SIGINT] within 5 seconds) is a bug.
It's a _transaction_, right? So either it completes successfully,
or fails with no apparent lasting effects (except log files, delay, etc.)
So yum should: respond immediately on stderr, abort the transaction
(roll back everything to the state before the transaction began),
and terminate with failure status. Because the original request
is for a transaction, then yum *must* be able to abort and rollback
anyway, to recover from I/O errors [and such errors _do_ happen.]
So, act as if ^C [SIGINT] is an I/O error.

--

[Bruno Wolff III]

On Mon, Feb 27, 2012 at 08:00:56 -0800,

Post by John Reiser
That behavior (no response to ^C [SIGINT] within 5 seconds) is a bug.
It's a _transaction_, right? So either it completes successfully,
or fails with no apparent lasting effects (except log files, delay, etc.)
So yum should: respond immediately on stderr, abort the transaction
(roll back everything to the state before the transaction began),
and terminate with failure status. Because the original request
is for a transaction, then yum *must* be able to abort and rollback
anyway, to recover from I/O errors [and such errors _do_ happen.]
So, act as if ^C [SIGINT] is an I/O error.

I don't believe yum has a way to roll back transactions reliably.

[Chris Murphy]

Post by Bruno Wolff III
I don't believe yum has a way to roll back transactions reliably.

http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs


Chris Murphy

[Bruno Wolff III]

On Mon, Feb 27, 2012 at 11:24:55 -0700,

Post by Chris Murphy

Post by Bruno Wolff III
I don't believe yum has a way to roll back transactions reliably.

http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs

Yeah being able to rollback file systems will help in some cases. It
isn't a complete answer for the case where you are using the machine
for other things at the time you are doing the updates, since you amy
want to rollback the updates without rolling back other changes (logfiles
newly delivered email messages and the like).

[drago01]

Post by Bruno Wolff III
On Mon, Feb 27, 2012 at 11:24:55 -0700,

Post by Chris Murphy

Post by Bruno Wolff III
I don't believe yum has a way to roll back transactions reliably.

http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs

Yeah being able to rollback file systems will help in some cases. It
isn't a complete answer for the case where you are using the machine
for other things at the time you are doing the updates, since you amy
want to rollback the updates without rolling back other changes (logfiles
newly delivered email messages and the like).

This fixable by taking the system "down" during the update (close all
apps and services) similar like what windows and os x do.

[Chris Murphy]

Post by drago01
This fixable by taking the system "down" during the update (close all
apps and services) similar like what windows and os x do.

At least on OS X this behavior depends on what's being updated. Most things are updated in place.

Chris Murphy

[Chris Murphy]

Post by Bruno Wolff III
On Mon, Feb 27, 2012 at 11:24:55 -0700,

Post by Chris Murphy
http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs

Yeah being able to rollback file systems will help in some cases. It
isn't a complete answer for the case where you are using the machine
for other things at the time you are doing the updates, since you amy
want to rollback the updates without rolling back other changes (logfiles
newly delivered email messages and the like).

It's a very broad rollback implementation. I think an eventual goal for the yum plugin, once btrfs is stable, is to make it more flexible. Maybe where /home is exempt from rollback.

Chris Murphy

[James Antill]

Post by Chris Murphy

Post by Bruno Wolff III
On Mon, Feb 27, 2012 at 11:24:55 -0700,

Post by Chris Murphy
http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs

Yeah being able to rollback file systems will help in some cases. It
isn't a complete answer for the case where you are using the machine
for other things at the time you are doing the updates, since you amy
want to rollback the updates without rolling back other changes (logfiles
newly delivered email messages and the like).

It's a very broad rollback implementation. I think an eventual goal for the yum plugin, once btrfs is stable, is to make it more flexible. Maybe where /home is exempt from rollback.

It's already usable with LVM and BtrFS, and you can exclude arbitrary
mount points.
However creating mount points in a way that makes it only "rollback"
those things you want is ... non-trivial.

[Chris Murphy]

Post by James Antill

Post by Chris Murphy
It's a very broad rollback implementation. I think an eventual goal for the yum plugin, once btrfs is stable, is to make it more flexible. Maybe where /home is exempt from rollback.

It's already usable with LVM and BtrFS, and you can exclude arbitrary
mount points.
However creating mount points in a way that makes it only "rollback"
those things you want is ... non-trivial.

Pretty sure it works without a dependency on LVM, rather uses btrfs snapshots.


Chris Murphy

[Adam Williamson]

Post by Chris Murphy

Post by Bruno Wolff III
I don't believe yum has a way to roll back transactions reliably.

http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs

Yeah...you might want to remember the context of the conversation.

I don't think you're *seriously* suggesting that hitting ctrl-c while
using yum should result in a btrfs snapshot restoration, are you?

[Chris Murphy]

Post by Adam Williamson

Post by Chris Murphy

Post by Bruno Wolff III
I don't believe yum has a way to roll back transactions reliably.

http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs

Yeah...you might want to remember the context of the conversation.
I don't think you're *seriously* suggesting that hitting ctrl-c while
using yum should result in a btrfs snapshot restoration, are you?

I'm agreeing with the assertion I quoted, but pointing out there is an option to gain rollback functionality. That's all.

I've never used control-c during a yum update. Too me, that seems like "Oh hell, I didn't mean to throw that cup of habaneros in my blueberry smoothie! Control-c?!" Even if they haven't been blended in yet, the smoothie is destroyed.

So no, I was not suggesting automatic rollback. However...

What's the expectation of a user hitting control-c in the middle of a yum update anyway? My first inclination is it makes zero sense, like habaneros in a smoothie. But if control-c means "stop here" as in "don't push the frappe button!" is that really as useful as "go back to start" as in "magically remove the habaneros?"

I'd pick a return to a known stable state, rather than being dropped in who knows what, where I'm probably going to have to install yum-utils and run yum-complete-transaction and who knows what. It'd probably work, that's what it's there for. Like picking each habanero and seed out of a blender with a fork?

Magic sounds better.


Chris Murphy

[elison.niven]

Post by Chris Murphy
What's the expectation of a user hitting control-c in the middle of a yum update anyway? My first inclination is it makes zero sense, like habaneros in a smoothie.

As stated earlier, the expectation is that when yum is still setting
up update process or downloading repo information, it will stop that
and quit.
Only when yum reaches "starting transaction test" or "running
transaction", it should restrict ctrl-c.

Best Regards,
Elison

[Chris Murphy]

Post by elison.niven

Post by Chris Murphy
What's the expectation of a user hitting control-c in the middle of a yum update anyway? My first inclination is it makes zero sense, like habaneros in a smoothie.

As stated earlier, the expectation is that when yum is still setting
up update process or downloading repo information, it will stop that
and quit.
Only when yum reaches "starting transaction test" or "running
transaction", it should restrict ctrl-c.

*shrug* OK I'm not going to deny you a feature. I still don't understand why it would be started in the first place if you didn't intend to finish it. But then, I never use -y either so I kinda know what I'm getting into before I confirm with "Y" that I do want to proceed with the update.


Chris Murphy

[John Reiser]

Post by Chris Murphy
*shrug* OK I'm not going to deny you a feature. I still don't understand
why it would be started in the first place if you didn't intend to finish it.

The Fedora mirror system doesn't always behave nicely
(timeouts, bad sync, slow transfer rate, ...)
I find that SIGINT is appropriate about once per week
just for downloads.

--

[Chris Murphy]

Post by John Reiser

Post by Chris Murphy
*shrug* OK I'm not going to deny you a feature. I still don't understand
why it would be started in the first place if you didn't intend to finish it.

The Fedora mirror system doesn't always behave nicely
(timeouts, bad sync, slow transfer rate, ...)
I find that SIGINT is appropriate about once per week
just for downloads.

Well I sure love eating crow. I have in fact hit control-c in the case where a slow mirror (like, dial-up modem slow) was even delaying the database update. 10 minutes later, still no idea if there were any applicable updates available. But control-c during that initial database updating for me has always been instant kill and drop to a prompt. Retrying, nothing is inconsistent, and I'm connected to a much faster mirror 100% of the time. So at least that instance of control-c appears to work.

Chris Murphy

[Panu Matilainen]

Post by John Reiser

Post by Bruno Wolff III
On Mon, Feb 27, 2012 at 14:00:51 +0000,

Post by Frank Murphy

Post by elison.niven
4) Quit on single CTRL-C. Users expect an application to quit on
pressing CTRL-C.
Reason to have this feature : Better user experience

never used ctrl-c, normally use "killall yum"
if required.

Control C works, but it needs to reach a break point. And once you start
actually doing a transaction you don't normally want control C to work
since it will leave your system in a state where manual cleanup is likely
required.

That behavior (no response to ^C [SIGINT] within 5 seconds) is a bug.
It's a _transaction_, right? So either it completes successfully,
or fails with no apparent lasting effects (except log files, delay, etc.)
So yum should: respond immediately on stderr, abort the transaction
(roll back everything to the state before the transaction began),
and terminate with failure status. Because the original request
is for a transaction, then yum *must* be able to abort and rollback
anyway, to recover from I/O errors [and such errors _do_ happen.]
So, act as if ^C [SIGINT] is an I/O error.

Rpm's so-called transactions aren't ACID by any stretch of imagination,
it's just a rather common misunderstanding to expect them to be.

- Panu -

[drago01]

On Mon, Feb 27, 2012 at 5:11 PM, Panu Matilainen

Rpm's so-called transactions aren't ACID by any stretch of imagination, it's
just a rather common misunderstanding to expect them to be.

They should be though (yeah I know way easier said then done).

[elison.niven]

I got many replies to my mail that answer many of my questions. Thanks to all.

Post by James Antill
Setting up Upgrade Process
Resolving Dependencies
...is this when you are doing a full "yum upgrade" or upgrading a
specific package too? How long is the delay?

I get the delay in doing a full "yum upgrade". Even when not
specifying --verbose, a percentage status similar to downloading
repodata can be used for "Setting up Upgrade/Install Process".

Post by James Antill
Control C works, but it needs to reach a break point. And once you start
actually doing a transaction you don't normally want control C to work
since it will leave your system in a state where manual cleanup is likely
required.
Do you really want the option to ^c in the middle of an update ?
Allowing the user to end-up with a half-updated system ?

IMHO, Using ctrl-c to quit should work instantaneously when yum is
still fetching repodata or downloading packages.

Post by James Antill
yum -C info <installed-package>
-C, --cacheonly run entirely from system cache, don't update
cache

If there is a way for yum to know that the package is installed by
looking up its name, it can eliminate the need for even specifying -C
here.

Post by James Antill
Kind of, we used to have non-root users use root's cache ... but that
caused lots of annoying problems.
I "have a plan" for Fedora 18, that should make things better. We'll
see.

Looks promising.

Best Regards,
Elison

[John Reiser]

Rpm's so-called transactions aren't ACID by any stretch of imagination, it's just a rather common misunderstanding to expect them to be.

OK, so both rpm and yum could do better: at the first mention of 'transaction',
then the documentation (manual page, ...) should specify "not ACID".
There is a database involved, and the word 'transaction' had a decade
of precedence in the database world before rpm was written.

Because rpm does not support ACID transactions, then yum should act
to minimize the adverse impact. Do not process the packages in
alphabetical order; instead sort the packages topologically: the
ones with no remaining dependencies go first, etc. Then responding
immediately to ^C [SIGINT] can leave at most one package in an
inconsistent state (assuming no circular dependencies.)
Or, it might be reasonable to finish processing that one package
before not starting the rest of the work.

Additionally, sorting each topological tier by descending size
tends to minimize the number of packages changed before any SIGINT,
so this is an inexpensive way give the interactive user more control.
However, sorting by ascending size tends to enable earlier detection
of systematic problems across packages. On average for a DVD, sorting
by size (and processing in the same direction) is significantly better
than random by size because the linear caching of most drives (2MB typical)
becomes much more effective on average for adjacent small files
if not all are selected.

--

[Emmanuel Seyman]

Post by John Reiser
OK, so both rpm and yum could do better: at the first mention of 'transaction',
then the documentation (manual page, ...) should specify "not ACID".

It would help if you filed a bug (preferably with a patch attached).

Post by John Reiser
There is a database involved, and the word 'transaction' had a decade
of precedence in the database world before rpm was written.

a) Databases have been around since the late-60s and rpm was written
in the early-90s.

b) I just did a quick poll around my office and the consensus is that
'transaction' does not imply 'ACID'.

Emmanuel

[Sandro Mani]

Post by Bruno Wolff III
On Mon, Feb 27, 2012 at 14:00:51 +0000,

Post by Frank Murphy

Post by elison.niven
4) Quit on single CTRL-C. Users expect an application to quit on
pressing CTRL-C.
Reason to have this feature : Better user experience

never used ctrl-c, normally use "killall yum"
if required.

Control C works, but it needs to reach a break point. And once you start
actually doing a transaction you don't normally want control C to work
since it will leave your system in a state where manual cleanup is likely
required.

One scenario which I often hit is forgetting to change the proxy
settings in yum.conf and then trying to update. Yum will clearly fail to
download repodata, but it will keep trying for all mirrors it knows.
Pressing ctrl+c there almost never works since yum only reacts to the
signal when it is sent exactely in the instant between when it gave up
downloading from one mirror due to timeout and beginning attempting to
download from the next.

[Genes MailLists]

On 02/27/2012 11:44 AM, Sandro Mani wrote:
will leave your system in a state where manual cleanup is likely

Post by Sandro Mani

Post by Frank Murphy
required.

One scenario which I often hit is forgetting to change the proxy
settings in yum.conf and then trying to update. Yum will clearly fail to
download repodata, but it will keep trying for all mirrors it knows.
Pressing ctrl+c there almost never works since yum only reacts to the
signal when it is sent exactely in the instant between when it gave up
downloading from one mirror due to timeout and beginning attempting to
download from the next.

Control-Z
bg
kill -9 %1

[Richard W.M. Jones]

Post by Bruno Wolff III
will leave your system in a state where manual cleanup is likely

Post by Sandro Mani

Post by Frank Murphy
required.

One scenario which I often hit is forgetting to change the proxy
settings in yum.conf and then trying to update. Yum will clearly fail to
download repodata, but it will keep trying for all mirrors it knows.
Pressing ctrl+c there almost never works since yum only reacts to the
signal when it is sent exactely in the instant between when it gave up
downloading from one mirror due to timeout and beginning attempting to
download from the next.

Control-Z
bg
kill -9 %1

That's what I frequently have to do. It *is* a bug in yum (and a very
very long-standing one at that):

https://encrypted.google.com/search?q=yum+ctrl+c
("About 137,000 results")

https://bugzilla.redhat.com/show_bug.cgi?id=519233
(open since 2009-08-25, and that is a regression on an earlier
bug that was opened in 2004)

And yes, I know I haven't submitted the patch yet.

Rich.

[James Antill]

Post by Richard W.M. Jones

Post by Bruno Wolff III
will leave your system in a state where manual cleanup is likely

Post by Sandro Mani

Post by Frank Murphy
required.

One scenario which I often hit is forgetting to change the proxy
settings in yum.conf and then trying to update. Yum will clearly fail to
download repodata, but it will keep trying for all mirrors it knows.
Pressing ctrl+c there almost never works since yum only reacts to the
signal when it is sent exactely in the instant between when it gave up
downloading from one mirror due to timeout and beginning attempting to
download from the next.

Control-Z
bg
kill -9 %1

That's what I frequently have to do. It *is* a bug in yum (and a very

Yeh, much like Fedora repodata is a yum bug.

There are at least 3 classes of bugs here:

1. rpm overrides C-c handling when you do various rpm operations, so
sometimes what look like "simple" changes mean C-c stops working for
parts of yum.

2. DNS handing in Glibc eats C-c, so various network related things
sometimes mean you have a non-C-c working yum (just like "ping blah"
C-c). AFAIK the only fixes are "don't ever call anything in proc. that
can do a glibc DNS lookup" or "add threads".

3. pycurl/curl/nss also eat C-c ... at least sometimes, and maybe only
when using rpm as well.

...before #3 we generally did the debugging and fixed things as best we
could, and there were a few yum's that people could use where C-c worked
really well (IIRC the latest el5 one was one).
But after #3 we had a lot of other problems in the same vein, so we
mostly gave up and are waiting for the downloads to not be in proc.
anymore. At which point it should mostly go away (hopefully we can get
rid of #2 as well ... so just need to be really careful about #1
problems).

[Richard W.M. Jones]

Post by James Antill
1. rpm overrides C-c handling when you do various rpm operations, so
sometimes what look like "simple" changes mean C-c stops working for
parts of yum.
2. DNS handing in Glibc eats C-c, so various network related things
sometimes mean you have a non-C-c working yum (just like "ping blah"
C-c). AFAIK the only fixes are "don't ever call anything in proc. that
can do a glibc DNS lookup" or "add threads".
3. pycurl/curl/nss also eat C-c ... at least sometimes, and maybe only
when using rpm as well.
...before #3 we generally did the debugging and fixed things as best we
could, and there were a few yum's that people could use where C-c worked
really well (IIRC the latest el5 one was one).
But after #3 we had a lot of other problems in the same vein, so we
mostly gave up and are waiting for the downloads to not be in proc.
anymore. At which point it should mostly go away (hopefully we can get
rid of #2 as well ... so just need to be really careful about #1
problems).

How much of this is to do with %post scripts?

IMHO we should reduce and remove the use of scripts as far as possible
over the whole of Fedora. RPM upstream too, but that may be harder.

We should replace %post scripts with more intelligence in RPM, so it
can, for example, create (and _delete_) user accounts on demand, or
run ldconfig when required.

Rich.

[James Antill]

Post by Richard W.M. Jones
How much of this is to do with %post scripts?

Not much, in that scripts run in a separate process. Everything, in
that while in the middle of a transaction rpm is in control of
everything and thus. anything above rpm can't catch C-c.

Post by Richard W.M. Jones
IMHO we should reduce and remove the use of scripts as far as possible
over the whole of Fedora. RPM upstream too, but that may be harder.
We should replace %post scripts with more intelligence in RPM, so it
can, for example, create (and _delete_) user accounts on demand, or
run ldconfig when required.

rpm upstream agrees:

http://lists.rpm.org/pipermail/rpm-maint/2010-June/002812.html
http://www.rpm.org/wiki/Releases/4.9.0#Collections

...any help would be appreciated, I'm sure.

[Jarosław Górny]

Post by Bruno Wolff III
On Mon, Feb 27, 2012 at 14:00:51 +0000,

Post by Frank Murphy

Post by elison.niven
4) Quit on single CTRL-C. Users expect an application to quit on
pressing CTRL-C.
Reason to have this feature : Better user experience

never used ctrl-c, normally use "killall yum"
if required.

Control C works, but it needs to reach a break point. And once you start
actually doing a transaction you don't normally want control C to work
since it will leave your system in a state where manual cleanup is likely
required.

Generally I agree, but with one exception. It should be allowed to hit ^C during preparation phases (metadata fetch, dependency processing, even package download), *before* any software get changed (also: rpmdb changes).

Example: I have proxy at work, no proxy at home. If I forget to change proxy settings, and run "yum check-update", it's very annoying it can't be stopped. And I think we all agree that breaking while "yum check-update" is not harmful.

regards,

[Sérgio Basto]

Post by Frank Murphy

Post by elison.niven
4) Quit on single CTRL-C. Users expect an application to quit on
pressing CTRL-C.
Reason to have this feature : Better user experience

never used ctrl-c, normally use "killall yum"
if required.

Ctrl-Z and
kill %1
normally do a better job.

[Jesse Keating]

Post by Sérgio Basto
Ctrl-Z and
kill %1
normally do a better job.

Providing a different method of reaching the same goal is missing the point.

[James Antill]

Post by Jarosław Górny

Post by Bruno Wolff III
On Mon, Feb 27, 2012 at 14:00:51 +0000,

Post by Frank Murphy

Post by elison.niven
4) Quit on single CTRL-C. Users expect an application to quit on
pressing CTRL-C.
Reason to have this feature : Better user experience

never used ctrl-c, normally use "killall yum"
if required.

Control C works, but it needs to reach a break point. And once you start
actually doing a transaction you don't normally want control C to work
since it will leave your system in a state where manual cleanup is likely
required.

Generally I agree, but with one exception. It should be allowed to hit ^C during preparation phases (metadata fetch, dependency processing, even package download), *before* any software get changed (also: rpmdb changes).

We agree ... see my message posted "27 Feb 2012 16:08:53 -0500" about
what is happening here, and how it should get fixed again "soon".

[Pierre-Yves Chibon]

Post by elison.niven
1) yum should maintain status of installed packages locally. And it
should not need to fetch repository information when user tries
yum info <installed-package>
Reason to have this feature : It seems logical to have information
about an installed package locally.

yum -C info <installed-package>
from --help:
-C, --cacheonly run entirely from system cache, don't update
cache

Post by elison.niven
2) yum is currently downloading repository information separately for each user.
It can use the same downloaded repository information for all users.
For example : root did yum install <some-package> followed by
Non root user did : yum info <same-package>.
yum will currently fetch repo information again for the non root user.
Reason to have this feature : Save time, bandwidth.

Wrong, information are cached in /var/lib/yum.

Post by elison.niven
4) Quit on single CTRL-C. Users expect an application to quit on
pressing CTRL-C.
Reason to have this feature : Better user experience

Do you really want the option to ^c in the middle of an update ?
Allowing the user to end-up with a half-updated system ?

Pierre

[Adam Williamson]

Post by Pierre-Yves Chibon

Post by elison.niven
2) yum is currently downloading repository information separately for each user.
It can use the same downloaded repository information for all users.
For example : root did yum install <some-package> followed by
Non root user did : yum info <same-package>.
yum will currently fetch repo information again for the non root user.
Reason to have this feature : Save time, bandwidth.

Wrong, information are cached in /var/lib/yum.

I don't know the technical background, but I certainly see the 'user
experience' side of the complaint. Running 'yum info foobar' as user on
my system takes much longer than running it as root. The logical
conclusion is root has access to some cache that my user doesn't.

[Gerd Hoffmann]

Hi,

Post by Pierre-Yves Chibon

Post by elison.niven
2) yum is currently downloading repository information separately for each user.
It can use the same downloaded repository information for all users.

Wrong, information are cached in /var/lib/yum.

When you run yum as user it doesn't use the cache though. It creates
its own cache somewhere in /var/tmp. It ignores the cachedir option too.

cheers
Gerd

[Johannes Lips]

There is a filed bug regarding this behavior. But so far no explanation or
cause for this behavior.
https://bugzilla.redhat.com/show_bug.cgi?id=771043

Johannes

Post by Gerd Hoffmann
Hi,

Post by Pierre-Yves Chibon

Post by elison.niven
2) yum is currently downloading repository information separately for each user.
It can use the same downloaded repository information for all users.

Wrong, information are cached in /var/lib/yum.

When you run yum as user it doesn't use the cache though. It creates
its own cache somewhere in /var/tmp. It ignores the cachedir option too.
cheers
Gerd
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120228/849cb5e8/attachment.html>

[James Antill]

Post by elison.niven

Post by Josh Boyer

Post by elison.niven
8) Yum cannot use an iso image as a repo without mounting it.
Yast in suse allows to directly use iso images as repos.

1) A proposed alternative

I am more than happy to propose alternatives.
Alternative 1 : Use a totally different package management system : apt-get
It is mature enough. I know this is going to be rejected totally even
without consideration.

Have you actually used apt on Fedora?
The main benefit apt on Debian/Ubuntu has is that the repodata is very
different, making repodata updates much faster. It also helps that only
Debian unstable updates as much as Fedora stable.

Post by elison.niven
1) yum should maintain status of installed packages locally. And it
should not need to fetch repository information when user tries
yum info <installed-package>
Reason to have this feature : It seems logical to have information
about an installed package locally.

AFAIK the following will only look at the local data:

yum --nocolor info installed blah

Post by elison.niven
2) yum is currently downloading repository information separately for each user.
It can use the same downloaded repository information for all users.

Kind of, we used to have non-root users use root's cache ... but that
caused lots of annoying problems.
I "have a plan" for Fedora 18, that should make things better. We'll
see.

Post by elison.niven
3) Show progress in "Setting up update process" or "Setting up install process".
At present, users cannot know that is it working or sleeping.
Reason to have this feature : Better user experience

There is a significant delay between these two pieces:

Setting up Upgrade Process
Resolving Dependencies

...is this when you are doing a full "yum upgrade" or upgrading a
specific package too? How long is the delay?