redhat abe

Jeff Johnson n3npq at nc.rr.com
Thu Jan 27 14:07:24 UTC 2005


Ralf Corsepius wrote:

>On Thu, 2005-01-27 at 08:16 -0500, Jeff Johnson wrote:
>  
>
>>Thomas Vander Stichele wrote:
>>
>>    
>>
>
>  
>
>>>c) nothing more was ever offered as negative feedback on mach than "it
>>>uses apt" (a fact that is easily changeable, obviously);
>>>
>>>      
>>>
>>Well clearly, having mach rely on a package that is not included in any Red
>>Hat product,
>>    
>>
>RH has the ability to change this at any time.
>  
>

So does mach.

>  
>
>> presents certain logistical difficulties.
>> That should be obvious.
>>    
>>
>It is not - RH has had no problems in adding yum support and has no
>problem in adding and removing other packages at any time at RH's free
>will.
>  
>

It's not obvious that mach (as is) will never function on any Red Hat 
(or Red Hat packages)
based distro unless apt is included? I beg to differ.

Yum, because in python, and because developed more closely with other 
Red Hat tools
like anaconda originally at YDL and now locally at Duke, was an easier 
cost/benefit decision.

apt, because in C++, with concepts like Suggests: and Recommends:
and Enhances: and pinning and a back-tracking depsolver and alien etc 
etc, is a far far more
complicated integration effort with a less clear cost/benefit analysis.

Red Hat has very few people able or willing to support apt, for 
historical, if not
for other reasons.

>For example instead of adding yum and keeping up2date, RH could have
>tried to help apt. - IMO, this is all politics and not at all
>technically motivated.
>  
>

I have helped apt-rpm, and have helped smartpm, and have helped Red Carpet,
and other distros technically with rpm for years.

And I work for Red Hat.

Does that count?

>  
>
>>And, FWIW, I have suggested repeatedly that apt be added to FC 
>>internally to Red Hat
>>in spite of the cost of attempting to maintain Yet Another Depsolver. 
>>The previous line
>>basically summarizes the majority of the feedback that I have heard:
>>
>>   FC needs fewer depsolvers that work more reliably.
>>    
>>
>Isn't the solution obvious? Implement one unified depsolver into rpm
>which behaves exactly as you envision it, instead.
>  
>

What do you think I am trying to do, grow bananas in Chapel Hill?

I have been trying to build the infrastructure for a unified package manager
for *years*. And so has Red Hat, but the politics are insurmountable imho.

Where have you been?

73 de Jeff




More information about the fedora-devel-list mailing list