Karmic 9.10 new kernel BAD!

[Chan Chung Hang Christopher]

Avi Greenbury wrote:
> Christopher Chan wrote:
>   
>> Of course. However, that does not mean new features cannot be added
>> to an LTS release. Redhat can add new features to their RHEL4 kernel
>> and other core packages after a few point releases, so it is not
>> something that is not done or unfeasible. You just have to test
>> everything before you let such updates loose.
>>     
>
> I can see the feasibility, and some of the advantages. It just doesn't
> appear to line up with my priorities as well as it might (and apparently
> does with yours).
> I'm not particularly opposed to the idea, really, I just thought I'd
> suggest why it isn't implemented in Ubuntu.
>
>   

Well, why else would I go with an LTS release for a school? If I am 
going to have to build me own, then maybe I should just give Nexenta a 
shot instead.

>>> What's wrong with upgrading to a newer release? That way
>>> _everything_ gets new features.
>>>   
>>>       
>> Bugs. No irony here though.
>>
>>     
>
> But you *always* get bugs on upgrades. I want the upgrades with the most
> bugs in to happen rarely and at some pre-warned time. And, ideally, to
> be able to delay them without delaying the security upgrades I want.
>   

Tell that to RHEL/Centos users. I can hear the answer now: Oh really? 
(in a tone of disinterest)

> Of course, the downside is this means a cascade of bugs and
> problems and clobbered config files every release cycle, but at least
> it doesn't tend to happen in between.
>
>   

Clobbered config files? What on earth are you talking about? That sort 
of things rarely happens. Exceptions might be samba which changes stuff 
on you and sometimes without much notice at that (working but 
undocumented/poorly documented features - winbind on ldap anyone?).

>> So is it the way Ubuntu is organised that is the problem? How about 
>> system packages in a 'core' repository and applications in a
>> 'consumer' repository that depend on packages in the 'core'
>> repository then?
>>     
>
> Ubuntu's certainly organised in such a way as to lean towards Debian's
> model. I don't know how much of this is necessitated by the means
> through which packages come from Debian to Ubuntu.
>
>   

Excuse me if I vehemently feel otherwise. Debian may not separate 'core' 
and 'consumer' but they certainly upgrade 'consumer' packages such as 
pidgin without having to dist-upgrade.

>> If those ppas were advertised, fine.
>>     
>
> Yes, they do need to be more publicised. I wasn't aware of them until I
> decided to work out why no-one in Ubuntuland seemed to be suggesting
> apt-pinning to anyone, which is definitely the wrong way to find out
> about them.
>
>   
>> I don't think the problem was in shipping Firefox 3 beta. The problem 
>> was in how it was done. You can have both.
>>     
>  
> I thought the issue was that they could either ship with 2.x and
> support it longer than Mozilla would, or ship with 3.x beta and support
> it *before* mozilla did, since the policy is to not change major
> versions during a release?
>   

Like I said, you can have both. No need to change major versions. Just 
like how you got both KDE 3.5 and KDE 4.0 in Hardy.

> I'd certainly have been pissed if an apt-get upgrade broke my firefox
> and all its extensions. Though, I suppose, that'd be more down to how
> it was packaged than the fact that the upgrade happened.
>
>   

It is. Either you provide a migration tool or you install but do not 
touch the existing version. If both cannot be made to coexist, then you 
must provide a migration tool/perform migration.

>> Well I am not asking for CHANGES in feature sets. In the example
>> about Redhat, they did not change any features, they just added some
>> new ones but this was at the system level. End user level changes is
>> certainly not as hard and nor does it require the same level of
>> testing.
>>     
>
> If this is a routine thing, though - the automatic updating of
> userland apps - what do you do at the juncture where one feature is
> deprecated in favour of another? Implement both? Your current example
> doesn't ask for changes to featuresets so much as additions to it, but
> some updates are bound to. 
>   

Oh yeah for an LTS release. This is even done for system level packages 
never mind dependent packages. python, perl, glibc have all had cases on 
various distributions where two versions were install side by side with 
one being the default for the system. If you cannot migrate, then you 
very well implement both.

> Or, for example, when an automatic upgrade gives you Firefox 3.5, and
> breaks compatibility with several of your Firefox 3.somethingelse
> add-ons.
>   

That would a case for side-by-side.

> I'm not overly familiar with the range of userland applications that
> one might want to upgrade frequently, perhaps it is entirely possible
> to describe a collection which can always be upgraded without breaking
> anything, but I'd _always_ want my system to default to the side of
> caution. 
>
>   

Which is what installing side-by-side achieves if necessary.