Hi there,
I'm always interested in pure Debian based Live-CDs. I was half way building my own read-only root fs, when I noticed grml. I wish I had known it earlier. I have to say grml is exactly the type of Live distro that I've been looking for for a long long time. Browsing through the web site, I know it has got lots of publicity in the German speaking world. But I think it lacks the equivalent publicity in the English speaking world. In summary, such nice distro deserved to have more people to know and use...
Ok, here are my questions.
I'd like to know the philosophy behind the grml releases. I used to use Debian testing, but recently revert to stable because the vulnerability of Debian testing. So you know I'm always on the cautions side. I know Knopsis, Ubunto does a lot of QA testing before the release. How about grml? Seems to me that grml pick its release packages only based on the cut off date. How about the problems/errors that inherited from the packages of the cut off date? Can't imaging so many tools will have one perfect day to be error free. Do you revert several versions back on those packages that have problems? In short, Debian unstable always has the potential to be unstable. What's the mechanism in place for grml to avoid it?
thanks
tong
* T mlist4suntong@yahoo.com [20060628 20:55]:
I'd like to know the philosophy behind the grml releases. I used to use Debian testing, but recently revert to stable because the vulnerability of Debian testing. So you know I'm always on the cautions side. I know Knopsis, Ubunto does a lot of QA testing before the release. How about grml? Seems to me that grml pick its release packages only based on the cut off date. How about the problems/errors that inherited from the packages of the cut off date? Can't imaging so many tools will have one perfect day to be error free. Do you revert several versions back on those packages that have problems? In short, Debian unstable always has the potential to be unstable. What's the mechanism in place for grml to avoid it?
I'm running several quality checks. I run daily updates and report problems to the Debian Bug Tracking System (BTS).
I also maintain an "upgrading webpage" in the grml-wiki:
http://wiki.grml.org/doku.php?id=upgrading
The site is up2date at least from release to release. Unstable does not mean that the software has to be unstable but that the package pool is the unstable part of it. So the uncomfortable stuff is the package upgrades, not the software itself. ;)
Therefore: before grml 0.8 will be available I'll make a full upgrade from a grml 0.7 system and check what's failing. If something is failing I'll report it to the BTS. If it isn't fixed when next grml version is coming I do provide a working package/instructions how to solve it. To upgrade all relevant grml-packages a virtual package named 'grml' exists. Upgrading all grml related stuff from one release to the next one is possible therefore via running:
# apt-get update ; apt-get install grml
It won't touch the installed kernel and as we do maintain the grml-packages on our own (and test them before they are going into a public release) this upgrade process can be considered as stable.
Between the stable release I provide several develreleases to grml developers and betatesters (see http://grml.org/beta-tester/ for details). And of course I (and several grml developers and users) use grml at work, at home,...
regards, -mika-
Unstable does not mean that the software has to be unstable but that the package pool is the unstable part of it. So the uncomfortable stuff is the package upgrades, not the software itself.
Dear Friends,
I am repeating, re-iterating and re-quoting this because, for those who are new to either grml or using debian unstable, this needs to be the first sentence one reads.(Thals, M - I shall plagiarise often ;) )
It is hard to explain that the unstable repository is not an repository of unstable software, but an unstable repository of software where dependencies might or might not be met, and the normal debian stable guarantee of easy apt-get installation does not apply.
As to the relevance of this to grml, there is none, in se, as the same issues would apply to any pure debian installation where apt was used with unstable sources.
The main difference is that when we, whether programmer or newbie, ask for help on this list, the questions are both taken seriously and answered courteously. We, the noobs, try in return not to bug the developers with issues unrelated to grml.
We do anyway, and are bloody grateful for the patience of Mika and the whole team.
best, M
Thanks for the explanation, Michael.
On Wed, 28 Jun 2006 21:30:51 +0200, Michael Prokop wrote:
I'd like to know the philosophy behind the grml releases. I used to use Debian testing, but recently revert to stable because the vulnerability of Debian testing. So you know I'm always on the cautions side. I know
The reason that I'd like to know this is because I am seriously considering using grml, ie grml2hd, as my working environment. So I need to assess the full impact before I jump the ship.
To upgrade all relevant grml-packages a virtual package named 'grml' exists. Upgrading all grml related stuff from one release to the next one is possible therefore via running:
# apt-get update ; apt-get install grml
It won't touch the installed kernel and as we do maintain the grml-packages on our own (and test them before they are going into a public release) this upgrade process can be considered as stable.
Between the stable release I provide several develreleases to grml developers and betatesters (see http://grml.org/beta-tester/ for details). And of course I (and several grml developers and users) use grml at work, at home,...
So far, my understanding is as follows. Please correct me if any of the following statements in not true.
- grml makes use the official Debian unstable packages, which means the grml2hd will give you a pure Debian unstable environment, not a hybrid one like Knoppix.
- having set proper apt-source, one can start install from official Debian unstable repository right way after the grml2hd.
- grml has a virtual package named 'grml' that define all the package' versions that the release uses.
- the virtual grml package can help upgrade grml system by a single apt-get install
- grml maintains all its release packages in its own repository, which can help insulate any problem occurs in the official Debian unstable repository
- In general, grml's own repository stays stable, and is only updated for new grml release or develreleases.
- the virtual grml package, which defines all the package's versions that the release uses, help the grml grml2hd system stays stable between releases, even the official Debian unstable packages have moved along.
- grml's own repository contains only the packages that are released to cd.
Are all above correct? If so, please consider the following situation.
The official Debian unstable repository has moved along, while grml's own repository stays the same. I need to install a package that is not in the grml's own repository, but the one in the official Debian unstable repository required a certain grml package(s) to be upgraded. How would the situation be handle? Triggering a cascade of upgrading, or refuse to install the new package?
please help
thanks
On Sat, 01 Jul 2006 13:51:39 -0400, T wrote:
The official Debian unstable repository has moved along, while grml's own
If I removed a package by mistake, how can I install the original one?
For example, I removed the psad by mistake, when I re-install it, I get:
grave bugs of psad ( -> 1.4.6-1) <done> #357253 - psad: kmsgsd segfaults Summary: psad(1 bug) Are you sure you want to install/upgrade the above packages? [Y/n/?/...] n
please help
thanks
* T mlist4suntong@yahoo.com [20060702 19:45]:
On Sat, 01 Jul 2006 13:51:39 -0400, T wrote:
The official Debian unstable repository has moved along, while grml's own
If I removed a package by mistake, how can I install the original one?
For example, I removed the psad by mistake, when I re-install it, I get:
grave bugs of psad ( -> 1.4.6-1) <done> #357253 - psad: kmsgsd segfaults Summary: psad(1 bug) Are you sure you want to install/upgrade the above packages? [Y/n/?/...] n
Well, how about pressing 'y' instead of 'n'? 8-)
regards, -mika-
Incoming from T:
On Sat, 01 Jul 2006 13:51:39 -0400, T wrote:
The official Debian unstable repository has moved along, while grml's own
If I removed a package by mistake, how can I install the original one?
For example, I removed the psad by mistake, when I re-install it, I get:
grave bugs of psad ( -> 1.4.6-1) <done> #357253 - psad: kmsgsd segfaults Summary: psad(1 bug) Are you sure you want to install/upgrade the above packages? [Y/n/?/...] n
That's apt-listbugs telling you there's been a grave bug filed against the package. So, based on that information, what do you want to do? If you've never seen it segfault, or if that doesn't worry you too much, go ahead and say "y". What have you got to lose? It might work alright or it might segfault. Woohoo.
On the other hand, if the bug mentions "remote root exploit", you might want to reconsider just how much you want it.
* s. keeling keeling@spots.ab.ca [20060702 20:05]:
Incoming from T:
On Sat, 01 Jul 2006 13:51:39 -0400, T wrote:
grave bugs of psad ( -> 1.4.6-1) <done>
^^^^^^
That's apt-listbugs telling you there's been a grave bug filed against the package. So, based on that information, what do you want to do? If you've never seen it segfault, or if that doesn't worry you too much, go ahead and say "y". What have you got to lose? It might work alright or it might segfault. Woohoo.
On the other hand, if the bug mentions "remote root exploit", you might want to reconsider just how much you want it.
The bug has been closed already. Nothing to care about...
regards, -mika-
Incoming from Michael Prokop:
- s. keeling keeling@spots.ab.ca [20060702 20:05]:
Incoming from T:
On Sat, 01 Jul 2006 13:51:39 -0400, T wrote:
grave bugs of psad ( -> 1.4.6-1) <done>
^^^^^^The bug has been closed already. Nothing to care about...
Learn something new everyday. :-)
participants (4)
-
Martin Yazdzik -
Michael Prokop -
s. keeling -
T