On Wed, 2010-06-02 at 18:31 +0200, Christof Damian wrote: > I am reposting this from fedora php-devel list to get a bigger > audience. My questions are not that PHP specific: Good, because neither are my answers =) I know nothing about the area in question, so bear that in mind. > I got two questions regarding my effort to package more of the php-qa > packages for fedora. > > I have made a package for phpUnderControl now, but to use it you still > have to install CruiseControl by hand. The obvious response here is 'so, package CruiseControl too!' If you can't package CruiseControl, then you shouldn't package phpUnderControl; it's frowned upon / not allowed (I can never remember which) to package something which requires something that can't go into Fedora for some reason. > phpUnderControl also patches > the CruisceControl installation, so it isn't something that can easily > packaged as an RPM. The first obvious response here is 'ew, why does it do that?' The second is 'then package the modified CruiseControl that phpUnderControl requires under a different name, to make it clear it's been modified'. > Does it still make sense to bring phpUnderControl into Fedora even > though it requires an external software package? In general, no - see above. Fedora should be internally complete. But again, the obvious response is 'so, package CruiseControl'. > Second question: I would love to have a meta package which brings all > of these packages ( phpunit, phpmd, phpcpd, phpdoc, phpcs, Mockery, > ...) together and allows installation with one yum command. But as far > as I could detect from the random posts it seems that meta packages > are not really wanted on Fedora. An alternative is the comps list, but > that doesn't allow for rapid changes and phpqa would be a bit > specific. For whatever reason, We Don't Like Metapackages and the 'recommended' way to do it is with a package group. I've never seen a particularly coherent reason given for this, but never mind. Some packagers _have_ done metapackages, and none of them have been shot yet. Just sayin'. > A third option would be to make something like phpUnderControl require > all of these. The pear package already suggests some of them, but it > isn't a hard require. Generally speaking, requirements should be *requirements*; you should only have your phpUC package require those other things if it just wouldn't work without them, or if no sane person would ever actually want to run it without them. Soft dependencies (suggests) are the 'obvious' solution there, but whenever anyone suggests soft dependencies, Seth posts his handy laundry list of corner cases and says 'sure, we'll do it as soon as you can come up with the right way to do all of these', and no-one ever *can* come up with a right way to do them. So we don't get soft deps. =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
