[packagers] Re: [users] FYI: bug in git-1.7.1-1 package
dag at wieers.com
Thu Jun 24 17:25:54 CEST 2010
On Thu, 24 Jun 2010, Tom G. Christensen wrote:
> Dag Wieers wrote:
>> On Thu, 24 Jun 2010, Tom G. Christensen wrote:
>> > I simply don't understand why he would deliberately choose to be
>> > different from all the other repos :(
>> Because different policies cause different ways of doing it. Did you like
>> the clamav subpackage mess in Fedora ? I know few people who liked it. And
>> they introduced these packages years after RPMforge was shipping them. So
>> it's not like RPMforge is doing everything differently, all repositories
>> do things differently depending on what the packager thinks is best.
> I refuse to get into the clamav debacle with you.
Perfect, I had no interest in doing that either :-)
>> Besides I took care to make sure you can upgrade to the RPMforge packages,
>> or upgrade back to EPEL packages. It shouldn't cause any problems, and if
>> they do, let me know.
> Yes thank you, that should make it much easier to ignore them.
I don't ignore them. Quite the opposite.
>> > The old rpmforge package was *horrible* because it had no subpackages.
>> > Many people have absolutely zero need for git-svn or git-cvs and don't
>> > want subversion and cvs installed on their machines just because they
>> > need git!
>> Indeed, I agree with that. We didn't have subversion or cvs as a
>> dependency so it shouldn't have mattered.
> I see. So shipping binaries without their dependencies so they're useless is
> better than putting them in their own package with proper deps?
We can debate what is useless and what isn't. But yes, in some cases I
prefer having no dependencies over sub-packages. nagios-plugins is one of
> $ rpm -qp --requires git-22.214.171.124-1.el4.rf.i386.rpm |grep -i svn
> $ rpm -qp --requires git-1.7.1-2.el4.rf.i386.rpm |grep -i svn
> That's subversion for you right there as a dependency.
And so you make a good point here :-) Which pretty much
>> > Ofcourse his new package does not build on el3 either since he just
>> > merged upstream :(
>> Who's fault is that ?
> Yours since upstream does not support el3 and rpmforge does (or is that
See further below.
> The reason it does not build is because I am using
>> the filter macros to filter away perl(packed-refs) and those macros don't
>> work on RHEL3. Besides RHEL3 is almost past its expiration date.
> You introduced that problem yourself.
Yes, we decided to move to the filter macros a long time ago. We are
already doing that for various perl packages. Those don't build for RHEL3
anymore either, since some time. I don't see why I should do it here.
> AFAIK the upstream does not use the filter macros because they are not
> available in their older buildroots so would make it unbuildable on EPEL 4,5.
> It's not the only problem you'll run into on el3 but it seems you don't care
No, I don't see a point in spending more time on RHEL3 packages if it's
end-of-life in about 5 months. If it's a by-product or someone else wants
to go the extra mile I don't mind but it's certainly not my focus.
Maybe we should ask around if anyone is interested in git for RHEL3 and
only spend that effort when there is a demand ?
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]
More information about the packagers