[Grml] Re: Debian Etch and grml

[Marc Haber]

On Sun, Jan 14, 2007 at 01:37:02PM +0100, Michael Prokop wrote:
> * Marc Haber <mh+grml at zugschlus.de> [20070113 14:15]:
> > On Mon, Jan 08, 2007 at 11:17:18PM +0100, Michael Prokop wrote:
> > > I'm of course aware of 'We have never claimed that sid is ready to
> > > be used by end-users' - but I think reality shows something else in
> > > common practice.
> 
> > It's always the same problem during our release cycle: After a
> > release, many people use stable. Stable gets old, while sid goes
> > throught the usual heavy development phase where things sometimes go
> > badly wrong. While stable gets stale, sid's breakages get less and
> > less, while end users migrate from sta(b)le to sid because they want
> > later software (or get misled by media reporting that apt pinning is
> > going to get them the advantages of stable and sid together while in
> > reality they only get the disadvantages of both combined). These
> > migrations are supported by third parties saying "use sid, it's
> > stable!".
> 
> ACK
> 
> But: about half a year before and >=half a year after the release,
> stable might not even boot and therefore d-i won't be able to
> install Debian at all.

If we continue with installer releases like we currently do. I think
we need to offer backported installers, or at least a stable installer
with a current kernel (and of course less support).

AFAIK, the unstable installer can be used to install stable as well,
which might be a way to have stable (with a backported kernel) for
these people.

>  People usually don't buy hardware according to Debian stable release
>  cycles. ;) Therefore stable won't work for people with brand new
>  hardware besides a narrow time-frame of the new release.

Fortunately, a lot of newbies use older hardware for Linux.

> But: IMO today unstable isn't the unstable you were used to get a
> few years ago. A few years ago unstable was broken on a regular
> base.  Nowadays unstable is even less broken than the update
> (procedures) of some so called "stable distributions" (count M$
> Windows as well). I suspect it's mainly because stable has its
> market on the servers and unstable has its market on the
> workstations (the ones without commercial support).

I disagree here. There is bad breakage in unstable.

> > If they are technically knowledgeable, they can go ahead with Debian
> > sid or Debian testing, helping development by reporting and even
> > fixing bugs. If they are not technically knowledgeable, they are
> > better off with a distribution geared for the Desktop such as Ubuntu
> > or OpenSUSE.
> 
> People considering Debian as their main operating system often have
> a reason why they chose Debian and not Ubuntu or OpenSuSE. ;)

So they are deliberately choosing a distribution that might not suit
their needs best.

> > >  You get this with Debian unstable quite well nowadays as all of you
> > >  might know. :)
> 
> > Yes, but you also get the latest breakage. Which you might not be able
> > to fix if you don't know your way around a broken Linux system very
> > well.
> 
> Yes, but the "latest breakage" isn't on a high level nowadays IMO.

It can be on very low levels during some stages of the release
process, such as right after a stable release when everybody puts the
lastest developments into unstable.

> Most problems of upgrading an unstable system can be fixed with the
> two notices mentioned in section "Common Debian unstable problems"
> of http://wiki.grml.org/doku.php?id=upgrading

These are the most trivial problems that are trivially fixed.

> If the user has problems with a special package and knows about
> http://bugs.debian.org/$PACKAGENAME he usually finds a detailed
> bugreport (often including a workaround) as well.

How does the user do this when she cannot log in to her primary
computer?

> An important point I forgot to mention is the user-support:
> 
> A KDE developer (who uses grml as base system, hello Kevin :)) I was
> talking to reminded me of the issue "support for newbies".  Upstream
> developers and supporters of software usually don't provide support
> for ancient software versions.

While this is for example understandable for exim 3, which has been
obsoleted upstream by exim 4 some five years ago, this is ridiculous
for some KDE apps which do not get upstream support because it is four
weeks old.

>  Bugreports
>  for older software versions might not be accepted or are answered
>  with "please reproduce with current version". So the next step for
>  the user might be to upgrade his stable system to testing (bad
>  choice) or unstable.

The next step for the user might be to use VMware or a chroot to
reproduce the bug with a current version there. Or to try a backport
of the unstable package to stable.

Btw, these methods are _great_ to learn about Debian and Unix in
general and help in accumulating the skills necessary to run Debian
testing or unstable.

>  Now the user can get support from upstream. (JFTR: I'm talking about
>  end-user support of course, not package maintainence support!) So IMO
>  that's another reason why unstable is so common on workstations.

Yes, but that's a misled reason. Upgrading a productive system to an
unreleased development version just because joe random developer does
not care about what he released four weeks ago is a bad idea.

> > I have heard that Debian plans to issue (unofficial) stable intaller
> > releases with later kernels.
> 
> That's good, but this should have happened before Ubuntu reached the
> market. ;) But unofficial usually means "nobody except developers
> and people who know how they might fix the problem anyway will find
> the ISOs".

Not communicating clearly enough is a classical problem within Debian.

While Ubuntu does bad things to Debian (for example by keeping peopleh
holding key positions in Debian from doing their work), it also does
some good things, for example taking the most clueless of newbies away.


>  (Reminds me of the security-support within Debian testing...) :(

Yes, that's an entirely different story.

> > > Oh, and even developers (I do not mean DDs only here!) have the need
> > > for recent software: compiler versions, libraries,... - stuff you
> > > just might not get with Debian/stable.
> 
> > I have done development quite successfully in chroots, and developers
> > are usually able to fix breakages (and thus qualify for sid).
> 
> You are talking about developer like in "debian developer" for your
> chroot actions, right?  I'm talking about "plain" *software*
> developers. They usually don't want to do their daily business
> inside a chroot.

Why? If set up properly, you wouldn't even notice. In the chroot, you
can do anything you see fit without endangering your primary vehicle
of work.

But, plain software developers usually have debugging and bug fixing
skills, so I am inclined to call them "qualified for unstable".

> > > Finally just think of DD that maintain core software packages and
> > > don't even use the Debian kernel. ;)
> 
> > You mean, like me?
> 
> Well, you might count yourself ;) but I was trying to point into the
> direction of udev....

I see.

> > I used to do this until June 2003, where a change of workplace made me
> > install a new workstation. I used unstable there for the first time.
> 
> But how many DDs use stable as their main platform to work with the
> packages they maintain *nowadays*? I'm not aware of any official
> stats but I'm sure most of them don't use stable as their main
> working system.

Sure. But they're developers. They're supposed to work with
development versions of Debian.

> > I use grml to install a tarball containing a Debian system on my
> > servers. I rarely use the Debian installation methods.
> 
> Ok, the method itself isn't that important as you get an up2date
> kernel with grml which lets you boot the system for further actions. ;)

Indeed. And grml is a fabulous tool for doing so since its hooks into
the startup process are so versatile that I am frequently using grml
to install Debian on machines I have never physically seen.

> > >  and grml-users on the other side don't have to run "daily" updates to
> > >  be sure to be able to follow the Debian/unstable pool. They can wait
> > >  ~2-3 month until a new grml release is available and be sure that the
> > >  upgrade works quite well then.
> 
> > How are security issues in packages available with grml handled?
> 
> Package updates deriving from grml itself are uploaded to
> grml-stable pool.

This is good.

> Packages not originally deriving from grml itself can be found in the
> Debian/unstable pool - as usual (=> debsecan).

This is not good. Reasons: There are no security advisories for Debian
unstable, and a security-fixed package version might depend on other
libraries. So, grml users are basically forced to track Debian
unstable and get unstable's breakage. Which, unfortunately, kind of
proves my point that grml's stability is only guaranteed in a short
time frame after a grml release.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835