One option smart needs to conquer the world

[Eli Wapniarski]

> On Wed, 22 Feb 2006, Gustavo Niemeyer wrote:
> > > > Modifying a schema upgrade on package upgrade is what is wrong
> > > > (imho).
> > >
> > > I agree in the general case. But, our package is not for public
> > > consumption.  Smart's dowgrade feature has never caused us a problem,
> > > but we have safe guards in place, always due testing and don't
> > > automate the upgrades.
> >
> > That's precisely what I think.  Distribution packagers shouldn't be
> > worried about Smart downgrading things, they should be worried about
> > packaging software correctly, in a way that will never make Smart
> > downgrade a single package.
>
> Exactly. In case this happens I'm sure a packager would be thrilled to
> know the conditions. Maybe we could have a feedback mechanisme to inform
> the involved packagers ? :)
>

This works, only if a user is using a relatively few number of channel 
sources. That is the user is only upgrading what a distro is providing as 
upgrade. In the Fedora Core world, this might be the case for a newbie that 
is unaware that multiple channel sources exist.

In the Fedora Core world 3rd party channels do not live in a vacuum. At least, 
speaking for myself, I would need to rely on at least 10 seperate channels in 
4 sources. Once a user becomes aware of the 3rd party channels there's really 
no turning back because, suddenly, features get switched on. The ability to 
play mp3 files is one simple expample of a feature one will never find Fedora 
Core / Redhat distributions. However, when going to 3rd parties, suddenly a 
use can do what the rest of the world takes for granted; play an mp3.

One of the things that one will find with a little exploration that many 3rd 
parties package the exact same version of the exact same package. The only 
difference being the build number. Some are higher others are lower. Which 
one is the right one for my environment. Some examples of this would be 
aspell, automake etc.

Then there's the situation where updates get released and all the third 
parties release the update. Today channel 1 gets the update and the package 
is upgraded. Tomorrow, channel 2 provides the update with a higher build 
number and upgrades, but, this package is dependant on "libpackagte" rather 
than "package" and so removes "package" and installs "libpackage." 
Unfortuneately "foo" is dependant on "package" not "libpackage" and so "foo" 
gets removed. I have to reboot the system and low and behold kernel panic.

For Fedora Core users, Smart badly needs an effective mechanism to allow a 
user to favor a channel over and to the exclusion of another in a 
hierarchical fashion. Even if that means downgrading packages as specified by 
a users preference.

Eli