[Debburn-devel] Suggestions

[Christian Fromme]

On 12.09. 04:55, Nathanael Nerode wrote:
> (1) Merge changes made in dvdrtools.  dvdrtools forked from an even
> earlier version of cdrtools, and all the additions are GPLv2-or-later.

Sounds good to me, but I don't know the dvdrtools code well enough to
make a useful statement to this. Maybe someone else can enlighten us
here?

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

The support of architectures was already discussed and is still being
discussed but no definite decision has been made to this point. It is
likely that some archs will be dropped sooner or later.

> (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
> become totally irrelevant.  The libscg interface is bizarrely Solaris-centric, and
> also excessively old-style-SCSI-centric, because it's a direct emulation of a hardware
> interface.
> 
> >From the TODO for dvdrtools: 
> "- Better support for writing directly to device files, without having
>    to create fake SCSI bus mappings"
> 
> This will mean that Solaris support would require a translation layer, but that
> can be provided as soon as a Solaris user cares.  :-)
> 
> (6) Rather than using the built-in hacked-up libparanoia, dynamically link to the
> standard cdparanoia.
> 
> (7) Move the man pages to their own subdirectories instead of leaving them scattered
> amidst the source code.

Sounds good to me mostly. The suggestion about the manpages definitly
makes sense.

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

This is also part of current discussions [as is your suggestion to split
btcflash]. So far, nothing has been definitly decided.

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

This is being worked on.

Thanks alot for your suggestions, Nathanael. Keep in mind that we all do
this as part of our free time and we have other jobs as well, so don't
expect wonders here. That being said, I personally think that most of
them are useful from a technical perspective, so we should at least
discuss them, if not already done so.

Best wishes,
Christian