* Benji Weber <[EMAIL PROTECTED]> [Jul 02. 2007 22:51]:
> 
> There are also other things to be decided, like how to resolve package
> vendor "bouncing" where the user has e.g. guru & kde-backports
> repositories subscribed and the updater first updates to one then the
> other version of amarok, gaining and losing the additional
> functionality.

Actually, thats the biggest problem when 'blindly' updating all packages.

> 
> Zen-updater's upgrade-all policy was fairly broken and no thought
> given to these kind of issues, (even had problems with multilib) it
> would be good to avoid that where possible.

Remember that zen-updater was designed with a ZLM (zenwork linux mgmt)
server in mind. The server always shows the client a 'perfect' world and
installing all upgrades is the right approach in this environment.
However, this fails when deployed in a more 'hostile' environment with
lots of 3rd party repositories.

> 
> It may be we need 3 policies:
> 
> - Updates only (as default now)
> - Updates and version upgrades from same vendor as installed package
> (e.g. if you install xine from packman you will get upgrades always
> from packman, but not from an alternative vendor, fixes the bouncing
> problem)
> - Upgrades from all vendors indiscriminately - like smart upgrade etc.
> (For people who have the knowledge to fix their system if the package
> manager does something stupid.)

There might be even another approach - updating by repository.

Looking at a typical system, one usually has
- the installation repository (i.e. openSuSE 10.2)
- the update repository (for openSuSE 10.2)
- one or more add-on repositories (packman, guru, ...)

Under the assumption that each repository by itself is consistent,
one should be able to 'update all' on a per-repository basis.

The default would be "update everything", starting with the updates
for openSuSE 10.2 first, then the other add-ons.
One could also restrict updates to a specific repo only. So if you
have e.g. KDE4 subscribed, you should be able to update only packages
coming from the KDE4 repo.

This basically introduces priorities on repositories, with the update
repo of the installed OS at the highest prio.


Probably a project for the next hack-week ... ;-)

Klaus
---
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to