Re: Bug#181028: cdrecord: promotes non-free software
#include <hallo.h>
* BenC [Sat, Feb 22 2003, 05:46:59PM]:
> > As said before, why not fixing SILO instead? You are the maintainer, I
> > expect an answer now.
>
> You have had an answer for as long as this argument has been around.
I cannot remember it and I cannot find anything in my mail archives,
only this:
|>From bmc@visi.net Wed Apr 10 18:17:44 2002
|
|>> >> If he intionally breaks the patch, I'll fix it up right. I'm closing
|>> >> this bug report. SILO is different, just like a lot of other boot
|>> >> loaders. Until I get time to rewrite that for SILO, this is the way it
|>> >> will be.
|>>
|>> So it looks nothing fom my old impression was wrong.
|>>
|>> Instead of investing 2-6 hours to fix SILO he rather likes to put 10 hours
|>> in a useless discussion and just tell other people that he is not interested
|>> in fixing a bad design :-(
|
|>I said I would fix it, but I have no time right now.
|
|OK, let's wait.
|
|J\366rg
|
| EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J\366rg Schilling D-13353 Berlin
| js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
| schilling@fokus.gmd.de (work) chars I am J"org Schilling
| URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
> Note, this is not "fixing" SILO, since SILO is not broken. It uses the
No, it is not broken, it just ignores Sun's conventions and implements a
different boot sequence.
> correct booting procedure, else the CD's would not boot. It's just that
> SILO requires that the first stage boot loader know the sector of the
> second stage boot loader.
As said, JS' arguments do sound better, and the descrition in
mkisofs(8) too.
> I am adrressing this as time permits, but that doesn't alleviate the
> fact that there is nothing wrong with the patch as-is.
Yes, I know, that universal excuse... Other developers defined even
better cludges as evil hacks and refused to accept them.
> > Pissing of the upstream by making changes without telling him is not a
> > good way go to. They have to deal with problems that our changes may
> > create - many people contact upstream first and not the Debian
> > maintainer.
>
> Allowing the upstream to dictate how Debian handles its internal affairs
> is also not ideal. It's a step into the wrong direction. No upstream
> author should ever feel they can dictate what happens to their software
I do not allow JS to dictate to much and we had many conflicts in the
past.
> after they release it. It is after all free software - the very core of
> which means it is open to changes outside the author's control.
And you are aware of the number of upstream authors that are not happy
with every distributor that modifies their software and release it in
modified form with the name of the author in the subject? Neccessary
modifications (like changes on the build system to get rid of non-PIC
code in libs) are okay, visible changes should not be done behind
upstream's back.
Gruss/Regards,
Eduard.
--
Wie man sein Kind nicht nennen sollte:
Karl Funkel
Reply to: