[opensuse-factory] Locking packages ...

older
[opensuse-factory] RFC: Topics for...

Klaus Kaempf

17 Apr 2007 17 Apr '07

12:56

Hi, bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager. This mail should be a kickoff to define a common understanding and concept for package locks. Package locks try to provide a solution for the following use-cases 1. Distribution upgrade with 3rd party packages Desktop user Joe has purchased a full featured version of the FooBar application from vendor ACME for openSUSE 10.2 The new openSUSE 10.3 distribution contains a free version of FooBar, based on open source, built in autobuild with vendor 'openSUSE', with limited functionality. Upgrade of the distribution replaces the full featured version with the limited one. 2. Maintenance upgrade of 3rd party packages Multimedia junkie Susan likes to listen to mp3 encoded music files and regularly watches DVD movies on her laptop. Because of license issues, she installed mplayer from a 3rd party repository, including a full set of patented codec implementations. The openSUSE project provides a maintenance update for mplayer, fixing a critical security bug. This update replaces the installed mplayer, resulting in a version with limited functionality. The current solution to the above scenarious is to group packages based on their vendor attribute. Packages from unknown vendors are auto-protected in order to prevent unwanted replacements. This is a very effective but also very limited solution. Proposals anyone ? Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Show replies by date

Henne Vogelsang

17 Apr 17 Apr

13:03

Hi, On Tuesday, April 17, 2007 at 14:56:30, Klaus Kaempf wrote:

...

bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager.

Proposals anyone ?

Simple. Get rid of that alltogether. $VENDOR has to take care of that. Most of them do already. Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Klaus Kaempf

13:17

* Henne Vogelsang [Apr 17. 2007 15:07]:

...

Hi,

On Tuesday, April 17, 2007 at 14:56:30, Klaus Kaempf wrote:

...
bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager.

Proposals anyone ?

Simple. Get rid of that alltogether. $VENDOR has to take care of that. Most of them do already.

Can you detail on how this proposal relates to the mentioned use-cases ? Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Henne Vogelsang

14:01

Hi, On Tuesday, April 17, 2007 at 15:17:02, Klaus Kaempf wrote:

...

* Henne Vogelsang [Apr 17. 2007 15:07]:

...
On Tuesday, April 17, 2007 at 14:56:30, Klaus Kaempf wrote:

...
bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager.

Proposals anyone ?

Simple. Get rid of that alltogether. $VENDOR has to take care of that. Most of them do already.

Can you detail on how this proposal relates to the mentioned use-cases ?

The first usecase is not really a realworld usecase because updates usualy dont include extra repos (if they would it would be no other usecase then the second). So with or without the lock you run into manual intervention. For the maintenance case either you, as third party vendor, decide that you want to use the openSUSE updates (only increment %release by .0) even if they dont provide the same functionality or you prevent the updates from ever beeing newer (increment %release by 1). Most even use some extra chars in %release which is very stupid because it follows no scheme you could catch in a version comparison, but nevertheless this is the kind of the standard (for other reasons than version comparison too e.g. easily identify packages from the 3rd party repo.) All 3rd party repos i am aware of already do that because they support more package-managers than the yast one. And most of them strictly work on basis of rpmvercomp. Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Herbert Graeber

21:13

Am Dienstag, 17. April 2007 schrieb Henne Vogelsang:

...

On Tuesday, April 17, 2007 at 15:17:02, Klaus Kaempf wrote:

...
* Henne Vogelsang [Apr 17. 2007 15:07]:

...
On Tuesday, April 17, 2007 at 14:56:30, Klaus Kaempf wrote:

...
bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager.

Proposals anyone ?

Simple. Get rid of that alltogether. $VENDOR has to take care of that. Most of them do already.

Can you detail on how this proposal relates to the mentioned use-cases ?

The first usecase is not really a realworld usecase because updates usualy dont include extra repos (if they would it would be no other usecase then the second). So with or without the lock you run into manual intervention.

For the maintenance case either you, as third party vendor, decide that you want to use the openSUSE updates (only increment %release by .0) even if they dont provide the same functionality or you prevent the updates from ever beeing newer (increment %release by 1). Most even use some extra chars in %release which is very stupid because it follows no scheme you could catch in a version comparison, but nevertheless this is the kind of the standard (for other reasons than version comparison too e.g. easily identify packages from the 3rd party repo.)

All 3rd party repos i am aware of already do that because they support more package-managers than the yast one. And most of them strictly work on basis of rpmvercomp.

