[Klug-general] Ubuntu and Kabuntu

[Karl Lattimer]

>>
> Unfortunately not everyone is as good as you. Sucess rate for these
> sorts of things have to be at least 99.9% not ~40%
>

Seriously show me an instance of a piece of software which hasn't  
already been built for rh/suse or has a spec available, or isn't too  
difficult to write a spec? I agree that back in the days of rh 3.x ->  
7 there were major issues and (upto suse 8), rh8 didn't fix it but it  
made them go away, 9 has the new spanky rpm and fc4 has a swanky one,  
the majority of build issues have dissolved and packages can be built  
nightly without breaking in 99.9% ~ .2% of the time. So ner ner, I  
like rpm and it is better than deb!

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

Yes but do you want duplicate packages? gtk-1.2 and gtk-2 what if you  
want to delete gtk-2 but not gtk-1.2 and you don't realise you have  
gtk-1.2 installed, so its easy just to call it gtk2-2.x because that  
way A) you are reminded that there are legacy apps which still use  
gtk1 and B) you can completely separate them and have them run nicely  
co-existively. by saying requires gtk+ >= 1.2 or gtk2 >= 2.4 means  
you don't have the need for complex dependencies, and admittedly in  
the past some packagers fell over with this but its now easy to see  
past it.

>
> 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.
>
Do you need to do intelligent queries? Dependencies are best put as  
keep it simple, or else other problems arise, but having said that  
you don't want to say package b requires package a and c when in fact  
having package a implies this. Its just a waste of time, headers  
provide masses of data about packages without needing the packages  
installed downloaded or otherwise available. The issue now is to  
resolve packaging issues by means of employing a repository ala apt/ 
yum that way you have access to tried and tested working packages  
within a repository which is rebuilt whenever there is a new release,  
no more messing about.

BTW deb's are also monolithic, they do not include the whole tree of  
dependencies and therefore are simply almost the same as RPM in that  
respect. So you still haven't given a single reason why deb is  
_BETTER_ than rpm you've just slated rpm?
>
>>> 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.
>
I know its a better architechture, I said it was cool, i wasn't  
slating it, but you are bringing it into the conversation i admit it  
fucking rocks BUT! you're building everything? from source so you  
have great advantages, and great disadvantages, its all about  
balance. Servers you want packages you know work, have been tested  
have (sometimes obscure) security fixes in place weeks sometimes  
months before they come out of CVS. Desktops well I'd rather use  
something that someone else has built and tested before I put it on  
my box.


> 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.
>
Agreed but its f*ck all to do with rpm, and hey its better than (un) 
united linux which i believe has crumbled after some in fighting.  
Remember that LSB is a simple set of standards so systems can be  
inter-compatible for things like initscripts and such like, not a  
cartel of linux distributers who are angry at the linux share that  
redhat has and wants a piece of the pie.

The simple fact here is that deb vs rpm is a moot point, rpm has got  
better market penetration and is more widely adopted. The deb  
community in general is slipping away, they have managed to make a  
release this year so did apple, redhat, fedora and sun? Microsoft is  
still nowhere to be seen and missing most of the tech they promised  
instead touting the usual bullshit about security, stability and  
reliability i think its their mantra now.

The simple fact is, RPM has made it incredibly easy to run servers  
throughout the world, suse/novell and redhat/ibm and many others have  
benefitted from it, whereas deb has produced an almost impossible to  
sell distro because of their attitude toward non gpl software, this  
makes it harder to support from a hardware vendors perspective, they  
trail behind on patches and updates because they even struggle to  
release a distro. Deb is completely out dated and is difficult to  
maintain, and build new distributions out of.

RPM/Anaconda has been a vital tool, in places where there has been a  
mass install of redhat/fedora (a number of US universities and other  
institutions) they have found it easy to custom build their install  
CD's update their install CD's, build kickstarts for unattended  
installs with custom install cd's, maintain a package repository to  
speed up yum transactions and maintain versioning throughout an  
organisation.  These are all very important achievements of RPM/ 
anaconda, deb has been left by the wayside as a result of the way  
their community is run.

So from my point of view, as a linux user, systems administrator,  
programmer and general geek, rpm serves my needs, has better support  
is more widely available and pretty easy to use, and I get to use  
gnome 2.10 without much work i.e. putting a CD in and pressing the  
big upgrade button. A few days pass and the bleeding edge distro is  
even more bleeding edge and about a week from now I'll have gstreamer  
with DVD menu's in totem, how long will it take deb to get that?  
WITHOUT BUILDING IT FROM SOURCE!

Not everyone wants to build a package from source when it doesn't  
work, or its not available, for me that is a last resort. rpm/yum and  
anaconda serve the needs of many. Me included I don't find the  
problems you mention, as inhibiting factors. I find apart from the  
odd nuisance of it rpm serves my needs and keeps things ship shape.

k,

>
>
>
> ___________________________________________________________
> Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide  
> with voicemail http://uk.messenger.yahoo.com
>
> _______________________________________________
> Kent mailing list
> Kent at mailman.lug.org.uk
> http://mailman.lug.org.uk/mailman/listinfo/kent
>
>