So just to be sure I understand. You take the list of updateable pkgs, and you iterate over each one until you can't update anything completely anymore. Is that right?
-sv
Correct.
I couldn't figure out a way to make yum do that itself and at first glance the -t option looks like it was built for that purpose.
Also, I couldn't figure out how to make yum stop "Gathering header information file(s) from server(s)" every single time it is run (to iterate through that list faster). I thought the -C option would but I doesn't.
The script shouldn't install anything that you don't already have installed unless it is a new dependency from something you are updating.
(Sorry for the broken topic threading ... replying from message digest)
/Mike
On Mon, 2004-03-15 at 01:29, Michael Wiktowy wrote:
So just to be sure I understand. You take the list of updateable pkgs, and you iterate over each one until you can't update anything completely anymore. Is that right?
-sv
Correct.
I couldn't figure out a way to make yum do that itself and at first glance the -t option looks like it was built for that purpose.
Also, I couldn't figure out how to make yum stop "Gathering header information file(s) from server(s)" every single time it is run (to iterate through that list faster). I thought the -C option would but I doesn't.
The script shouldn't install anything that you don't already have installed unless it is a new dependency from something you are updating.
(Sorry for the broken topic threading ... replying from message digest)
/Mike
The way my rawhide mirror works (mirror of a mirror), it would be nice if yum had a --update-what-you-can option. After a normal pass, it would just --exclude anything it reports as not upgradeable due to dependency issues and tries again until it succeeds. I don't know python but I may try to do a wrapper in perl...
tjb
The way my rawhide mirror works (mirror of a mirror), it would be nice if yum had a --update-what-you-can option. After a normal pass, it would just --exclude anything it reports as not upgradeable due to dependency issues and tries again until it succeeds. I don't know python but I may try to do a wrapper in perl...
Ok, 1. wrapping python programs in perl is simply DIRTY. Let's not do that. 2. it's funny that the only reason people want this feature in yum is b/c rawhide is so frequently dependency-incomplete. Kinda an odd direction to follow for writing features.
-sv
On Mon, 2004-03-15 at 09:46, seth vidal wrote:
The way my rawhide mirror works (mirror of a mirror), it would be nice if yum had a --update-what-you-can option. After a normal pass, it would just --exclude anything it reports as not upgradeable due to dependency issues and tries again until it succeeds. I don't know python but I may try to do a wrapper in perl...
Ok,
- wrapping python programs in perl is simply DIRTY. Let's not do
that. 2. it's funny that the only reason people want this feature in yum is b/c rawhide is so frequently dependency-incomplete. Kinda an odd direction to follow for writing features.
-sv
1 - I (mostly) said that because I knew it would gross you out!
2 - Considering the number of times I run yum during a beta period and how often rawhide is broken/incompletely mirrored, it would be a very worthwhile feature IMHO... and why I will still probably do #1 for my personal use unless you have other plans :-)
tjb
On Mon, 2004-03-15 at 16:46, seth vidal wrote:
The way my rawhide mirror works (mirror of a mirror), it would be nice if yum had a --update-what-you-can option. After a normal pass, it would just --exclude anything it reports as not upgradeable due to dependency issues and tries again until it succeeds. I don't know python but I may try to do a wrapper in perl...
Ok,
- wrapping python programs in perl is simply DIRTY. Let's not do
that. 2. it's funny that the only reason people want this feature in yum is b/c rawhide is so frequently dependency-incomplete. Kinda an odd direction to follow for writing features.
But then.. if you can't use the depsolvers to keep up with rawhide, back to rpm -Fvh <shrudder>
Apt has --fix-missing which attempts to fix the upgrade-set after downloading what's available and dropping any unsatisfied dependencies from the upgrade set. Not that I really know but I suspect that the existence of that option has everything to do with Debian unstable repository, not unlike rawhide in nature...
- Panu -
But then.. if you can't use the depsolvers to keep up with rawhide, back to rpm -Fvh <shrudder>
I didn't say it was out I just said it's a funny direction for things to follow. You'd think if so many people were going to follow rawhide then so many people would spend more time making it a touch more consistent before it gets pushed.
running a check for internal dependency consistency across the whole rawhide tree isn't that hard.
-sv
On Mon, 2004-03-15 at 09:32, seth vidal wrote:
But then.. if you can't use the depsolvers to keep up with rawhide, back to rpm -Fvh <shrudder>
I didn't say it was out I just said it's a funny direction for things to follow. You'd think if so many people were going to follow rawhide then so many people would spend more time making it a touch more consistent before it gets pushed.
Unfortunately, we (that is, non-RH employees involved in fedora) have not been given any ability to do this yet. Things seem to be broken for days at a time right now, rather than for just 24-hours after the last push, by which time several people have usually found and reported the issue here, if not in bugzilla.
Where SHOULD "rawhide deps are broken" reports go to, and what information do folks want in them? Greg
On Mon, Mar 15, 2004 at 09:42:14AM -0500, Thomas J. Baker wrote:
Reply-To: For testers of Fedora Core development releases fedora-test-list@redhat.com
On Mon, 2004-03-15 at 01:29, Michael Wiktowy wrote:
So just to be sure I understand. You take the list of updateable pkgs, and you iterate over each one until you can't update anything completely anymore. Is that right?
Also, I couldn't figure out how to make yum stop "Gathering header information file(s) from server(s)" every single time it is run (to iterate through that list faster).
....
The way my rawhide mirror works (mirror of a mirror), it would be nice if yum had a --update-what-you-can option. After a normal pass, it would just --exclude
In a pinch do a "up2date-nox --list" or a "yum list updates" and save the output to a file. Then edit that in to a script that updates one or two or three packages at a time. The packages that can be installed will be installed. Then a new list can be generated and turned into a script.
Also, by commenting out all but one or two sites in the yum.conf file you can often keep things simple enough to not have circular dependency requirements.
On Mon, 2004-03-15 at 21:27 -0800, Tom Mitchell wrote:
On Mon, Mar 15, 2004 at 09:42:14AM -0500, Thomas J. Baker wrote:
Reply-To: For testers of Fedora Core development releases fedora-test-list@redhat.com
On Mon, 2004-03-15 at 01:29, Michael Wiktowy wrote:
So just to be sure I understand. You take the list of updateable pkgs, and you iterate over each one until you can't update anything completely anymore. Is that right?
Also, I couldn't figure out how to make yum stop "Gathering header information file(s) from server(s)" every single time it is run (to iterate through that list faster).
....
The way my rawhide mirror works (mirror of a mirror), it would be nice if yum had a --update-what-you-can option. After a normal pass, it would just --exclude
In a pinch do a "up2date-nox --list" or a "yum list updates" and save the output to a file. Then edit that in to a script that updates one or two or three packages at a time. The packages that can be installed will be installed. Then a new list can be generated and turned into a script.
The easiest way is to get familiar with "yum provides <file>" and "yum list <pkg>". Sometimes you'll want to exclude ("yum --exclude=<pkg> update") a package from update, other times you'll want to remove the offending package ("rpm -e <pkg>"). There's no easy logic to automate.