7:52 a.m.
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:
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.
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.
3) 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
8 a.m.
New subject: Issues with yum
On 27/02/12 13:52, elison.niven(a)gmail.com wrote:
<snipped>
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.
try:
yumdb --help
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.
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
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.
--
Regards,
Frank
"Jack of all, fubars"
9:29 a.m.
New subject: Issues with yum
On Mon, Feb 27, 2012 at 14:00:51 +0000,
Frank Murphy <frankly3d(a)gmail.com> wrote:
On 27/02/12 13:52, elison.niven(a)gmail.com wrote:
>
>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.
10 a.m.
New subject: Issues with yum
On 02/27/2012 07:29 AM, Bruno Wolff III wrote:
On Mon, Feb 27, 2012 at 14:00:51 +0000,
Frank Murphy <frankly3d(a)gmail.com> wrote:
> On 27/02/12 13:52, elison.niven(a)gmail.com wrote:
>>
>> 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.
--
10:08 a.m.
New subject: Issues with yum
On Mon, Feb 27, 2012 at 08:00:56 -0800,
John Reiser <jreiser(a)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.
12:24 p.m.
New subject: Issues with yum
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
1:18 p.m.
New subject: Issues with yum
On Mon, Feb 27, 2012 at 11:24:55 -0700,
Chris Murphy <lists(a)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).
1:22 p.m.
New subject: Issues with yum
On Mon, Feb 27, 2012 at 8:18 PM, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Mon, Feb 27, 2012 at 11:24:55 -0700,
Chris Murphy <lists(a)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.
1:27 p.m.
New subject: Issues with yum
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
1:25 p.m.
New subject: Issues with yum
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(a)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
2:56 p.m.
New subject: Issues with yum
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(a)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.
3:09 p.m.
New subject: Issues with yum
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
10:28 p.m.
New subject: Issues with yum
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?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
1:09 a.m.
New subject: Issues with yum
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
1:19 a.m.
New subject: Issues with yum
On Tue, Feb 28, 2012 at 12:39 PM, Chris Murphy <lists(a)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
10:51 a.m.
New subject: Issues with yum
On Feb 28, 2012, at 12:19 AM, elison.niven(a)gmail.com wrote:
On Tue, Feb 28, 2012 at 12:39 PM, Chris Murphy
<lists(a)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
11:02 a.m.
New subject: Issues with yum
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.
--
11:14 a.m.
New subject: Issues with yum
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
10:11 a.m.
New subject: Issues with yum
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 Murphy<frankly3d(a)gmail.com> wrote:
>> On 27/02/12 13:52, elison.niven(a)gmail.com wrote:
>>>
>>> 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 -
10:56 a.m.
New subject: Issues with yum
On Mon, Feb 27, 2012 at 5:11 PM, Panu Matilainen
<pmatilai(a)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).
12:09 p.m.
New subject: Issues with yum
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
3:13 p.m.
New subject: Issues with yum
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.
--
4:02 p.m.
New subject: Issues with yum
* 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
10:44 a.m.
New subject: Issues with yum
On 02/27/2012 04:29 PM, Bruno Wolff III wrote:
On Mon, Feb 27, 2012 at 14:00:51 +0000,
Frank Murphy<frankly3d(a)gmail.com> wrote:
> On 27/02/12 13:52, elison.niven(a)gmail.com wrote:
>> 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.
10:56 a.m.
New subject: Issues with yum
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
11:45 a.m.
New subject: Issues with yum
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
3:08 p.m.
New subject: Issues with yum
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).
3:22 p.m.
New subject: Issues with yum
On Mon, Feb 27, 2012 at 04:08:53PM -0500, James Antill wrote:
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).
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
3:28 p.m.
New subject: Issues with yum
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.
5:34 p.m.
New subject: Issues with yum
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(a)gmail.com> wrote:
> On 27/02/12 13:52, elison.niven(a)gmail.com wrote:
>>
>> 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,
--
Jarosław Górny
RHCE: 805008212834187
6:06 p.m.
New subject: Issues with yum
On Thu, 2012-03-01 at 00:34 +0100, Jarosław Górny wrote:
>>> 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.
--
Sérgio M. B.
11:20 p.m.
New subject: Issues with yum
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.
--
Help me fight child abuse: http://tinyurl.com/jlkcourage
- jlk
9:21 a.m.
New subject: Issues with yum
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(a)gmail.com> wrote:
>> On 27/02/12 13:52, elison.niven(a)gmail.com wrote:
>>>
>>> 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".
8:04 a.m.
New subject: Issues with yum
On Mon, 2012-02-27 at 19:22 +0530, elison.niven(a)gmail.com wrote:
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
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.
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
10:21 p.m.
New subject: Issues with yum
On Mon, 2012-02-27 at 15:04 +0100, Pierre-Yves Chibon wrote:
> 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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:04 a.m.
New subject: Issues with yum
Hi,
> 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
3:20 a.m.
New subject: Issues with yum
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(a)redhat.com> wrote:
Hi,
>> 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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
9:03 a.m.
New subject: Issues with yum
On Mon, 2012-02-27 at 19:22 +0530, elison.niven(a)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:
> 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.
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.
AFAIK the following will only look at the local data:
yum --nocolor info installed blah
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.
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?
4436
days inactive
4439
days old
37 comments
19 participants
participants (19)
-
Adam Williamson -
Bruno Wolff III -
Chris Murphy -
drago01 -
elison.niven＠gmail.com -
Emmanuel Seyman -
Frank Murphy -
Genes MailLists -
Gerd Hoffmann -
James Antill -
Jarosław Górny -
Jesse Keating -
Johannes Lips -
John Reiser -
Panu Matilainen -
Pierre-Yves Chibon -
Richard W.M. Jones -
Sandro Mani -
Sérgio Basto