[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] new virtual package names for optical discs burning applications



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 



Reply to: