[Klug-general] Ubuntu and Kabuntu

[George Prowse]

Karl Lattimer wrote:

>On Tue, 2005-06-21 at 16:30 +0000, George Prowse wrote:
>  
>
>>RPMs never get built correctly because they are so complicated.
>>    
>>
>
>Only by truly stupid packagers, RPM builds should be simple enough, only
>a few packages require any special treatment and thus far I've never
>come across a single package which doesn't build correctly. And I
>rebuilt openLDAP, took a while but I did it 2.1.18 for rh7.1 that was
>admittedly a complicated process because of the redhat nspr? (ETLA i
>can't remember exactly) bug at the time which hindered db4 quite a bit.
>  
>
Unfortunately not everyone is as good as you. Sucess rate for these
sorts of things have to be at least 99.9% not ~40%

>
>  
>
>>The dependency managing/checking tools are bad (one type of dep... which
>>leads to multiple rpms needed)
>>What about if you install package a which has dep b but dep b needs dep
>>c? why do you not get told about dep c at dep a time?
>>    
>>
>Have you ever met yum? Yum fixes this problem. RPM is a replacement for
>slack builds, not a complete management of package builds, i.e. rpm is
>not emerge.
>
>The idea is simply to pack a tarball in such a way that it doesn't need
>to know anymore than what _it_ requires. To use your analogy does deb
>store a list of the requirements of package b inside of package a? I
>think you'll find it doesn't, apt handles that on deb, but also handles
>this on redhat, as well as yum up2date and red carpet. Imagine the size
>of a package like evolution, the header alone would be at least a meg in
>size defining the dependencies and dependencies of dependencies and the
>dependencies of the dependencies of the dependencies ad infinitum. 
>
>So in that instance does deb then get around the problem of package a
>requiring package b which requires package c? Not unless package a knows
>about what package b requires without having a copy of it.
>  
>
frontends are all the same, tell me that RPM is superious to DPKG...
Impossible so therefore whatever frontend DPKG is being used on is
automatically better.

>>Want me to go on?
>>    
>>
>Yes Please!!
>  
>
An RPM spec builder can't say that package A requires some version of package B, where the version is greater that 2.0 but less than 3.0, and not version 2.3. In fact, you can't specify that any version less than 2.0 is acceptable.

As a result of weak dependency management, package builders either choose the simplest dependency possible, or build their own complex dependency rules into RPM. However, no matter how nice your RPM dependencies are specified, the whole system can fail if just one package you depend on has a bad dependency specification. In short, RPM dependencies are fragile.

RPM packages are monolithic. That is to say, the package specifications are part of the entire package. Why is this a problem? Because to be able to resolve dependency trees, you have to have access to all of the packages in the tree. Here is the main failure of RPM: you can't get intelligent queries out of it. The O() number of packages you need to query any dependency tree is all of the RPM packages in the entire world.

>>RPM is just another example of good idea, bad execution.
>>
>>    
>>
>imho RPM has better (please excuse the executive bullshit) more market
>penetration than deb because, shock! its better! Unless you can think of
>another reason why redhat, turbolinux, suse and many others use it. Also
>remember that the only two well adopted enterprise distro's of linux
>suse 9.3 ent and rhel both use rpm.
>
>What wins out then for package management,
>
>deb & apt
>rpm & apt
>rpm & yum
>rpm & rc
>rpm & up2date
>???
>emerge is cool, but its hardly the same as either deb or rpm so don't
>bring that boy into the debate.
>
I'm not bringing emerge into this, Portage would always come out on top
because:
1. API compatibility across packages is very common, but by not building
these yourselves you can often break ABI compability. It means, that a
single package can be easily upgraded without having to upgrade anything
else which compiled against it (most of the time).
2. The ability to draw in/out dependancies based on true requirements
using USE flags. it will depend and build against say, kerberos, but
equally doesnt need to.

But apt would usually come out on top. I dont blame Red Hat, some of its
problems are from the LSB (the LSB is part of Red Hats problem though).

LSB: Another good idea badly handled.

	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com