[Debburn-devel] Suggestions

Eduard Bloch edi at gmx.de
Wed Sep 13 17:34:55 UTC 2006


#include <hallo.h>
* Nathanael Nerode [Tue, Sep 12 2006, 04:55:25AM]:
> (1) Merge changes made in dvdrtools.  dvdrtools forked from an even
> earlier version of cdrtools, and all the additions are GPLv2-or-later.

Which ones do you mean? Which ones do you miss?

You talk like we could just go, do a diff and patch and hey, it would
apply as-is and there would be no other work needed and everything is
easy and the sky is vanilla.

> (dvdrtools is in non-free solely because of the libscg "You may not" lines, which
> are *also* present in cdrkit.  Um.... there's some small problem there.)

If you see a concrete problem, point it out. Or stop talking like there
were a problem.

> (2) Strip out all the cruft related to support for Linux kernel interfaces
> other than the ones in Linux 2.6.

Why should we break portability or reduce our user base?

> (3) Drop support for obscure operating systems, starting with the VMS support
> files.  (All of those ".com" files are VMS build files -- there's no way those

Sorry for using hard words but it must be:
Bullshit. I am goint to port it to AIX (or better, fix our build scripts
and minor problems in the new iconv code).

> are going to stay maintained, so remove them.)  I think several of the
> proprietary Unices are clearly not worth supporting either.  You might want to
> just go all-Linux (or Linux + *BSD); do you really care about non-free OS support?

Some of us do. You are not among those who contributed good code so far,
why should we listen to you?

> (4) Phase out libscg altogether in favor of a 'new interface' of your own design.
> A new interface will allow the removal of the "You may not" lines, which will

Who is going to work on that? Or who would fund the complete
development? Unless you have good questions to those answers, I don't
see how dreaming of "new interface" is constructive. For the "good new"
development, look at libburn.

[ rest of rants deleted ]

> (5) btcflash should not be part of the 'cdrecord' package; it should definitely
> be a separate package.

We do not provide the cdrecord package. Go figure. It is even shipped by
another package in Debian. The code is just kept in the cdrkit source
because it may be of some interest for people, and because Joerg
Schilling made some extensions there (yes, for portability that you see
apparently not to care about).

> (6) Rather than using the built-in hacked-up libparanoia, dynamically link to the
> standard cdparanoia.

That item will be added to the TODO list. Someone needs to review
whether it is acceptable WRT portability. I assume that the Schily
version has been extended a bit.

> (7) Move the man pages to their own subdirectories instead of leaving them scattered
> amidst the source code.

I don't care. Any other opinion?

> (8) Move all the old cdrecord/cdrtools changelogs, NEWS files, announcements, etc. to
> one "old changelog" directory.  (a.k.a: get them out of the way)

What do you mean? There is an "ANNOUNCEMENTs" directory.

> (9) Break out mkisofs into an independent package; sever the links with
> wodim/cdrecord/etc.  mkisofs shouldn't be messing around with SCSI, so it has
> no excuse for using libscg, scsi_cdr.c, or modes.c (or indeed several of the other
> files it uses).

mkisofs has been an independent project ones. From what I know it has
been converted to use SCG methods instead of native open/close (though
the description is rather obscure, I am not sure this is really needed
on Solaris and libscg is really the only way to do it), and Schilling
prefered using his own functions instead of the common ones so the code
is a big mixture of libschily-using code and the usual things.

> This is apart from the existing suggestions other people have already made. :-)
> Clearly the first priority should be the elimination of libschily, since it should
> be relatively trivial.

Nathanael, send code, not uber-optimistic suggestions.

Eduard.

-- 
<formorer> 1762 OD  23.04.06 party-owner at ned (   0) Party Veröffentlichung von
	f15eweasel at marysden.com erfordert Bestätigung
<formorer> weasel, du sollst nicht meine Mailinglists zuspammen
<formorer> und was ist eigentlich ein ewasel?
<formorer> elektro weasel?
<rvb> formorer: Zitteraal mit Fell. :-)



More information about the Debburn-devel mailing list