[opensuse-packaging] Automatically installing "plugins" via dependencies
Hi, does anyone an idea how to solve situations like this in a "right way"? There is an application A and a library L and libL-plugin for app A. The user installs A and L and wants to use L features from A. Another user installs just A and is not interrested in L. Now if A would require or recommend libL-plugin, then installing A would automatically pull the (possibly big and unwanted) library L. Requiring or recommending libL-plugin in L would have the same problem. To give a real example: A = unixODBC L = mysql-shared (or postgresql-libs) libL-plugin = MyODBC-unixODBC (or psqlODBC) Both unixODBC and mysql-shared can be used without each other, but the user somehow expects, that if he or she installs unixODBC and mysql-shared, it will simply work with each other. See this bug: https://bugzilla.novell.com/show_bug.cgi?id=144602 Other example is php5 and it's extensions (databases again for example), some multimedia players and codec libraries probably have a similar problem. Any ideas? -- Michal Marek SuSE CR --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org
On Wed, Jun 07, 2006 at 02:00:38PM +0200, Michal Marek wrote:
does anyone an idea how to solve situations like this in a "right way"? There is an application A and a library L and libL-plugin for app A. The user installs A and L and wants to use L features from A. Another user installs just A and is not interrested in L. Now if A would require or recommend libL-plugin, then installing A would automatically pull the (possibly big and unwanted) library L. Requiring or recommending libL-plugin in L would have the same problem.
To give a real example: A = unixODBC L = mysql-shared (or postgresql-libs) libL-plugin = MyODBC-unixODBC (or psqlODBC)
Both unixODBC and mysql-shared can be used without each other, but the user somehow expects, that if he or she installs unixODBC and mysql-shared, it will simply work with each other. See this bug: https://bugzilla.novell.com/show_bug.cgi?id=144602
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. Sorry, Michael. -- Michael Schroeder mls@suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org
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... Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org
* Michal Marek <mmarek@suse.cz> [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
Klaus Kaempf wrote:
* Michal Marek <mmarek@suse.cz> [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
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?
This is internally evaluated as 'if unixODBC and mysql-shared are installed, then install this package'.
Yes, this would be exactly what I need. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org
* Michal Marek <mmarek@suse.cz> [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
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? 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
* Marcus Rueckert <mrueckert@suse.de> [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
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. Cheers, Michael. -- Michael Schroeder mls@suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- 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
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. 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. cu Reinhard --------------------------------------------------------------------- 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 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. cu Reinhard --------------------------------------------------------------------- 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
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. In addition the package contains a README.SUSE file that explains which library packages are needed the respective database backend plugins. I agree that this is nothing for entry level users, but entry level users most probably won't try setting up a Jabber server either. If we wanted to make jabberd ready for entry level users, we'd need a YaST module for it, that asks the user which database he wants to use and makes sure that the needed packages get installed. Again, no RPM-level dependencies needed for that.
imho the dependencies are the way to solve this. and just making rpm blind for those dependencies is an ugly hack.
The dependencies are just a tool. Tools are there to be used when they are helpful and not to be used when they do more harm than good. cu Reinhard --------------------------------------------------------------------- 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
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. 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. BTW, I talked to Rudi and aj before submitting this modification to the jabberd package, and got their OK to give it a try. cu Reinhard --------------------------------------------------------------------- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adrian Schröter wrote:
Am Wednesday 14 June 2006 11:23 schrieb Reinhard Max:
Hi,
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
On Wed, 14 Jun 2006 at 10:49, Adrian Schröter wrote: 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.
+1
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.
Totally agree. That's really the way to do it and, frankly, I don't see why those ugly hacks are necessary.. just to avoid having a few jabberd-* subpackages ? Reinhard, AFAICR, you were saying that having subpackages for backends would be too difficult for end users to install/choose from. If that's the reason for not doing it that way, then I wouldn't quite agree.. handling explicitly broken/removed dependencies is much more complex. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEkI98r3NMWliFcXcRAizFAKCmlERp+5xtW/L4wdttt1y021jV7QCeMnjY C4fhOC9gXO5iHJtsM8aUamk= =wYOl -----END PGP SIGNATURE----- --------------------------------------------------------------------- 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
* Reinhard Max <max@suse.de> [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). We're just missing an application to present it nicely to the user. Klaus --------------------------------------------------------------------- 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 <max@suse.de> [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
On Fri, 16 Jun 2006 at 13:38, Reinhard Max wrote:
# 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")
Hmm - looking again at the syntax of existing macros for the %files section (e.g. %attr), the syntax of my proposal should probably look more like this: --- snip --- %suggests("PAM authentication") %_libdir/jabber/authreg_pam.so %suggests("PostgreSQL storage and authentication") %_libdir/jabberd/*_pgsql.so [...] --- snap --- cu Reinhard --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org
* Adrian Schröter <adrian@suse.de> [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
Klaus Kaempf wrote:
* Adrian Schröter <adrian@suse.de> [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. Maybe this feature would solve my original problem. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging-help@opensuse.org
* Michal Marek <mmarek@suse.cz> [Jun 15. 2006 09:22]:
Klaus Kaempf wrote:
* Adrian Schröter <adrian@suse.de> [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
Klaus Kaempf wrote:
* Michal Marek <mmarek@suse.cz> [Jun 15. 2006 09:22]:
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.
No fair! ;-) $ ls -1Ssh postgresql-libs.rpm mysql-shared.rpm 1,2M mysql-shared.rpm 188K postgresql-libs.rpm Michal --------------------------------------------------------------------- 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
participants (8)
-
Adrian Schröter -
Klaus Kaempf -
Marcus Rueckert -
Michael Schroeder -
Michal Marek -
Pascal Bleser -
Reinhard Max -
Stanislav Brabec