But sometimes it would be nice to have some form of locking. For example, at the moment using KDE:Backprots and Packman togehter does'nt work if you are using digikam. It is likely in such cases if you can restrict the installation of digikam and some of the libraries it depends on to one of both repositories (I know no reason, why packman should provide digikam at all, but that's another story). Some time ago the same problem existed with k3b, which is now resolved by following the KDE:Backports release of k3b more closely. There is no need for locking, if all repositories are perfectly maintained, but thst's not reality. Locking would allow to work around such problems without manaual intervention on each package update. Cheers Herbert --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Martin Schlander

21:31

Den Tuesday 17 April 2007 23:13:12 skrev Herbert Graeber:

...

But sometimes it would be nice to have some form of locking. For example, at the moment using KDE:Backprots and Packman togehter does'nt work if you are using digikam.

Noone wants to remove the functionality completely. Only the automatic locking with no user interaction is being discussed. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Pascal Bleser

18 Apr 18 Apr

06:50

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Henne Vogelsang wrote:

...

On Tuesday, April 17, 2007 at 15:17:02, Klaus Kaempf wrote:

...
* Henne Vogelsang [Apr 17. 2007 15:07]:

...
On Tuesday, April 17, 2007 at 14:56:30, Klaus Kaempf wrote:

...
bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager.

Proposals anyone ? Simple. Get rid of that alltogether. $VENDOR has to take care of that. Most of them do already.

...

...
Can you detail on how this proposal relates to the mentioned use-cases ?

The first usecase is not really a realworld usecase because updates usualy dont include extra repos (if they would it would be no other usecase then the second). So with or without the lock you run into manual intervention.

Right. That use case is more for a production server or an enterprise desktop and such. And there, you wouldn't add 3rd party repositories in the first place.

...

For the maintenance case either you, as third party vendor, decide that you want to use the openSUSE updates (only increment %release by .0) even if they dont provide the same functionality or you prevent the updates from ever beeing newer (increment %release by 1). [...]

...

All 3rd party repos i am aware of already do that because they support more package-managers than the yast one. And most of them strictly work on basis of rpmvercomp.

Exactly. smart, yum, apt don't have such an automatic locking scheme (smart does have explicit locks though, even based on expressions, such as "smart flag --set lock 'foobar <= 1.0.1'", and they work on installed and non-installed packages) so as packagers, we have to take care it works properly anyhow, without the black magic of automatic locks. At the very least, one should be able to turn it off in YaST2 and IMHO it should be turned off by default in openSUSE (maybe turn it on by default in SLE*). cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFGJb/Tr3NMWliFcXcRAsXOAJ4n1TqmAQfmvWsPm5bt5A7lC+1MtACfUwdj nxEpgxRz/AnPiiCkAF0c0nE= =pOAO -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Martin Schlander

17 Apr 17 Apr

13:44

Den Tuesday 17 April 2007 14:56:30 skrev Klaus Kaempf:

...

Package locks try to provide a solution for the following use-cases

Proposals anyone ?

First of all I think these benefits are far outweighed by the problems the locks cause. So in my view the auto-locking could be just removed. Worst case a few people lose some functionaly temporarily. They would always be able to downgrade again if they have issues. And after trying that a couple of times they'll hopefully learn to pay attention to what they upgrade. But of course it's a valid point. For example you install Pascal's nice ktorrent package - and if you don't pay attention when updating you might get the crippled one from OBS with no DHT. Don't know if this could be taken care of with some versioning conventions, that could perhaps ensure that 3rd party packages are always considered "newer". One thing that could possibly diminish the problems that having no locks could cause, and at the same time solve a different issue, would be if it was somehow made more apparent in sw_single when more versions of a package are available. In the present state the user has to actively go to the "versions" tab and check. In the Smart-gui all packages are listed as individual packages even if they're different versions of the same package. Maybe sw_single could be made to behave in a way that's a kind of compromise between the two "radical" approaches. Maybe the list could have some kind of tree-format, like with folders - and a little [+] showing that there are actually more versions of this package avaialable. Maybe it should only be done in case there are packages available from different "vendors" - otherwise it could become messy on x86_64 (biarch) systems. Hopefully if people are informed that more versions are available they'll think twice about which they update to. Another issue is that if you update using sw_single -> "Package" -> "All packages" -> "Update if newer version is available" the locks are disregarded anyway. So in the ktorrent example you are very likely to have your guru-package replaced with the OBS-package despite the lock. If there were no locks at all, this way of updating could assume the user actively locked locked packages, and therefore respect the locks. The way it is now, whether Pascals package is locked or not, it will be updated if I use this method of updating. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Christian Boltz

23:43

