Csillag Tamas wrote:
On Wed, Dec 28, 2011 at 02:28:13AM +0100, Ulrich Dangel wrote:
[...]
http://daily.grml.org:8080/job/grml64_Release/25/artifact/changelog.txt which has a removed section
I am a bit sad glancing on that list. Some of the tools removed are big (ok, so one can accept that and it can be justified), but most of them are small so from the size point of view it does not help if you remove.
Here is my take on the subject: As other members of the team have pointed out, these rather severe have been done because there we don't have the manpower to keep the large set of packages rolling properly. We do realise, that not everything may be perfect. But it is equally important, that everyone understands, that the few people who do the major work on rolling out releases (and I am not one of them by a long shot) on a fairly regular schedule only have 24 hours in a day, just like everyone else. The workload needed to be contained at a doable level.
That aside, I don't see the changes as being damaging, but rather as a chance. I agree that there are some packages that are missing. But it's only *now* that we get to know what these packages were. It is a well deserved cleanup of our list of packages, because we now get to see which packages deserve attention and which do not.
afio
Agreed. I used to have my backups handled with afio scripts. But there seems to be issues with afio copyright (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509287 for details) and there is no package in debian testing right now.
So that's kind of a little hairy. (But I'd like to see this packages included again, too, if that's possible at all.)
aircrack-ng
No official debian package. We can't maintain it. http://packages.qa.debian.org/a/aircrack-ng.html
Otherwise it might well be in.
awesome (i do not use this a friend does)
Yes. WindowManagers. Again. We won't be maintaining a proper configuration for awesome and we'd also like this particular part of the distribution to be more uniform than before. If you must have it, grml-live is your friend.
build-essential (so from now on building inside grml will be not that easy) gcc, g++ also gone...
I'm finding this a little sad too. But build-essential is probably not enough to build most stuff anyway. So you'll need to install stuff already and you can just install build-essential along the way with that.
comgt (180k)
Can probably included. Our very own jimmy is the maintainer of the debian package, even. ;)
dns2tcp (201k) (I am using this if I stay at a hotel with insane internet rates)
A bit specialised, but a debian package is available and it would be reasonable added functionality at the cost of a pretty small package. So, I'd be for including this.
emacs23 (this is a beast I know, more than one friend use this)
Yeah. No. Don't get me wrong, I'm an emacs user *myself*. But if you don't have your setup along, it's useless. Well, not useless, but way less useful.
I'd include `mg' which is a tiny emacs-like editor.
If you want emacs23 (or even 24) - again - grml-live is your friend.
fakeroot
What's the use-case here? I mean, including it would be possible, but I don't see what for, off hand.
firmware-qlogic (this means that it will not boot on server containing FC card?)
Hm. this one's non-free. I don't know what else is blocking that. Someone else would have to comment.
irssi
I'd like at least one IRC client on the ISO, too. It's useful for crying for help when something goes haywire. Irssi or epic are reasonable suspects, I guess. Maybe even weechat (although I think the default behaviour is insane).
ipmitool
Um, no idea... I guess this one wouldn't hurt.
ldapvi
Again, no idea.
libnet-*-perl
As a Perl hacker, I'd agree. But I don't know how much space this would take. Maintaining such a proper list wouldn't be trivial either, I'd imagine.
mutt
I don't know. Without setup, you can't do much with mutt. I think this is a clear case for a private package list and grml-live again.
postfix (I was using this for educating mailing basics also good for testing)
grml-live, I guess.
pppoe (no one with adsl anymore?)
Hm. Yeah. Maybe someone can comment on that one.
radvd
No opinion.
runit (520k)
What for? We don't use it.
rxvt-unicode (this was part or the release from the begining)
There's xterm. I wouldn't mind if this would be included. But I guess this is yet another candidate for grml-live.
tcptraceroute
I wouldn't mind
virtualbox
grml-live. Really.
tp_smapi
There were issues with dmks, IIRC.
zsh-lovers is your package afaik
Well, I don't really see the use on a simple disk. Never looked at it even once on there.
[...]
What kind of testing is needed to get (most/some of) the tools back on the cd? I used to be around on IRC, but when some folk switched from english I was unable to follow the conversation so I dropped out.
Well, it would be useful to do some research before requesting packages: Is there a debian package, is it free/non-free, are there any severe problems with it? Etc. etc.
And finally: I am not a fan of the grml96 ISOs and I was only realising that they existed after the release. Here is why I don't like them: The cleaned up package list leaves us with huge amounts of free space on a standard blank CD. It would be trivial to say "What, you'd like afio back? Well. No problem. Readded it. Get tomorrows daily image."
Now there is a new artificial limit: If we add a lot of new packages, then grml96 may overflow. And if that limits what we'd include in our images, that would be *quite* unfortunate to say the least.
I realise, that grml96 may contain a completely different set of packages then the single-arch package. But I wouldn't want to diverge too much, because it would lead to confusion and pain. And it's trivial to create a bootable medium with both architectures using, say, grml2usb.
Regards, Frank