[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-devel
Subject:    Re: [RFC] new virtual package names for optical discs burning applications
From:       George Danchev <danchev () spnet ! net>
Date:       2006-11-21 18:21:29
Message-ID: 200611212021.31066.danchev () spnet ! net
[Download RAW message or body]

On Tuesday 21 November 2006 19:54, Hubert Chan wrote:
> George Danchev wrote:
> > On Saturday 18 November 2006 11:33, Adrian von Bidder wrote:
>
> [...]
>
> >> If they can't be used with the exact same commandline, there's no sense
> >> in providing these virtual packages because the programs need explicit
> >> support for each of those programs.  (And especially with these writing
> >> applications, arcane options need to be specified in many cases, so it's
> >> not a case of a common API with some few extra options a backend might
> >> use if it has specific support.)
> >
> > Fair concern, but this is also true for other already existing virtual
> > packages -- editor comes to mind. Isn't it more important what a
> > functionality is being provided, and not so important how it is provided.
>
> It depends on what the virtual package is meant for.  If it is meant for
> users, then command-line compatibility may not be so important (as long
> as it has a sane command line).  But if it is meant for dependencies
> from cd burning frontends, which may need to set all sorts of different
> options, then you definitely need command-line compatibility, or else
> those tools will break.

Such discriminations could be managed at the frontend's level and shouldn't be 
a problem since a decent frontend (i.e. client) might pass app-specific 
options (if there are any and it is really sensible to do so) to the 
low-level binary it spawns to actually do the burning.

-- 
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

[prev in list] [next in list] [prev in thread] [next in thread]