Hello, on Dienstag, 17. April 2007, Klaus Kaempf wrote:

...

bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager. [...] The current solution to the above scenarious is to group packages based on their vendor attribute.

Can you tell us some details? My impression always was that non-SUSE packages are always locked. Or did I miss some details?

...

Packages from unknown vendors are auto-protected in order to prevent unwanted replacements.

This is a very effective but also very limited solution.

Proposals anyone ?

IMHO, it's impossible to solve the usecases you posted automatically. Therefore, I'd like to have a dialog like Package updates - change vendor? You have installed package foo from $VENDOR, but there's a newer version available from $OTHER_VENDOR. What do you want to do? [Install package from $OTHER_VENDOR] [keep package from $VENDOR] [x] remember decicion for this package [x] remember decicion for vendor $VENDOR [x] remember decicion for all vendors So you would have the best of every solution: - no automatic cross-vendor that could remove some features - no package locks, "normal" dependency solving is possible - the user knows what's going on - seems to be really important because both the "lock all" and "lock none" method seem to imply that the user is surprised[tm] sooner or later Yes, it's another dialog to answer - but it's better than any automatic decision nobody really likes. Regards, Christian Boltz -- * Linux Viruscan..... Windows 95 found. Remove it? (y/n) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Rajko M.

18 Apr 18 Apr

03:18

On Tuesday 17 April 2007 18:43, Christian Boltz wrote:

...

Package updates - change vendor?

You have installed package foo from $VENDOR, but there's a newer version available from $OTHER_VENDOR. What do you want to do?

[Install package from $OTHER_VENDOR] [Install package from $VENDOR] [keep package from $VENDOR]

[x] remember decicion for this package [x] remember decicion for vendor $VENDOR [x] remember decicion for all vendors

This would be clear for most users. The other useful feature would be to have list of remembered status, to be able to revert decision by removing package fro the list. -- Regards, Rajko. http://en.opensuse.org/Portal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Karl Eichwalder

08:08

Klaus Kaempf writes:

...

bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager.

[...]

...

Proposals anyone ?

I still believe third parties (all of them) must learn not to touch the /usr, /var, etc. hierarchies. This includes the RPM database. That's probably a long term goal. For the time being, by default our tools should not update packages if the vendors are different. We must ask the user first or offer --force switches to command line tools. We also should ask whether some kind of update or a uninstall/install procedure is wanted. -- Karl Eichwalder R&D / Documentation SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Duncan Mac-Vicar P.

08:25

On Tuesday 17 April 2007 02:56:30 pm Klaus Kaempf wrote:

...

Hi,

bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager.

my proposal: - get rid of everything we have now. - don't allow automatic (only user transacted) inter-vendor upgrades (solves usecase 2) For the future: - implement a simple text list with package patterns that gets read from /etc. The challenge here is that it breaks the current UI lock concept (one package can be locked by more than one pattern). Duncan --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Henne Vogelsang

09:23

Hi, On Wednesday, April 18, 2007 at 10:25:36, Duncan Mac-Vicar P. wrote:

...

On Tuesday 17 April 2007 02:56:30 pm Klaus Kaempf wrote:

...
bug 264685 (Get rid of package locks in package manager) asks for reasoning of and better concepts for locking packages in the package manager.

my proposal:

- get rid of everything we have now. - don't allow automatic (only user transacted) inter-vendor upgrades (solves usecase 2)

Can you specify "inter-vendor upgrades" please? Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Duncan Mac-Vicar P.

22:18

On Wednesday 18 April 2007 11:23:12 am Henne Vogelsang wrote:

...

Can you specify "inter-vendor upgrades" please?

If you have MPlayer with vendor "Foo" the solver don't select Mplayer vendor "Bar" as a upgrade candidate even if it is newer unless it is a user explicit transaction Duncan --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Henne Vogelsang

19 Apr 19 Apr

09:33

Hi, On Thursday, April 19, 2007 at 00:18:56, Duncan Mac-Vicar P. wrote:

...

On Wednesday 18 April 2007 11:23:12 am Henne Vogelsang wrote:

...
Can you specify "inter-vendor upgrades" please?

If you have MPlayer with vendor "Foo" the solver don't select Mplayer vendor "Bar" as a upgrade candidate even if it is newer unless it is a user explicit transaction

Is that not the same as we have now? Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Duncan Mac-Vicar Prett

20 Apr 20 Apr

10:00

On Thursday 19 April 2007 11:33:42 Henne Vogelsang wrote:

...

Is that not the same as we have now? Henne

