I am reposting this from fedora php-devel list to get a bigger audience. My questions are not that PHP specific:
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. phpUnderControl also patches the CruisceControl installation, so it isn't something that can easily packaged as an RPM.
Does it still make sense to bring phpUnderControl into Fedora even though it requires an external software package?
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.
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.
My final goal is to make Fedora the best development environment for PHP, where you can get the full set-up of tools just with a few (or one) yum command. Ideally this would work on RHEL too, but I guess not before 6.0 and not for much after that because the shipped PHP release will too old again. With the Remi repository it would also work on older RHEL.
Any suggestions are welcome :-)
Cheers, Christof
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. =)
On Wed, Jun 2, 2010 at 23:52, Adam Williamson awilliam@redhat.com wrote:
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.
OK, that is what I thought. I might have a look at packaging CruiseControl in the future, but I can't really see having a CruiseControl and a phpUnderControlCruiseControl, because that would be frowned upon even by me :-)
I also don't really want to package CruiceControl, because it is Java and I just don't understand it enough. It seems to be very specific where you place your data files.
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'.
It would be good to have this in the packaging guidelines somewhere. All I could find were random threads in mailing list, none of them with an official conclusion as far as I could seen.
I guess I will leave both packages for now and create my own repository with just those two and see how it is working out.
Cheers, Christof
On Wed, 2010-06-02 at 14:52 -0700, Adam Williamson wrote:
On Wed, 2010-06-02 at 18:31 +0200, Christof Damian wrote:
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'.
Off the top of my head:
1. They are similar to groups and having two things that are similar is bad.
2. There's no way to do the groupremove operation, easily.
3. There's no way to do the groupinfo operation, easily.
4. There's no naming guideline, so grouplist operations are also not easily available.
5. You can't do:
@mygroup -blah
...in a kickstart, if "mygroup" is a metapackage.
6. All the packages as part of the metapackage will be marked as "reason = dep", which isn't true.
7. The one advantage they have (you can update the metapackage and have the new members added everywhere) will go away when we get groups as objects.
8. If you want to remove part of a metapackage, you have to remove the metapackage itself ... and thus. lose the only advantage they have.
9. There's no way to make them different for different spins.
10. There's no way to extend them from other repos.
James Antill wrote:
- There's no way to do the groupremove operation, easily.
The groupremove operation is completely and utterly broken by design anyway:
1. It doesn't remove stuff which was independently dragged in by dependencies of the packages in the group. So you'll be removing only the end-user apps and be stuck with most or all of the libraries. (And please don't suggest remove-with-leaves as the "solution", that one is completely and utterly broken by design as well, e.g. it will happily remove a standalone program which happens to also be a dependency of a program you remove.)
2. It also removes stuff which is also in other groups.
3. It also removes stuff which the user had already installed before installing the group.
Try groupremoving gnome-desktop on a system with both GNOME and KDE installed and watch it try to remove half of KDE while leaving half of GNOME sitting there wasting space. And it just CANNOT be fixed.
The only (mostly) reliable way to undo a groupinstall is yum history. And even that will only work as expected if the group was recently installed.
Kevin Kofler
On Fri, 2010-06-04 at 05:04 +0200, Kevin Kofler wrote:
James Antill wrote:
- There's no way to do the groupremove operation, easily.
The groupremove operation is completely and utterly broken by design anyway:
It doesn't act perfectly, in all cases, no. [...]
Try groupremoving gnome-desktop on a system with both GNOME and KDE installed and watch it try to remove half of KDE while leaving half of GNOME sitting there wasting space.
Right, "gnome-desktop" is a typical group. Silly me.
And it just CANNOT be fixed.
You mean apart from using yum from rawhide and doing:
yum remove @gnome-desktop --setopt=groupremove_leaf_only=true
...or groups as objects, or...
The only (mostly) reliable way to undo a groupinstall is yum history. And even that will only work as expected if the group was recently installed.
So groupremove _has_ to do the same thing as an undo of a groupinstall to not be considered "utterly broken by design"? I guess that means plain remove is also "utterly broken by design"?
Wait ... don't answer here ... if you want to troll/rant, feel free to send me personal email where I'll happily ignore it. Subjects like "yum should be faster than rpm" or "why don't we just move to apt/smart/pacman/image-packaging-system" are probably your best bang for the buck.