Stephan Kulow wrote:

Am Montag 14 April 2008 schrieb Stanislav Brabec:

...

Hallo.

To provide a solution for branding packages, I need a conflict, where any of foo-branding-myvendor packages conflicts with any of all other packages with name foo-branding-*.

All these packages provide the same files, but the complete list of packages, which will provide it, is not known in time of packaging.

For example: gimp-branding-openSUSE will conflict with gimp-branding-SLED. But both have to conflict with gimp-branding-Flocke, gimp-branding-Flower or gimp-branding-Spring, which may be created by a third party. And each of them has to conflict with each another.

There are two recent ideas: ... Is there any other solution for this problem? make gimp-branding-X require branding-X and then add all known brandings in the conflict list of branding-X. This is the only solution that rpm allows ;(

One could add a list of all Novell brandings, but it would look incredibly ugly: bootsplash-branding-openSUSE: Conflicts: bootsplash-branding-SLES bootsplash-branding-SLE bootsplash-branding-SLED bootsplash-branding-upstream bootsplash-branding-SLERT bootsplash-branding-SLEPOS And we have absolutely no idea, which third party branding packages will be created.

and leave out all other conflicts from gimp-branding-X. The good news: everyone learned something about rpm today ;)

Each of these features makes my packages even more ugly than before. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Klaus Kaempf wrote:

* Stanislav Brabec [Apr 14. 2008 15:19]:

...

One could add a list of all Novell brandings, but it would look incredibly ugly:

bootsplash-branding-openSUSE: Conflicts: bootsplash-branding-SLES bootsplash-branding-SLE bootsplash-branding-SLED bootsplash-branding-upstream bootsplash-branding-SLERT bootsplash-branding-SLEPOS

And we have absolutely no idea, which third party branding packages will be created.

Exactly.

So just do

Provides: bootsplash-branding Conflicts: bootsplash-branding

in each of the above mentioned packages. This will ensure they're all mutually conflicting.

It will cause lot of bug reports, as it will break our packages for rpm:  [Bug 379338] weird package conflict related to kdebase4-workspace-branding https://bugzilla.novell.com/show_bug.cgi?id=379338 -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On Mon, Apr 14, 2008 at 04:04:45PM +0200, Klaus Kaempf wrote:

Ouch ! About time to switch to rpm5 which supposedly gets this right ...

No. Jeff explicitely said that self-conflicting packages are broken and cannot be installed. No hope there... Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On Tue, Apr 15, 2008 at 09:59:44AM +0200, Klaus Kaempf wrote:

* Michael Schroeder [Apr 14. 2008 17:15]:

...

On Mon, Apr 14, 2008 at 04:04:45PM +0200, Klaus Kaempf wrote:

...

Ouch ! About time to switch to rpm5 which supposedly gets this right ...

No. Jeff explicitely said that self-conflicting packages are broken and cannot be installed. No hope there...

Well, then how can this use-case be implemented with rpm dependency semantics ?

You can't. Micha. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Am Dienstag 15 April 2008 schrieb Klaus Kaempf:

(from libredcarpet:rc-queue-item.c) /* Check to see if we conflict with ourself and don't create * an uninstall item for it if we do. This is Debian's way of * saying that one and only one package with this provide may * exist on the system at a time. */

Does sat-solver get this right ? Does it matter to rpm only solutions?

Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Klaus Kaempf escribió:

It does matter to customers using Code10 tools and it might be a valid reason to 'fix' rpm in this regard.

Isn't supporting this "rpm only" upgrade thing an absolute crazy requirement ? -- "Freedom of religion also means freedom **from** religion" - Anonymous Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/

On Wed, Apr 16, 2008 at 07:12:30AM +0200, Stephan Kulow wrote:

Am Dienstag, 15. April 2008 schrieb Cristian Rodríguez:

...

Klaus Kaempf escribió:

...

It does matter to customers using Code10 tools and it might be a valid reason to 'fix' rpm in this regard.

Isn't supporting this "rpm only" upgrade thing an absolute crazy requirement ? Call it "smart support" if you like

But smart will kill multiarch systems. I don't think our enterprise customers will like that. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Stephan Kulow wrote:

Am Dienstag 15 April 2008 schrieb Klaus Kaempf:

...

(from libredcarpet:rc-queue-item.c) /* Check to see if we conflict with ourself and don't create * an uninstall item for it if we do. This is Debian's way of * saying that one and only one package with this provide may * exist on the system at a time. */

Does sat-solver get this right ? Does it matter to rpm only solutions?

I can imagine any ugly way to hide self conflict to rpm: Conflicts: packagefirst(name_of_the_package:string_used_as_a_hash) For example: Conflicts: packagefirst(gimp-branding:branding-openSUSE) For rpm, strings will be different and file conflict will happen. For zypp, packagefirst will create conflict, which will be ignored for package itself and applied for all other packages. And yet another solution I can imagine: Do nothing. Let the error happen on rpm level. Calling solver again after rpm level error is a planned feature. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On Wed, Apr 16, 2008 at 11:20:43AM +0200, Stanislav Brabec wrote:

Stephan Kulow wrote:

...

Am Dienstag 15 April 2008 schrieb Klaus Kaempf:

...

(from libredcarpet:rc-queue-item.c) /* Check to see if we conflict with ourself and don't create * an uninstall item for it if we do. This is Debian's way of * saying that one and only one package with this provide may * exist on the system at a time. */

Does sat-solver get this right ? Does it matter to rpm only solutions?

I can imagine any ugly way to hide self conflict to rpm:

Conflicts: packagefirst(name_of_the_package:string_used_as_a_hash)

For example: Conflicts: packagefirst(gimp-branding:branding-openSUSE)

What is "packagefirst"? How about: Provides: bootsplash-branding Conflicts: otherproviders(bootsplash-branding) Or something like that. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On Tuesday 15 April 2008 09:59, Klaus Kaempf wrote:

Well, then how can this use-case be implemented with rpm dependency semantics ?

It's not pretty, but how about an intentional file conflict? CU -- Stefan Hundhammer Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Stefan Hundhammer wrote:

On Tuesday 15 April 2008 09:59, Klaus Kaempf wrote:

...

Well, then how can this use-case be implemented with rpm dependency semantics ?

It's not pretty, but how about an intentional file conflict?

It is already there. But libzypp does not use file conflict concept (requires very huge data). I am not sure, whether it is possible to solve such conflict post-mortem, i. e. after failed attempt to install, the conflict will be added to local zypp database, solver will run once again and suggest new solution including this conflict. Note that it would not be sufficient to implement such conflicts to server metadata. Typically, this conflict will look as follows: Repository openSUSE 11.0: gimp-branding-openSUSE Repository SLED 11: gimp-branding-SLED Repository Flocke Brand: gimp-branding-Flocke Repository Flocke Brand could be used for both openSUSE 11.0 and SLED 11, in both cases gimp-branding-Flocke conflicts with each other gimp-branding-*. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org