No, now packages from other vendors are locked. Nothing should be locked unless the user locks it. I am just saying the solver should not take a update from a _different_ vendor (different from what you have right now, not != SUSE) in consideration (unless the user explicitly do it) , that does not mean you lock it. For example, right now if you install MPlayer from packman, mplayer gets locked, because vendor != "SUSE", and wont be changed even if there is an updated from the same packman! -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Martin Schlander

10:15

Den Friday 20 April 2007 12:00:25 skrev Duncan Mac-Vicar Prett:

...

On Thursday 19 April 2007 11:33:42 Henne Vogelsang wrote:

...
Is that not the same as we have now? Henne

No, now packages from other vendors are locked. Nothing should be locked unless the user locks it.

I am just saying the solver should not take a update from a _different_ vendor (different from what you have right now, not != SUSE) in consideration (unless the user explicitly do it) , that does not mean you lock it.

For example, right now if you install MPlayer from packman, mplayer gets locked, because vendor != "SUSE", and wont be changed even if there is an updated from the same packman!

I like this suggestion a lot. Especially if combined with an obvious way of showing that versions from more than one vendor are available - without requiring the user to actively go to "Versions" to check. Be that an '*', a [+] or whatever. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Henne Vogelsang

11:13

Hi, On Friday, April 20, 2007 at 12:00:25, Duncan Mac-Vicar Prett wrote:

...

On Thursday 19 April 2007 11:33:42 Henne Vogelsang wrote:

...
Is that not the same as we have now?

No, now packages from other vendors are locked. Nothing should be locked unless the user locks it.

I am just saying the solver should not take a update from a _different_ vendor (different from what you have right now, not != SUSE) in consideration (unless the user explicitly do it) , that does not mean you lock it.

I see and i dont like it. Because that would mean that you never get anything updated from a 3rd party repo because there the vendor will always be != <what you have now a.k.a. SUSE after a install> Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Benji Weber

12:24

On 4/20/07, Henne Vogelsang wrote:

...

Hi,

On Friday, April 20, 2007 at 12:00:25, Duncan Mac-Vicar Prett wrote:

...
On Thursday 19 April 2007 11:33:42 Henne Vogelsang wrote:

...
Is that not the same as we have now?

No, now packages from other vendors are locked. Nothing should be locked unless the user locks it.

I am just saying the solver should not take a update from a _different_ vendor (different from what you have right now, not != SUSE) in consideration (unless the user explicitly do it) , that does not mean you lock it.

I like the suggestion a lot. The user will specifically want to install the packman versions of crippled packages, but won't want build service re-cripped newer versions to override them. Also it would help discourage upgrade all mentality which would replace all suse supported packages with the newer unsupported versions on packman when the user doesn't require the newer version.

...

I see and i dont like it. Because that would mean that you never get anything updated from a 3rd party repo because there the vendor will always be !=

User would still be able to request upgrade to a different vendor, but automatic upgrades to different vendor are more likely to cause problems than be useful imo. _ Benjamin Weber --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Henne Vogelsang

12:42

Hi, On Friday, April 20, 2007 at 13:24:53, Benji Weber wrote:

...

On 4/20/07, Henne Vogelsang wrote:

...
On Friday, April 20, 2007 at 12:00:25, Duncan Mac-Vicar Prett wrote:

...
On Thursday 19 April 2007 11:33:42 Henne Vogelsang wrote:

...
Is that not the same as we have now?

No, now packages from other vendors are locked. Nothing should be locked unless the user locks it.

I am just saying the solver should not take a update from a _different_ vendor (different from what you have right now, not != SUSE) in consideration (unless the user explicitly do it) , that does not mean you lock it.

I like the suggestion a lot. The user will specifically want to install the packman versions of crippled packages, but won't want build service re-cripped newer versions to override them.

This is is such a special usecase that you will only be able to solve this, without user knowledge, if you can mark repos as leading, authorative or whatever. I dont think you can (and should) solve these usecases on a package level.

...

Also it would help discourage upgrade all mentality which would replace all suse supported packages with the newer unsupported versions on packman when the user doesn't require the newer version.

The user specifically requested newer unsupported packages by adding the 3rd party repo. Why would the package manager hold back those packages and install them only on request?

...

...
I see and i dont like it. Because that would mean that you never get anything updated from a 3rd party repo because there the vendor will always be !=
User would still be able to request upgrade to a different vendor, but automatic upgrades to different vendor are more likely to cause problems than be useful imo.

Automatic inter-vendor updates are what people expect to happen. Its what we currently do not deliver with yast but with all other package managers. There it works fine since ages. Why would we prohibit it (again)? Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Alberto Passalacqua

12:51

...

