[packagers] Re: [users] FYI: bug in git-1.7.1-1 package

Dag Wieers 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:
> <snip>
>> >  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 
the examples.

> $ rpm -qp --requires git- |grep -i svn
> perl(SVN::Core)
> perl(SVN::Delta)
> perl(SVN::Ra)
> $ rpm -qp --requires git-1.7.1-2.el4.rf.i386.rpm |grep -i svn
> perl(SVN::Core)
> $
> 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 
> did?).

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 
> anyway.

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 mailing list