* Michal Marek [Jun 07. 2006 14:25]:

Michael Schroeder wrote:

...

You need enhances/supplements with AND for this, i.e. in package libL-plugin add:

Supplements(and): unixODBC mysql-shared

We don't have support for this yet, though. ^^^

This means that such feature is planned? Wow...

Yes. For now, you can work around by specifying a 'freshens' as Freshens: unixODBC Supplements: mysql-shared This is internally evaluated as 'if unixODBC and mysql-shared are installed, then install this package'. However, the solution proposed by Michael is the right one for the future. Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org

* Michal Marek [Jun 07. 2006 15:10]:

Freshens: doesn't seem to be supported by rpmbuild, I get

error: line 7: Unknown tag: Freshens: unixODBC

also grep -i "freshens" in our current rpm source tree doesn't show anything. Maybe it's just a dependency used internally in ZYPP (for patches?), but not in rpm?

Please check with Michael Schroeder (mls@suse.de) what the exact Tag name is. Its supposed to be supported by rpm in Code10. Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org

* Marcus Rueckert [Jun 08. 2006 15:10]:

On 2006-06-08 14:36:48 +0200, Klaus Kaempf wrote:

...

...

Freshens: doesn't seem to be supported by rpmbuild, I get

error: line 7: Unknown tag: Freshens: unixODBC

also grep -i "freshens" in our current rpm source tree doesn't show anything. Maybe it's just a dependency used internally in ZYPP (for patches?), but not in rpm?

Enhances?

No, not quite. Enhances is a weaker 'supplements' and completely ignored by the dependency solver. The intended use for 'enhances' is by applications like SuSEplugger to present the user a list of packages which are useful for a specific task (i.e. support of a device). So enhances is just additional information but does not trigger any action. Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org

Michael Schroeder wrote:

On Thu, Jun 08, 2006 at 02:36:48PM +0200, Klaus Kaempf wrote:

...

Please check with Michael Schroeder (mls@suse.de) what the exact Tag name is. Its supposed to be supported by rpm in Code10.

No, it's not.

Well, that doesn't matter. Automatically installing the MyODBC-unixODBC package would be just a "nice to have" thing for 10.2 or so. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org

On 2006-06-13 13:27:22 +0200, Reinhard Max wrote:

I recently had the same problem with the jabberd package. It supports a variety of database backends, but I didn't want to add all those libraries to the dependency list of the package, and I didn't want to add half a dozen plugin packages that contain more metadata than payload.

So I decided to keep all the plugins in the main package, but exclude them from the automatic dependency checking.

As jabberd doesn't try to load any plugins it hasn't been configured for, I think this was the best solution for my case. Not sure how well it applies to other plugin-capable packages.

i have the same "problem" with dspam and pdns. but i dont think it is this hard: http://zen.sh.nu/~darix/dspam.spec http://zen.sh.nu/~darix/pdns.spec i simply moved all backends, that require new libraries, into subpackages. For dspam i solved it with some virtual provides/requires. in case of pdns it has some working backends in the main package. shouldnt the same work for you aswell? darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org

On 2006-06-13 14:36:24 +0200, Reinhard Max wrote:

On Tue, 13 Jun 2006 at 13:38, Marcus Rueckert wrote:

...

shouldnt the same work for you aswell?

Yes, probably, but I already explained why I din't want to do it that way. I consider it easier to skip some automatic dependencies and keep everything in one package than "simply" creating all those tiny subpackages and having to maintain their metadata in the PDB.

IMHO we have way too many of those micro-packages already.

imho we have way to many of those "fat pull in all dependencies" packages. what happens in your jabber package if the required library for a plugin isnt found? imho the dependencies are the way to solve this. and just making rpm blind for those dependencies is an ugly hack. just my 2 cents darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org

Am Tuesday 13 June 2006 15:20 schrieb Reinhard Max:

Hi,

On Tue, 13 Jun 2006 at 15:05, Marcus Rueckert wrote:

...

imho we have way to many of those "fat pull in all dependencies" packages.

True, that's why I am skipping the dependencies in this special case.

...

what happens in your jabber package if the required library for a plugin isnt found?

You get an error message saying exactly that.

I think that's acceptable, because you have to go through a number of config files when setting up jabberd anyways, and when you decide to use database X as your storage backend you most probably have the respective library package installed already, because for most databases you also need the command line client (which in turn depends on the library) to initialize the database before jabberd can use them.

It is anyway not really good, when jabberd is the only exception where the user has to manually find that out while all other packages are package in a different way, where this is not needed. Consistens is also a feature of a distribution ... -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org

Am Wednesday 14 June 2006 11:23 schrieb Reinhard Max:

Hi,

On Wed, 14 Jun 2006 at 10:49, Adrian Schröter wrote:

...

It is anyway not really good, when jabberd is the only exception where the user has to manually find that out while all other packages are package in a different way, where this is not needed.

it wouldn't be any different with the other proposed solution (set the dependencies of the plugin subpackage so, that it will be installed when the main package and the respective database library are installed), because the user still has to know that he must install the database library in order to get the plugin installed.

Yes, but the user does see all the packages in his installation tool in YaST when he searched for jabberd and can decide which backend he wants to use. And it does work afterwards because of correct requires. You could even add a "Requires: jabberd_backend" to the main package, so the user gets a popup from YaST to select one.

