No FC2 updates anymore in all repo's?

[Ralf Corsepius]

On Fri, 2005-05-27 at 15:45 -0500, Jeff Vian wrote:
> On Fri, 2005-05-27 at 15:57 +0200, Ralf Corsepius wrote:
> > On Fri, 2005-05-27 at 19:15 +0530, Rahul Sundaram wrote:
> > > Ralf Corsepius wrote:
> > > 
> > > >On Fri, 2005-05-27 at 14:15 +0100, Paul Howarth wrote:
> > > >
> > > >  
> > > >
> > > >>RedHat Linux distributions have always been designed to be upgradeable; 
> > > >>right from the outset the RPM package manager had as one of its design 
> > > >>goals the ability to easily upgrade everything. The "official" way of 
> > > >>upgrading though is to use the anaconda installer on the CDs/DVD to do 
> > > >>the upgrade. This is the way least likely to result in problems. 
> > > >>Upgrading via yum/apt may also work, yum will not work without major effort.
> > > >> but YMMV; anaconda is coded with 
> > > >>knowledge of things that need to be done (e.g. on FC4 it will remove the 
> > > >>i386 version of perl on x86_64 installs), information that isn't 
> > > >>available to yum or apt.
> > > >>    
> > > >>
> > > >Well, that's what I call broked design.
> > > >
> > > >Ralf
> > > >  
> > > >
> > > I would be very interested in your solution to fix this particular issue 
> > > any other way
> > It's beyond my knowledge on this particular issue (IIRC, FC3 shipped
> > i386 perl packages, while FC4 is going to be shipped with x86_64
> > packages). Esp. I don't know x86_64's rpm/yum/apt are handling mixed
> > architecture installations.
> > 
> > Anyway, for rpm, apt, yum and similar tools to work correctly, all such
> > kind of information must be encoded into rpms. Therefore using anaconda
> > to achieve an architecture switch for certain packages is a hack and
> > violates rpm, yum, apt etc. working principles.
> > 
> 
> Please explain that.
Quite simple: The origin is rpm (the program) and rpmlib. 
Rpm assumes all packaging information to be encoded into rpms.

Therefore, all operations yum and apt perform are based on
a) user input
b) information contained inside of rpms.
c) rpm/rpmlib's internal operations.

Neither yum nor apt have any knowledge about anaconda (RH), yast (SuSE),
nor what ever meta installation files a system might be using.

>   Anaconda is a different tool (distribution
> installer) than yum, apt, rpm (package updater/installer).
IMO, this is very arguable. 

Either anaconda is an alternative installer, then this issue boils down
to an inconsistency between anaconda, yum and apt's behavior, being
caused by anaconda using additional sources of information than yum/apt.
In this case yum, apt, up2date probably better should be discontinued
and be merged into anaconda. This is similar to the way SuSE went with
their proprietary YOU.

Or, anaconda is a "wrapper around rpm" being used for cludges which are
not easy to deal with by rpm/rpmlib. In this case yum, apt etc. should
be built on top of anaconda instead of rpm.

Or, anaconda is an "interactive GUI installer"/"first time installer",
then anaconda should be using the same tools/sources underneath as the
non-interactive installers (yum/apt) do. In this case, anaconda must not
use other sources than yum/apt, i.e. the information inside of the rpms.
If wanting to drive this to extremes, anaconda then would reduce to a
GUI to yum/apt.

>  I don't see
> that as a hack at all.  The change occurs with anaconda during
> installation and not on a daily basis.
The points are:

* yum, apt and rpm alone do not use the additional information anaconda
uses and do not have any possibility to get this information.

* If using yum, apt or rpm alone to manage package installations,
anaconda is completely superfluous and irrelevant. People using them do
not have anaconda installed and do not use it.

Ralf