When should a package be ubuntu-versioned?

[Stephan Hermann]

Hi Mike,

On Tuesday 03 January 2006 20:38, Mike Bird wrote:
> On Tue, 2006-01-03 at 11:00, Stephan Hermann wrote:
> > You are alone when you do this, and you have to support your own mess.
>
> I haven't called your favorite distro a mess, so why do you call a
> configuration with slightly fewer bugs a mess?  

Because it's not the original distribution anymore. You stand alone with this 
configuration.

> Rather than flaming 
> "mess", what solution would you suggest when a combination of needed
> features is not available in a single release?  Put the firm's
> employees on a six-month hiatus?

Well thinking in real life terms, there are different solutions:

1. I'll postpone the upgrade and staying with my old distro, which is working.

2. I'll postpone the upgrade and staying with my old distro, and try to give 
the distro developers some hints, that there is software which is broken.

3. I'll postpone the upgrade and staying with my old distro, and try to give 
the distro developers some hints, that there is software which is broken. 
Most likely I'm a paid support customer which can call the creator of the 
distro and tell him to fix this for the released new OS, and the creator will 
send you a fix and finally the fixed software will hit the distros archives.

4. I'll postpone the upgrade and trying to fix the bugs myself in a distro 
related work afford. Means, installation of the to be upgraded OS, install my 
needed applications, and check if they are working or not. If not, I'll try 
to fix them, because I know, on my old OS it was working, so I'll check what 
is the difference in the source of the old and the new package. After 
figuring this out, I'll prepare a package with the patches applied to the new 
software and compile this package, install it, and test again if it is 
working as expected. If so, I have a patch which I can send to the distro 
developers via bugzilla/malone/whatever and if it's an upstream problem, then 
I send my patch upstream.

5. I'll install the minimum needed set of packages of my OS, and compile all 
software for myself and put them into an internal repository, from where all 
other servers/desktop can fetch the packages. 
(and this is something really hard, but working solution, which needs at least 
some sort of knowledge and some resources, but it exists in real working DC 
environments)

But, to be honest...point 4 and 5 are expecting more knowledge of the software 
and the system from the system administrator, means you should have more then 
>3 years of working experience in this environment.

Point 1, 2 and 3 are more sane then 4 and 5, and they are compatible with 
corporate/DC environments.

> Support for techies is Google, source code, and mailing lists - in
> that order.  You test the plausible solutions, select the best, and
> then deploy.  It's the same whether you're pinning or editing conf
> files or recompiling or dist-upgrading or whatever.

We are talking about serious corporate/DC environments or just an environment
with one administrator who thinks he is not replaceable?

> Now the non-techie shouldn't be pinning or editing conf files or
> recompiling or dist-upgrading or whatever, but the non-techie's tech
> will pin or edit or recompile or dist-upgrade or whatever as needed.

Well as I said, the non-techies tech will pin, edit, recompile because he, the 
non-techies tech, thinks he is not replaceable. Which is most propably wrong 
and the team lead of this non-techie tech should think about replacing this 
tech very soon to avoid more dangerous actions of this non-techie tech.

This is not a flame, Mike, but believe me, I'm working >13 years in this 
business, and I made all mistakes someone can manage to make, but the good 
thing is, everyone is learning of his/her mistakes...the first lesson someone 
will learn is, that even if someone was creating such a mysterious secret 
about his/her system administration, that it is of no good for the 
collaborative work of a team of sysadmins. Especially when you think of "a 
sysadmin is a lazy bastard in things like documentation". So, having a clean 
and sane environment is a big plus for everyone working with this system. 

Mixing binary packages on a productive machine is always the wrong way to 
achieve the goal. If the to be upgraded OS has problems, which someone can 
only figure out with tests, then someone has to make sure, that this problem 
is reproduceable, the fix is already somewhere in the old package, and that 
someone will report this to the well known channels of the distro, means BTS.
Most of the time, the fix is an easy one, because the developers can compare 
the two versions of the source and fix the new source accordingly. They will 
move the fix then to the archives, and the sysadmin can upgrade his OS later.

Regards,

\sh