The user specifically requested newer unsupported packages by adding

Il giorno ven, 20/04/2007 alle 14.42 +0200, Henne Vogelsang ha scritto: the

...

3rd party repo. Why would the package manager hold back those packages and install them only on request?

In general, users add packman and other repositories to enable features not available in the default packages provided by SUSE. This doesn't mean that all more recent packages from packman have to be installed to replace the default ones. The decision should be left to the user and not by the package manager, because upgrading all default packages with 3rd party ones automatically might bring to a messed up system. Regards, Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

M9.

15:14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alberto Passalacqua schreef:

...

Il giorno ven, 20/04/2007 alle 14.42 +0200, Henne Vogelsang ha scritto:

...
The user specifically requested newer unsupported packages by adding the 3rd party repo. Why would the package manager hold back those packages and install them only on request?

In general, users add packman and other repositories to enable features not available in the default packages provided by SUSE. This doesn't mean that all more recent packages from packman have to be installed to replace the default ones. The decision should be left to the user and not by the package manager, because upgrading all default packages with 3rd party ones automatically might bring to a messed up system.

Here i agree, it happened to me on 100, which became useless,(had to reinstall, choose 101),on 101, which became instable, but still worked, and also on 102. the retailversion, which took about 3 hours to upgrade a few pkgs, and all kind of mysterious happenings flew over the screen and got me realy worried,(it costs a day to get everything back to normal after wrekking an OS..) and when it was done, I thought: this is the last time like this!, but after finishing, the system was and still is stable as a house....( but i still do not know what realy happened there...a feeling i personaly don't like at all..) I am carefull now with other pkgs except the ones I realy need: Samba,(a story on its own..) libxine, w32codec-all.. Only factory upgrades? No problem at all...

...

Regards, Alberto

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

- -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.2-34-default x86_64 Huidige gebruiker: monkey9@tribal-sfn2 Systeem: openSUSE 10.2 (X86-64) KDE: 3.5.5 "release 45.2" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGKNjqX5/X5X6LpDgRAo+XAKCNn3YZ+uj4/6nMfNphGEvaocZHhQCeIibT JyRZFxOwLOo1FQtrBaSaVsk= =tuQb -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

M9.

15:33

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M9. schreef:

...

Alberto Passalacqua schreef:

...
Il giorno ven, 20/04/2007 alle 14.42 +0200, Henne Vogelsang ha scritto:

...
...
The user specifically requested newer unsupported packages by adding the 3rd party repo. Why would the package manager hold back those packages and install them only on request? In general, users add packman and other repositories to enable features not available in the default packages provided by SUSE. This doesn't mean that all more recent packages from packman have to be installed to replace the default ones. The decision should be left to the user and not by the package manager, because upgrading all default packages with 3rd party ones automatically might bring to a messed up system.

I am carefull now with other pkgs except the ones I realy need: Samba,(a story on its own..) libxine, w32codec-all..

..forgot libdvdcss, i allways have a tar lying around to compile....

...

Only factory upgrades? No problem at all...

...
Regards, Alberto

...
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org - -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.2-34-default x86_64 Huidige gebruiker: monkey9@tribal-sfn2 Systeem: openSUSE 10.2 (X86-64) KDE: 3.5.5 "release 45.2" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGKN1fX5/X5X6LpDgRAryVAJ90G6SlnPfQcF7fr1Fasz8tKlNYqgCgwJ5z hDllIDUtM21LVcL4A8eQwVQ= =Kdax -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Martin Schlander

13:06

Den Friday 20 April 2007 14:42:42 skrev Henne Vogelsang:

...

...
I like the suggestion a lot. The user will specifically want to install the packman versions of crippled packages, but won't want build service re-cripped newer versions to override them.

This is is such a special usecase that you will only be able to solve this, without user knowledge, if you can mark repos as leading, authorative or whatever. I dont think you can (and should) solve these usecases on a package level.

I think this is a quite common usecase actually. Many users will have KDE-backports, Packman and Guru and many packages exist on two out of the three repos. And if you're not paying attention you'll be playing 'ping-pong' as so elegantly put by Duncan. Amarok (most people will want Guru, BS version is crippled wrt. database support I believe) Ktorrent (most people will want Guru, BS-version crippled wrt. DHT) Digikam (most people will want the backported version cuz the packman version causes problems with some libs) K3b (sometimes packman has had development builds, which not all will want) Alsa (if your sounds working nicely why would you want to do a risky upgrade automatically for something like that). To name a few very popular packages where I'm aware of problems (presently or in the past). I wonder, do kde-backports and kde-playground have same vendor? If not this behaviour would also make it possible to have kde-playground enabled for certain packages, without constantly having to be alert as to whether you're updating to something alphaish. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Dominique Leuenberger

13:12

...

...
...
On 20-04-2007 at 16:06, Martin Schlander wrote: I wonder, do kde-backports and kde-playground have same vendor? If not this behaviour would also make it possible to have kde-playground enabled for certain packages, without constantly having to be alert as to whether you're

I think the whole thing is going in the right direction now: have upgrades happen only withing the same vendor. This would allow me to add packman again as a source (hmm. just wonder: do I need it? anyhow I can just copy thge required RPMs down). But this gives a new 'problem' for the BS repos: as far as I know, they're all by the same vendor. Maybe the repo name should be added there, so that 'inter-repo-updates' (so from one repo to another' don't happen. Example: I have GNOME:UNSTABLE in my source list. out of GNOME:UNSTABLE I link some to my home repo, with some patches. Both are in my source list. I most likely will want to keep the packages from where I installed them until further configuration. A notice, that another subscribed repo provides a newer version could thus be interesting... but that's another story. Dominique -- TMF is a global management and accounting outsourcing firm with 72 offices in 56 countries and over 2,000 professionals (February 2007). TMF is expanding rapidly throughout the world. Learn more about our unique network and our services and visit our website at www.tmf-group.com. The information contained in this e-mail communication is confidential and solely intended for the person to whom it is addressed. If someone other than the intended recipient should receive or come into possession of this e-mail communication, he/she will not be entitled to read, disseminate, disclose or duplicate it. If you are not the intended recipient, you are requested to notify the sender and to destroy the original e-mail communication. TMF is neither liable for the correct and complete transmission of the information contained in this e-mail communication nor for any delay in its receipt. This footnote also confirms that this email message has been checked for the presence of computer viruses. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Henne Vogelsang

13:14

Hi, On Friday, April 20, 2007 at 15:06:34, Martin Schlander wrote:

...

Den Friday 20 April 2007 14:42:42 skrev Henne Vogelsang:

...
...
I like the suggestion a lot. The user will specifically want to install the packman versions of crippled packages, but won't want build service re-cripped newer versions to override them.

This is is such a special usecase that you will only be able to solve this, without user knowledge, if you can mark repos as leading, authorative or whatever. I dont think you can (and should) solve these usecases on a package level.

I think this is a quite common usecase actually.

Many users will have KDE-backports, Packman and Guru and many packages exist on two out of the three repos. And if you're not paying attention you'll be playing 'ping-pong' as so elegantly put by Duncan.

Amarok (most people will want Guru, BS version is crippled wrt. database support I believe)

[...]

And you should decide these on a package basis (setting something to taboo if you definately dont want it). This however should have nothing to do with the general policy. Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

M9.

15:18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Schlander schreef:

...

Den Friday 20 April 2007 14:42:42 skrev Henne Vogelsang:

...
...
I like the suggestion a lot. The user will specifically want to install the packman versions of crippled packages, but won't want build service re-cripped newer versions to override them. This is is such a special usecase that you will only be able to solve this, without user knowledge, if you can mark repos as leading, authorative or whatever. I dont think you can (and should) solve these usecases on a package level.

I think this is a quite common usecase actually.

Many users will have KDE-backports, Packman and Guru and many packages exist on two out of the three repos. And if you're not paying attention you'll be playing 'ping-pong' as so elegantly put by Duncan.

Amarok (most people will want Guru, BS version is crippled wrt. database support I believe)

This is correct..

...

Ktorrent (most people will want Guru, BS-version crippled wrt. DHT)

Digikam (most people will want the backported version cuz the packman version causes problems with some libs)

K3b (sometimes packman has had development builds, which not all will want)

Alsa (if your sounds working nicely why would you want to do a risky upgrade automatically for something like that).

Agree..

...

To name a few very popular packages where I'm aware of problems (presently or in the past).

Yes...

...

I wonder, do kde-backports and kde-playground have same vendor? If not this behaviour would also make it possible to have kde-playground enabled for certain packages, without constantly having to be alert as to whether you're updating to something alphaish.

You hit the nail on the head....

...

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

- -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.2-34-default x86_64 Huidige gebruiker: monkey9@tribal-sfn2 Systeem: openSUSE 10.2 (X86-64) KDE: 3.5.5 "release 45.2" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGKNnQX5/X5X6LpDgRAscaAJ4pV2ArqjT9j27Lf862sthlrD58bACgjmee 4e2eW13aSduu9cXHVvoLGFc= =h5Gz -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Duncan Mac-Vicar Prett

15:56

Exactly, so for crippled packages, you want to switch vendor, and keep upgrading from the same vendor. If you lock them like now, you dont get upgrades If you allow inter vendor upgrades, if a crppled version from another vendor has a newer version, it will be replaced. I think my proposal of - no automatic inter-vendor upgrades, only explicit - only explicit user locks (rules) is much more simple and consistant. -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Druid

17:26

...

I think my proposal of - no automatic inter-vendor upgrades, only explicit - only explicit user locks (rules)

is much more simple and consistant.

Its better, a little bit saner. I would prefer not to upgrade by default. You dont need to upgrade either when there is a new version of a package in packman either. Specialy when there are some cvs builds, experimental stuff, that can break easily. And as people said, just because you want codecs, doesnt mean you want to install alsa and lots of other core packages available in packman for some reason. Henne´s proposal will increase upgraditis. We dont need that. Its enough clueless people breaking their sytems with xgl, compiz and beryl. Marcio --- druid --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

M9.

19:03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Druid schreef:

...

...
I think my proposal of - no automatic inter-vendor upgrades, only explicit - only explicit user locks (rules)

is much more simple and consistant.

Its better, a little bit saner. I would prefer not to upgrade by default.

You dont need to upgrade either when there is a new version of a package in packman either. Specialy when there are some cvs builds, experimental stuff, that can break easily. And as people said, just because you want codecs, doesnt mean you want to install alsa and lots of other core packages available in packman for some reason.

Henne´s proposal will increase upgraditis. We dont need that. Its enough clueless people breaking their sytems with xgl, compiz and beryl.

This is not realy correct, if a system has to be improved, in this case the way to update/grade, this feature has to be tested vigourously, i would not want to call this behaviour 'upgraditis' ...in this case.. A way has to be found, to upgrade from url, without to have to be afraid to loose a goodworking system... <INTERMEZZO>

...

I guess that everyone has his/her own taste according the look and feel of his/her Desktops.

So am I liking one specific transparent sys-monitor, which comes with caramba: i-cons-sysres.

In the upper-right corner of the screen (you can hang it where-ever you like..)it shows me CPU, RAM and swap load consumption, little things i want to know if the sys slows down.(top open on another desktop to find the cause..) I do not need a dominant gui, just the figures is enough.

But caramba's support stopped somehow, and as KDE loads all apps i have open when i shut down,(very nice feature btw..) it now stopped to load the monitor (and Also Amarok (
As I have all the apps I use getting loaded on start-up, the start-up time is a little longer, but everything should be ready when i come back...

But now corn has to ask everytime for validating the mailserver-certificate, and when i answer 'accept forever', every session this is asked, for 2 mailboxes x 4 buttons to push? These things make me dislike an ap, (might be a bug..), makes me decide to shut it off..(or get an update..if there was one..)

Also, still the time nessesary for reading the metadata is much too long, and that way updating, or installing an app, takes too much time....

(What happened to the clever discussion about this subject some weeks ago?)

(just little annoyances, making the experience a little less fun, that is all..)

I like SuSE very much, installed the 102 32Bits retailversion on a U-Buddy yesterday. (barebone) P4 2.66GHz, 1024MB Ram, 160GB 2,5 " IDE HDD, which has to gonna be my 'car-pc', for in the camper, USB GPS for the 'tomtom' and a 12" touchscreen (second-hand, has to be 'rubberized' open steel version), come to it, doing this all by myself, save me about 600,- euro, minimum. The idea to have lot of music, good movies, and all my apps while traveling makes me feel very 'complete'..

...

Marcio --- druid --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

- -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.8-01-default x86_64 Huidige gebruiker: monkey9@tribal-sfn2 Systeem: openSUSE 10.2 (X86-64) KDE: 3.5.5 "release 45.4" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGKQ6XX5/X5X6LpDgRAhmfAJ4/fJKf9O05zjRulpKK04zEvLnrMgCg3/+b 6x8e2YU0vAOFgBZEndqsicw= =Po9L -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Druid

20:15

...

This is not realy correct, if a system has to be improved, in this case the way to update/grade, this feature has to be tested vigourously, i would not want to call this behaviour 'upgraditis' ...in this case..

You wouldnt call but it is. And who said all repositories contains tested packages?

...

A way has to be found, to upgrade from url, without to have to be afraid to loose a goodworking system...

That of course is a non sense, as it depends on the repository, not on the lock method, package manager, or the user. If you are afraid of losing a good working system, you should isntall waht you want after installation, and never ever touch the package manager again. Thats the way you wont never lose a good working system. In fact, if people did this more often, they would break much much less their installations Marcio --- druid --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Pascal Bleser

21:36

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Druid wrote:

...

...
I think my proposal of - no automatic inter-vendor upgrades, only explicit - only explicit user locks (rules)

is much more simple and consistent.

IMO vendor is the wrong thing to attach this behaviour to. What would actually be needed is *repository* priority or not doing "inter-repository upgrades". Another aspect/solution/idea would be to differentiate the behaviour of YaST2 wrt install/upgrade/remove (sw_single) and "online update". Or, maybe the best solution, but arguably the one that needs the most thought: being able to configure a "profile" for YaST2's behaviour: - - conservative - - always upgrade

...

Its better, a little bit saner. I would prefer not to upgrade by default.

That's your preference. Hence the "profile" option is the nicest way to accommodate (almost) everyone, but probably far from being trivial to implement.

...

You dont need to upgrade either when there is a new version of a package in packman either. Specialy when there are some cvs builds,

Wrong. Packages that are not present in the openSUSE distro or only as crippled versions also have security issues or important bugfixes. You definitely almost always want to upgrade to the latest version.

...

experimental stuff, that can break easily. And as people said, just because you want codecs, doesnt mean you want to install alsa and lots of other core packages available in packman for some reason.

Splitting Packman (and Guru and ...) into "stable" and "experimental" repositories could be an option (but it's not as trivial as it might sound, because of dependencies).

...

Henne´s proposal will increase upgraditis. We dont need that. Its enough clueless people breaking their sytems with xgl, compiz and beryl.

I don't think the behaviour of the package manager has much influence on that. If people want the latest Xgl/compiz/beryl/mplayer/..., they'll install it, whether the package manager makes things a pain in the ass or not (it's just going to be a pain in the ass, like now). cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFGKTJqr3NMWliFcXcRAmtxAKCOI8u+bO42/silPrxLDj0AcctYKQCgqRvf HzD8EMkPMKnxeKc41JPxY/4= =WWPf -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Duncan Mac-Vicar Prett

13:11

On Friday 20 April 2007 14:42:42 Henne Vogelsang wrote:

...

The user specifically requested newer unsupported packages by adding the 3rd party repo. Why would the package manager hold back those packages and install them only on request?

No, especially with the build service, you never know what package will appear there (in a specific repo) you just dont want to use. The packages in a repo are not a "constant" you agree on. Duncan --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Martin Schlander

12:51

Den Friday 20 April 2007 14:24:53 skrev Benji Weber:

...

I like the suggestion a lot. The user will specifically want to install the packman versions of crippled packages, but won't want build service re-cripped newer versions to override them. Also it would help discourage upgrade all mentality which would replace all suse supported packages with the newer unsupported versions on packman when the user doesn't require the newer version.

...
I see and i dont like it. Because that would mean that you never get anything updated from a 3rd party repo because there the vendor will always be !=
User would still be able to request upgrade to a different vendor, but automatic upgrades to different vendor are more likely to cause problems than be useful imo.

I agree. But Henne makes a good point too, and I have no doubt that many, many users will be very unhappy if "upgrade all"-behaviour is made more difficult for them - even if it is for their own good ;-) Many already want it to be even easier than now - for example by opensuseupdater supporting it. Maybe it could be possible to have two options. Only do semi-automatic updates from same vendor (default) and Do semi-automatic upgrade of any package where newer version is avaialable, (break-my-SUSE) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Duncan Mac-Vicar Prett

12:43

On Friday 20 April 2007 13:13:04 Henne Vogelsang wrote:

...

I see and i dont like it. Because that would mean that you never get anything updated from a 3rd party repo because there the vendor will always be != <what you have now a.k.a. SUSE after a install>

Of course not, because the package from a 3er party is seen as a replacement, not as an upgrade. You can always manually (click twice) "upgrade" (or "replace") one vendor to another, and then the semantics are the same, the packages will be automatically updated if newer versions from your new vendor are available. If it does not work like I say, it basically means cou could be playing ping pong across 2 or 3 vendors as newer packages come out, or you do it like now, which sucks. Duncan --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

6223

Age (days ago)

6226

Last active (days ago)

List overview

Download

34 comments

15 participants

participants (15)

Alberto Passalacqua
Benji Weber
Christian Boltz
Dominique Leuenberger
Druid
Duncan Mac-Vicar P.
Duncan Mac-Vicar Prett
Henne Vogelsang
Herbert Graeber
Karl Eichwalder
Klaus Kaempf
M9.
Martin Schlander
Pascal Bleser
Rajko M.