[Grml] Re: Debian Etch and grml

[Michael Prokop]

* Marc Haber <mh+grml at zugschlus.de> [20070116 13:15]:
> On Sun, Jan 14, 2007 at 01:37:02PM +0100, Michael Prokop wrote:
> > * Marc Haber <mh+grml at zugschlus.de> [20070113 14:15]:

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

ACK

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

True for workstations, but IMO not true for notebooks.

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

Yes, but that's something that can be communicated to newbies too
(or they experience it on their own and hopefully learn from that ;)).

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

Jepp, but they are the most common ones too.

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

*I* for example have never ever experienced something like that.
Of course that's a worst case where more experienced users have to
help the newbie to fix such a breakage.

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

Just think of the big KDE version steps between woody (2.2.2) and
sarge (3.3.2).

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

I wouldn't call a user that uses VMware on Linux or has a running
and working chroot system a newbie, sorry. :)

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

FullACK

> >  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 don't mean a time frame of just four weeks, again - just think of
KDE in woody vs. KDE in sarge.

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

ACK

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

ACK, but I just think that it's not common practice. (Feel free to
correct me. ;))

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

Jepp, that's why they usually use unstable. ;)

[...]

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

'debsecan --suite sid' works fine for me.

regards,
-mika-
-- 
 http://grml.org/            # Linux for texttool-users and sysadmins
 http://wiki.grml.org/       # share your knowledge
 http://grml.supersized.org/ # the grml development weblog
 #grml @ irc.freenode.org    # meet us on irc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://ml.grml.org/pipermail/grml/attachments/20070116/2a54d4b4/attachment-0004.pgp>