On Mon, Feb 27 12:13:07 UTC 2012, Josh Boyer jwboyer at gmail.com wrote
On Mon, Feb 27, 2012 at 1:44 AM, elison.niven at gmail.com: 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.
You also forgot to add:
- 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.
- Patches to fix any of the issues you pointed out
I am not a yum developer at present nor am acquainted with the source.
- Anything constructive at all in your ramblings.
Does the above count now as constructive?
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
On 27/02/12 13:52, elison.niven@gmail.com wrote: <snipped>
Alternative 2 : Make the following changes to yum to make yum better:
- 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
- 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.
- 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
- 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.
On Mon, Feb 27, 2012 at 14:00:51 +0000, Frank Murphy frankly3d@gmail.com wrote:
On 27/02/12 13:52, elison.niven@gmail.com wrote:
- 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.
On 02/27/2012 07:29 AM, Bruno Wolff III wrote:
On Mon, Feb 27, 2012 at 14:00:51 +0000, Frank Murphy frankly3d@gmail.com wrote:
On 27/02/12 13:52, elison.niven@gmail.com wrote:
- 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.
--
On Mon, Feb 27, 2012 at 08:00:56 -0800, John Reiser jreiser@bitwagon.com wrote:
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.
On Feb 27, 2012, at 9:08 AM, Bruno Wolff III wrote:
I don't believe yum has a way to roll back transactions reliably.
http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs
Chris Murphy
On Mon, Feb 27, 2012 at 11:24:55 -0700, Chris Murphy lists@colorremedies.com wrote:
On Feb 27, 2012, at 9:08 AM, Bruno Wolff III wrote:
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).
On Mon, Feb 27, 2012 at 8:18 PM, Bruno Wolff III bruno@wolff.to wrote:
On Mon, Feb 27, 2012 at 11:24:55 -0700, Chris Murphy lists@colorremedies.com wrote:
On Feb 27, 2012, at 9:08 AM, Bruno Wolff III wrote:
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.
On Feb 27, 2012, at 12:22 PM, drago01 wrote:
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
On Feb 27, 2012, at 12:18 PM, Bruno Wolff III wrote:
On Mon, Feb 27, 2012 at 11:24:55 -0700, Chris Murphy lists@colorremedies.com wrote:
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
On Mon, 2012-02-27 at 12:25 -0700, Chris Murphy wrote:
On Feb 27, 2012, at 12:18 PM, Bruno Wolff III wrote:
On Mon, Feb 27, 2012 at 11:24:55 -0700, Chris Murphy lists@colorremedies.com wrote:
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.
On Feb 27, 2012, at 1:56 PM, James Antill wrote:
On Mon, 2012-02-27 at 12:25 -0700, Chris Murphy wrote:
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
On Mon, 2012-02-27 at 11:24 -0700, Chris Murphy wrote:
On Feb 27, 2012, at 9:08 AM, Bruno Wolff III wrote:
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?
On Feb 27, 2012, at 9:28 PM, Adam Williamson wrote:
On Mon, 2012-02-27 at 11:24 -0700, Chris Murphy wrote:
On Feb 27, 2012, at 9:08 AM, Bruno Wolff III wrote:
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
On Tue, Feb 28, 2012 at 12:39 PM, Chris Murphy lists@colorremedies.com wrote:
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
On Feb 28, 2012, at 12:19 AM, elison.niven@gmail.com wrote:
On Tue, Feb 28, 2012 at 12:39 PM, Chris Murphy lists@colorremedies.com wrote:
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
On 02/28/2012 08:51 AM, Chris Murphy wrote:
*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.
On Feb 28, 2012, at 10:02 AM, John Reiser wrote:
On 02/28/2012 08:51 AM, Chris Murphy wrote:
*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
On 02/27/2012 06:00 PM, John Reiser wrote:
On 02/27/2012 07:29 AM, Bruno Wolff III wrote:
On Mon, Feb 27, 2012 at 14:00:51 +0000, Frank Murphyfrankly3d@gmail.com wrote:
On 27/02/12 13:52, elison.niven@gmail.com wrote:
- 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 -
On Mon, Feb 27, 2012 at 5:11 PM, Panu Matilainen pmatilai@laiskiainen.org wrote:
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).
I got many replies to my mail that answer many of my questions. Thanks to all.
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?
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".
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.
yum -C info <installed-package> from --help: -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.
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
On 02/27/2012 08:11 AM, Panu Matilainen wrote:
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.
* John Reiser [27/02/2012 22:50] :
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).
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
On 02/27/2012 04:29 PM, Bruno Wolff III wrote:
On Mon, Feb 27, 2012 at 14:00:51 +0000, Frank Murphyfrankly3d@gmail.com wrote:
On 27/02/12 13:52, elison.niven@gmail.com wrote:
- 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.
On 02/27/2012 11:44 AM, Sandro Mani wrote:
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.
Control-Z bg kill -9 %1
On Mon, Feb 27, 2012 at 11:56:12AM -0500, Genes MailLists wrote:
On 02/27/2012 11:44 AM, Sandro Mani wrote:
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.
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.
On Mon, 2012-02-27 at 17:45 +0000, Richard W.M. Jones wrote:
On Mon, Feb 27, 2012 at 11:56:12AM -0500, Genes MailLists wrote:
On 02/27/2012 11:44 AM, Sandro Mani wrote:
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.
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):
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).
On Mon, Feb 27, 2012 at 04:08:53PM -0500, James Antill wrote:
There are at least 3 classes of bugs here:
- 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.
- 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".
- 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.
On Mon, 2012-02-27 at 21:22 +0000, Richard W.M. Jones wrote:
On Mon, Feb 27, 2012 at 04:08:53PM -0500, James Antill wrote:
There are at least 3 classes of bugs here:
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.
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.
Wiadomość napisana przez Bruno Wolff III w dniu 2012-02-27, o godz. 16:29:
On Mon, Feb 27, 2012 at 14:00:51 +0000, Frank Murphy frankly3d@gmail.com wrote:
On 27/02/12 13:52, elison.niven@gmail.com wrote:
- 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,
On Thu, 2012-03-01 at 00:34 +0100, Jarosław Górny wrote:
- 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.
On 2/29/12 4:06 PM, Sérgio Basto wrote:
Ctrl-Z and kill %1 normally do a better job.
Providing a different method of reaching the same goal is missing the point.
On Thu, 2012-03-01 at 00:34 +0100, Jarosław Górny wrote:
Wiadomość napisana przez Bruno Wolff III w dniu 2012-02-27, o godz. 16:29:
On Mon, Feb 27, 2012 at 14:00:51 +0000, Frank Murphy frankly3d@gmail.com wrote:
On 27/02/12 13:52, elison.niven@gmail.com wrote:
- 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".
On Mon, 2012-02-27 at 19:22 +0530, elison.niven@gmail.com wrote:
- 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
- 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.
- 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
On Mon, 2012-02-27 at 15:04 +0100, Pierre-Yves Chibon wrote:
- 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.
Hi,
- 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
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 On Tue, Feb 28, 2012 at 9:04 AM, Gerd Hoffmann kraxel@redhat.com wrote:
Hi,
- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 2012-02-27 at 19:22 +0530, elison.niven@gmail.com wrote:
On Mon, Feb 27 12:13:07 UTC 2012, Josh Boyer jwboyer at gmail.com wrote
On Mon, Feb 27, 2012 at 1:44 AM, elison.niven at gmail.com: 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.
You also forgot to add:
- 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.
Alternative 2 : Make the following changes to yum to make yum better:
- 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
- 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.
- 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?
devel@lists.stg.fedoraproject.org