11:31 a.m.
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
4:52 p.m.
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
2:25 a.m.
On Wed, Jun 2, 2010 at 23:52, Adam Williamson <awilliam(a)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
10:06 a.m.
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 - james(a)fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.28
http://yum.baseurl.org/wiki/YumMultipleMachineCaching
10:04 p.m.
James Antill wrote:
2. 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
10:45 p.m.
On Fri, 2010-06-04 at 05:04 +0200, Kevin Kofler wrote:
James Antill wrote:
> 2. 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.
--
James Antill - james(a)fedoraproject.org
"... so the consumable rawhide is likely not to get as many updates
as its users would like to have." -- Kevin Kofler
5082
days inactive
5084
days old
5 comments
4 participants
participants (4)
-
Adam Williamson -
Christof Damian -
James Antill -
Kevin Kofler