Red Hat Bugzilla – Bug 137394
RPM Self-Suggest: field
Last modified: 2007-11-30 17:07:04 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Description of problem: Here's an idea: We could have a "Self-Suggest" header with package. For example, the "Self-Suggests" header for the php-mysql would read "php, mysql". The reason why you would want something like this is so that, if both PHP and MySQL are installed, then the php-mysql package is likely to be wanted too. The reason I name it that is because it suggests itself when it sees these things. The reason I suggest this is that there seems to be the potential for an increasing number of "glue" packages (eg. join logwatch and mysql, logwatch and squid, logwatch and apache, bind and ldap, bind and postgresql..... (and on and on for a loooong time)), and finding the glue packages would be much easier if we could type "up2date --dry-run --suggest", which would generate a list of all suggestions, or "up2date --suggest bind", which would install all packages which are suggested by bind (ie. list "bind" in their self-suggests field), and have their other prerequisites installed. It would be good to allow multiples of this header. For example, you might want a package that lists: Self-Suggests: perl-DBI perl-DBD-Pg Self-Suggests: perl-DBI perl-DBD-MySQL ...and want to require each collection as a group, but don't want to require *both* Pg and MySQL. If this bug would be better filed against up2date, please let me know. But I thought that a prerequisite to making it work in up2date would be adding the header in RPM.
There is no way to impose a Self-suggests convention for choosing names on existing *.rpm packages. Your rule works only for some cases, not all.
I'm happy if you guys decide not to implement this, but I want to ensure that I've communicated properly. I realised in retrospect that I didn't state the idea very well. First imagine that a package suggests itself if all prerequisites are installed. But this isn't really what's wanted. For example, it's probable that although all prerequisites for XFree86 might be installed, the user wouldn't actually want XFree86 unless they selected it or something which depends on it. Whereas if they install both php and mysql, it's probable that they want the php-mysql package. That's the problem I'm attempting to solve with the "Self-suggests" header. If you can think of a better way to solve it, I'd be even happier. Since I'm commenting anyway: > There is no way to impose a Self-suggests convention for > choosing names on existing *.rpm packages. I'm unsure what you're saying here. If you're talking about retrofitting Self-suggests onto existing RPMs, my thought was that Self-suggests would be entirely optional, as only some packages would want it. I should also make clear my assumption that Self-suggests interacts with "provides". So it's not really "if these packages are installed...", but "If these RPM thingies are provided...". If you're saying that package names are non-standard, that's no different than the problem you encounter now with Requires/Provides. This just adds a third element. > Your rule works only for some cases, not all. Great! If we've identified some cases where it doesn't work, then there may be an even better solution just around the corner! Are you willing to identify one of these cases so that I can think about them too? Thanks,