12:06 p.m.
When I try to preupgrade F10 to F11-alpha I don't see any selection for
F11-alpha, only Rawhide. Shouldn't there be a selection for F11-alpha
if I check off the "show everything" box? (this is on a test machine).
Regards,
Gerry
12:21 p.m.
On Thu, Mar 19, 2009 at 6:06 PM, Gerry Reno <greno(a)verizon.net> wrote:
When I try to preupgrade F10 to F11-alpha I don't see any
selection for
F11-alpha, only Rawhide. Shouldn't there be a selection for F11-alpha if I
check off the "show everything" box? (this is on a test machine).
Beside the technical problem for tracking which versions were present
in the alpha, I don't think there is a point in upgrading to Alpha
given that it will update to latest rawhide at first yum/pk run...
--
Gianluca Sforna
http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna
5:02 p.m.
On Thu, Mar 19, 2009 at 06:21:20PM +0100, Gianluca Sforna wrote:
On Thu, Mar 19, 2009 at 6:06 PM, Gerry Reno <greno(a)verizon.net>
wrote:
> When I try to preupgrade F10 to F11-alpha I don't see any selection for
> F11-alpha, only Rawhide. Shouldn't there be a selection for F11-alpha if I
> check off the "show everything" box? (this is on a test machine).
Beside the technical problem for tracking which versions were present
in the alpha, I don't think there is a point in upgrading to Alpha
given that it will update to latest rawhide at first yum/pk run...
And make sure you update rpm and yum before proceeding with a
pre-upgrade. Or does pre-upgrade do that first automatically?
https://fedoraproject.org/wiki/Fedora_11_Beta_release_notes#Known_Issues
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
6:04 p.m.
Paul W. Frields wrote:
On Thu, Mar 19, 2009 at 06:21:20PM +0100, Gianluca Sforna wrote:
> On Thu, Mar 19, 2009 at 6:06 PM, Gerry Reno <greno(a)verizon.net> wrote:
>
>> When I try to preupgrade F10 to F11-alpha I don't see any selection for
>> F11-alpha, only Rawhide. Shouldn't there be a selection for F11-alpha if I
>> check off the "show everything" box? (this is on a test machine).
>>
> Beside the technical problem for tracking which versions were present
> in the alpha, I don't think there is a point in upgrading to Alpha
> given that it will update to latest rawhide at first yum/pk run...
>
And make sure you update rpm and yum before proceeding with a
pre-upgrade. Or does pre-upgrade do that first automatically?
https://fedoraproject.org/wiki/Fedora_11_Beta_release_notes#Known_Issues
I think yum should automatically do that for you. It should first check
if new 'rpm' and 'yum' are available and if so upgrade them and then
reinvoke itself.
Regards,
Gerry
4:38 a.m.
On Thu, 19 Mar 2009, Paul W. Frields wrote:
And make sure you update rpm and yum before proceeding with a
pre-upgrade. Or does pre-upgrade do that first automatically?
https://fedoraproject.org/wiki/Fedora_11_Beta_release_notes#Known_Issues
For preupgrade it shouldn't matter, because it does a full anaconda based
upgrade, booting from the install image, and that will include all the
required package versions. The difference between preupgrade and a DVD
based upgrade is that preupgrade assembles the packages you are going
to need on local disks before booting from the install image, rather than
relying on the standard collection from the DVD.
Michael Young
8:07 a.m.
Right, but my comment was more geared towards the fact that installing
from F11-Alpha and trying to run 'yum update' at one point wasn't
possible without first running 'yum update rpm' and then 'yum update'.
I think that is a flaw in the priority of package installation, if it
had first checked for a new yum or new rpm package, installed those
and then re-invoked itself then the problem would be solved.
-Adam
On Fri, Mar 20, 2009 at 4:38 AM, M A Young <m.a.young(a)durham.ac.uk> wrote:
On Thu, 19 Mar 2009, Paul W. Frields wrote:
> And make sure you update rpm and yum before proceeding with a
> pre-upgrade. Or does pre-upgrade do that first automatically?
>
> https://fedoraproject.org/wiki/Fedora_11_Beta_release_notes#Known_Issues
For preupgrade it shouldn't matter, because it does a full anaconda based
upgrade, booting from the install image, and that will include all the
required package versions. The difference between preupgrade and a DVD based
upgrade is that preupgrade assembles the packages you are going to need on
local disks before booting from the install image, rather than relying on
the standard collection from the DVD.
Michael Young
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
10:35 a.m.
On Fri, 2009-03-20 at 08:07 -0500, Adam Miller wrote:
Right, but my comment was more geared towards the fact that
installing
from F11-Alpha and trying to run 'yum update' at one point wasn't
possible without first running 'yum update rpm' and then 'yum update'.
I think that is a flaw in the priority of package installation, if it
had first checked for a new yum or new rpm package, installed those
and then re-invoked itself then the problem would be solved.
In the rare scenario of alpha -> missed some updates -> rawhide case,
it might help some. In the far more common F10 -> rawhide case it
wouldn't help one bit. Why? Because trying to go from an out of date
F10 directly to rawhide rpm would drag in hundreds and hundreds of
packages due to deps, because python changed. The only way around this
is to fully update your F10 with F10 updates, and /then/ proceed to
rawhide, which you can do in one full swing.
The updater updating itself and restarting doesn't really solve enough
scenarios to add in the complication and complexity and numerous new
failure cases.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
11:03 a.m.
Jesse Keating wrote:
On Fri, 2009-03-20 at 08:07 -0500, Adam Miller wrote:
> Right, but my comment was more geared towards the fact that installing
> from F11-Alpha and trying to run 'yum update' at one point wasn't
> possible without first running 'yum update rpm' and then 'yum
update'.
> I think that is a flaw in the priority of package installation, if it
> had first checked for a new yum or new rpm package, installed those
> and then re-invoked itself then the problem would be solved.
>
In the rare scenario of alpha -> missed some updates -> rawhide case,
it might help some. In the far more common F10 -> rawhide case it
wouldn't help one bit. Why? Because trying to go from an out of date
F10 directly to rawhide rpm would drag in hundreds and hundreds of
packages due to deps, because python changed. The only way around this
is to fully update your F10 with F10 updates, and /then/ proceed to
rawhide, which you can do in one full swing.
The updater updating itself and restarting doesn't really solve enough
scenarios to add in the complication and complexity and numerous new
failure cases.
The need to make sure that you update rpm or yum before you do 'yum
update' has happened before and I'm sure this isn't the last time that
it will happen either. It just makes sense for a packager to see if
there is an update to itself first. Update itself and THEN do the
updates for everything else.
Regards,
Gerry
11:37 a.m.
On Fri, 2009-03-20 at 12:03 -0400, Gerry Reno wrote:
The need to make sure that you update rpm or yum before you do
'yum
update' has happened before and I'm sure this isn't the last time that
it will happen either. It just makes sense for a packager to see if
there is an update to itself first. Update itself and THEN do the
updates for everything else.
That's your opinion. The opinion of the people writing the update tools
and preparing the repos and living through such "needs" and really
understanding what is actually going on don't share that opinion.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12:27 p.m.
Jesse Keating wrote:
On Fri, 2009-03-20 at 12:03 -0400, Gerry Reno wrote:
> The need to make sure that you update rpm or yum before you do 'yum
> update' has happened before and I'm sure this isn't the last time that
> it will happen either. It just makes sense for a packager to see if
> there is an update to itself first. Update itself and THEN do the
> updates for everything else.
>
That's your opinion. The opinion of the people writing the update tools
and preparing the repos and living through such "needs" and really
understanding what is actually going on don't share that opinion.
What is the matter with yum doing something like this?
if updated yum or updated rpm is available:
if updated yum is available:
update yum
yum_is_new = true
if updated rpm is available:
update rpm
if yum_is_new:
sys.execv("/usr/bin/yum", sys.argv) # replace current process
with updated yum
Regards,
Gerry
12:37 p.m.
On Friday, March 20 2009, Gerry Reno said:
Jesse Keating wrote:
> On Fri, 2009-03-20 at 12:03 -0400, Gerry Reno wrote:
>> The need to make sure that you update rpm or yum before you do 'yum
>> update' has happened before and I'm sure this isn't the last time
>> that it will happen either. It just makes sense for a packager to
>> see if there is an update to itself first. Update itself and THEN do
>> the updates for everything else.
>
> That's your opinion. The opinion of the people writing the update tools
> and preparing the repos and living through such "needs" and really
> understanding what is actually going on don't share that opinion.
What is the matter with yum doing something like this?
if updated yum or updated rpm is available:
if updated yum is available:
update yum
yum_is_new = true
if updated rpm is available:
update rpm
if yum_is_new:
sys.execv("/usr/bin/yum", sys.argv) # replace current process
with updated yum
New yum may depend on new python, new glibc, etc and thus 'update yum'
may essentially be 'update everything'
Jeremy
12:50 p.m.
Jeremy Katz wrote:
On Friday, March 20 2009, Gerry Reno said:
> Jesse Keating wrote:
>
>> On Fri, 2009-03-20 at 12:03 -0400, Gerry Reno wrote:
>>
>>> The need to make sure that you update rpm or yum before you do 'yum
>>> update' has happened before and I'm sure this isn't the last time
>>> that it will happen either. It just makes sense for a packager to
>>> see if there is an update to itself first. Update itself and THEN do
>>> the updates for everything else.
>>>
>> That's your opinion. The opinion of the people writing the update tools
>> and preparing the repos and living through such "needs" and really
>> understanding what is actually going on don't share that opinion.
>>
> What is the matter with yum doing something like this?
>
> if updated yum or updated rpm is available:
> if updated yum is available:
> update yum
> yum_is_new = true
> if updated rpm is available:
> update rpm
> if yum_is_new:
> sys.execv("/usr/bin/yum", sys.argv) # replace current process
> with updated yum
>
New yum may depend on new python, new glibc, etc and thus 'update yum'
may essentially be 'update everything'
Jeremy
Ok, understand that. So an update of yum has to be left until the very
last moment just before other things that require it.
So maybe change the first line to:
if found package that requires new yum or rpm and updated yum or updated
rpm is available:
That way yum wouldn't update yum/rpm unless something actually required
the updated yum/rpm.
My interest was just to make the process as simple as possible.
Regards,
Gerry
1:34 p.m.
On Fri, 20 Mar 2009, Gerry Reno wrote:
Ok, understand that. So an update of yum has to be left until the very last moment just
before other things that require
it.
So maybe change the first line to:
if found package that requires new yum or rpm and updated yum or updated rpm is
available:
That way yum wouldn't update yum/rpm unless something actually required the updated
yum/rpm.
My interest was just to make the process as simple as possible.
Here's my other hang up with it.
If the user issued:
yum install zsh
Does it seem right to check for a yum update and/or rpm updates before
doing what the user asked?
I think we'd be better served with making this better via dependencies. If
you cannot use your current rpm to install the pkgs updates that are
available it should fail long before the transaction.
imo.
-sv
1:43 p.m.
On Fri, 2009-03-20 at 14:34 -0400, Seth Vidal wrote:
Here's my other hang up with it.
If the user issued:
yum install zsh
Does it seem right to check for a yum update and/or rpm updates before
doing what the user asked?
FWIW, Mandriva (which, as I've mentioned, implements this) doesn't do
the check in that case. It only does the check if you do one of the
'automatically update my system' commands, like 'urpmi
--auto-update' (equivalent to 'yum upgrade', pretty much).
Just a note.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:48 p.m.
Seth Vidal wrote:
On Fri, 20 Mar 2009, Gerry Reno wrote:
>
> Ok, understand that. So an update of yum has to be left until the
> very last moment just before other things that require
> it.
>
> So maybe change the first line to:
>
> if found package that requires new yum or rpm and updated yum
> or updated rpm is available:
>
>
>
> That way yum wouldn't update yum/rpm unless something actually
> required the updated yum/rpm.
>
> My interest was just to make the process as simple as possible.
>
Here's my other hang up with it.
If the user issued:
yum install zsh
Does it seem right to check for a yum update and/or rpm updates before
doing what the user asked?
I think we'd be better served with making this better via
dependencies. If you cannot use your current rpm to install the pkgs
updates that are available it should fail long before the transaction.
imo.
-sv
That is what the first 'if' should do. Act as a filter. So only if
'zsh' had a dependency on a new yum or rpm would it go check for a new
yum/rpm. Otherwise it would just do the zsh update.
My perspective is from the user point of view. If the user is
upgrading to a new release let's say and the process goes along for
quite a while and then decides to bomb out because the rpm version
needed to be newer then the user becomes confused. The software should
take care of this. So if any package in the whole update requires a
newer yum/rpm then I think yum should go do that first.
Regards,
Gerry
4:34 p.m.
On Fri, 2009-03-20 at 14:48 -0400, Gerry Reno wrote:
My perspective is from the user point of view. If the user is
upgrading to a new release let's say and the process goes along for
quite a while and then decides to bomb out because the rpm version
needed to be newer then the user becomes confused. The software should
take care of this. So if any package in the whole update requires a
newer yum/rpm then I think yum should go do that first.
Upgrading to a new release is precisely when this will fail. The "new
yum" and "new rpm" would require all the other new packages in order to
be functional. There is no way to use the new yum without the rest of
the new stuff.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:38 p.m.
Then why was I able to pull the new rpm without any other packages
when going from Alpha -> Current Rawhide?
-Adam
2009/3/20 Jesse Keating <jkeating(a)redhat.com>:
On Fri, 2009-03-20 at 14:48 -0400, Gerry Reno wrote:
>
> My perspective is from the user point of view. If the user is
> upgrading to a new release let's say and the process goes along for
> quite a while and then decides to bomb out because the rpm version
> needed to be newer then the user becomes confused. The software should
> take care of this. So if any package in the whole update requires a
> newer yum/rpm then I think yum should go do that first.
Upgrading to a new release is precisely when this will fail. The "new
yum" and "new rpm" would require all the other new packages in order to
be functional. There is no way to use the new yum without the rest of
the new stuff.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
5:02 p.m.
2009/3/20 Adam Miller <maxamillion(a)gmail.com>
Then why was I able to pull the new rpm without any other packages
when going from Alpha -> Current Rawhide?
Because in this particular case rpm didnt need a newer version of any other
packages but there have been and will continue to be many cases where rpm
does require later versions of some supporting library. These are the cases
i think Jesse was talking about when saying that we cant have yum install
rpm by itself first regardless. It may rely on some other updated package
and that would fail under those circumstances
--
There are 10 kinds of people in the world: Those who understand binary and
those who don't...
5:09 p.m.
On Fri, 2009-03-20 at 22:02 +0000, John5342 wrote:
2009/3/20 Adam Miller <maxamillion(a)gmail.com>
Then why was I able to pull the new rpm without any other
packages
when going from Alpha -> Current Rawhide?
Because in this particular case rpm didnt need a newer version of any
other packages but there have been and will continue to be many cases
where rpm does require later versions of some supporting library.
These are the cases i think Jesse was talking about when saying that
we cant have yum install rpm by itself first regardless. It may rely
on some other updated package and that would fail under those
circumstances
I don't see why it would fail. When I spoke to him, Jesse's argument was
not that it would fail (or, more precisely, that it would be any more
*likely* to fail than the current system), just that in most practical
real-world cases it would not be significantly different from the
current system and it's therefore not worth the effort to implement.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
5:14 p.m.
On Fri, 2009-03-20 at 16:38 -0500, Adam Miller wrote:
Then why was I able to pull the new rpm without any other packages
when going from Alpha -> Current Rawhide?
Because you're not doing a major version upgrade. Gerry was talking
about F10 -> rawhide, not alpha -> rawhide.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
5:50 p.m.
Jesse Keating wrote:
On Fri, 2009-03-20 at 14:48 -0400, Gerry Reno wrote:
> My perspective is from the user point of view. If the user is
> upgrading to a new release let's say and the process goes along for
> quite a while and then decides to bomb out because the rpm version
> needed to be newer then the user becomes confused. The software should
> take care of this. So if any package in the whole update requires a
> newer yum/rpm then I think yum should go do that first.
>
Upgrading to a new release is precisely when this will fail. The "new
yum" and "new rpm" would require all the other new packages in order to
be functional. There is no way to use the new yum without the rest of
the new stuff.
This then says to me that packagers ought to be completely static and
not dependent on anything, so that we can actually perform an upgrade on
them first and then upgrade everything else. Or alternatively, we load
a static version to complete the upgrade and then update to the shared
version.
To require that the user remember to perform certain preupgrade
procedures is just asking for lots of user frustration. Even if you put
it in bold geezer font you will always have users who just forget, or
get confused and don't do it. The better way is to create software
that takes care of these things and gives the user a better experience.
Regards,
Gerry
12:43 p.m.
On Fri, 2009-03-20 at 18:50 -0400, Gerry Reno wrote:
Jesse Keating wrote:
> On Fri, 2009-03-20 at 14:48 -0400, Gerry Reno wrote:
>
> > My perspective is from the user point of view. If the user is
> > upgrading to a new release let's say and the process goes along for
> > quite a while and then decides to bomb out because the rpm version
> > needed to be newer then the user becomes confused. The software should
> > take care of this. So if any package in the whole update requires a
> > newer yum/rpm then I think yum should go do that first.
> >
>
> Upgrading to a new release is precisely when this will fail. The "new
> yum" and "new rpm" would require all the other new packages in order
to
> be functional. There is no way to use the new yum without the rest of
> the new stuff.
>
>
This then says to me that packagers ought to be completely static and
not dependent on anything, so that we can actually perform an upgrade
on them first and then upgrade everything else. Or alternatively, we
load a static version to complete the upgrade and then update to the
shared version.
To require that the user remember to perform certain preupgrade
procedures is just asking for lots of user frustration. Even if you
put it in bold geezer font you will always have users who just forget,
or get confused and don't do it.
You're getting confused. These tricks are only required if you're going
to try to run a 'yum upgrade' on a running system to upgrade between
major releases. It's complex, hard to document, error-prone, and doesn't
handle a lot of the special cases that anaconda does.
Running preupgrade requires *none* of these special preparations. It
downloads install images and *only* the packages you need, and then it
boots into the installer. The installer already *has* the newer
kernel/yum/rpm/etc. You don't need to worry about any of these things
with preupgrade.
The better way is to create software that takes care of these things
and gives the user a better experience.
We did. It's preupgrade. Give it a try!
-w
5565
days inactive
5567
days old
21 comments
11 participants
participants (11)
-
Adam Miller -
Adam Williamson -
Gerry Reno -
Gianluca Sforna -
Jeremy Katz -
Jesse Keating -
John5342 -
M A Young -
Paul W. Frields -
Seth Vidal -
Will Woods