Also, who says, that when somebody has installed jabberd and, say, the MySQL client libraries, that he actually wants to use MySQL as the storage backend for jabberd (and hence needs the MySQL plugin), and not PostgreSQL, SQLite, or something else. Only the user knows this, and that's why automatic dependencies and/or subpackages just don't make sense for this package when looking for the best tradeoff between ease of use, packaging complexity and space requirements.

yes, so you need for mysql, postgresql and sqlite an own sub package. AFAIK it is done in that way with all packages we do have and can use different SQL backends. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org

On Thu, 15 Jun 2006 at 00:36, Pascal Bleser wrote:

Adrian Schröter wrote:

...

You could even add a "Requires: jabberd_backend" to the main package, so the user gets a popup from YaST to select one.

+1

That dependency would be bogus, because the backends that don't have external dependencies will of course stay in the main package, and so the main package would be self-contained. So the difference between this and my solution would be: This: 1. Install jabberd 2. Install the client library package of the database you want to use (if it isn't there already). 3. Configure jabberd to use that database. 4. Find out that jabberd doesn't work. 5. Investigate and find out that a plugin is missing. 6. Search for the package that has the plugin and install it. 7. Enjoy a working jabberd installation. My Solution: 1. Install jabberd 2. Install the client library package of the database you want to use (if it isn't there already). 3. Configure jabberd to use that database. 4. Enjoy a working jabberd installation. I know that this solution isn't perfect either, because it e.g. doesn't cover the case that the installed version of the database client libary might be incompatible with the one the plugin was linked against. I think an ideal solution for this (so that package cluttering is avoided but not too many dependencies are skipped) would be if RPM provided a way to specify, "The dependencies of this shared object are weak. The package will work fine when they are not resolved, but tell the user that he will get this and that additional functionality when he choses to resolve them." cu Reinhard --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org

On Fri, 16 Jun 2006 at 12:53, Klaus Kaempf wrote:

* Reinhard Max [Jun 16. 2006 12:47]:

...

I think an ideal solution for this (so that package cluttering is avoided but not too many dependencies are skipped) would be if RPM provided a way to specify, "The dependencies of this shared object are weak. The package will work fine when they are not resolved, but tell the user that he will get this and that additional functionality when he choses to resolve them."

We have this kind of dependency (suggests).

Can I tell rpmbuild's automatic dependency collector that all dependencies of a certain shared object inside my package will be of the kind "Suggests:" rather than "Requires:"? Otherwise I'd still have to hide these files from the automagic and maintain the tags by hand, which is either too generic (when only suggesting by package name) or too much manual work (when suggesting by soname and having to touch my package every time the soname changes). And can I add some descriptive text to a suggests dependency that will be presented to the user (once a frontend exists) to help him making his decision? I imagine something like this: --- snip --- %files # the plugin directory %dir %_libdir/jabberd # plugins without additional external dependencies %_libdir/jabberd/authreg_anon.so %_libdir/jabberd/authreg_pipe.so %_libdir/jabberd/storage_fs.so [...] # plugins with additional external dependencies # that shall be treated in a weak way. %suggests(%_libdir/jabber/authreg_pam.so, "PAM authentication") %suggests(%_libdir/jabber/authreg_ldap.so, "LDAP authentication") %suggests(%_libdir/jabberd/*_pgsql.so, "PostgreSQL storage and authentication") %suggests(%_libdir/jabberd/*_mysql.so, "MySQL storage and authentication") [...] --- snap ---

We're just missing an application to present it nicely to the user.

Which is very much eqivalent to "we don't have this kind of dependency yet." ;) cu Reinhard --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org

* Adrian Schröter [Jun 14. 2006 12:14]:

You could even add a "Requires: jabberd_backend" to the main package, so the user gets a popup from YaST to select one.

No, you don't. The dependency solver coming with 10.1 will solve this requirement automatically. Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org

* Michal Marek [Jun 15. 2006 09:22]:

Klaus Kaempf wrote:

...

* Adrian Schröter [Jun 14. 2006 12:14]:

...

You could even add a "Requires: jabberd_backend" to the main package, so the user gets a popup from YaST to select one.

No, you don't. The dependency solver coming with 10.1 will solve this requirement automatically.

Which criteria are taken into account? Esp. when each one of the alternatives would pull aditional dependencies.

The current algorithm tries to optimize on package changes (i.e. prefer update of an existing package over installation of a new package) and on download size. There are zillions of other algorithm, each of them probably completely wrong and completely right, depending on the circumstances ;-) Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org

Reinhard Max wrote:

Hi,

I recently had the same problem with the jabberd package. It supports a variety of database backends, but I didn't want to add all those libraries to the dependency list of the package, and I didn't want to add half a dozen plugin packages that contain more metadata than payload.

I did the same for inkscape and planner packages, but did an additional triggers to enable these plugins only if dependent packages are installed. For more see these spec file in 10.1. Note that you may want to copy and paste %triggerin to %post (it looks so, needs re-check) and %triggerpostun to %postun (probably not required, needs re-check) - see planner.spec. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SuSE CR, s. r. o. e-mail: sbrabec@suse.cz Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9 fax: +420 296 542 374 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org