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

Re: Proposal: new virtual packages names

joost witteveen writes:
 > > As we already have several packages allowing to compile C code (gcc,
 > > altgcc, pgcc), and as we may have some more (egcs ?),
 > > 
 > > As we currently have (at least) 2 packages allowing to compile
 > > Fortran-77 code (namely, g77 and f2c),
 > > 
 > > As some packages need to suggest/recommend
 > > such compilers (cweb, fweb, etc.), 
 > > 
 > > I suggest to use the following virtual-packages names:
 > > 
 > > 	c-compiler
 > > 	fortran77-compiler
 > > 
 > > Maybe this should be extended to other langages as well.
 > > 
 > > Any comments ?
 > What's the goal of the Virtual Packages list? Is it to be as
 > complete as possible, or just to serve our needs?
 > I've always thought it to be the second (to be a minimal list that
 > allows us to specify the dependancies properly). If so, do you know
 > any packages that would like to depend on "c-compiler", or 
 > "fortran77-compiler"?

Yes, as stated above: fweb (which I happen to maintain), and then
probably all literate-programming tools, which produce code to be
compiled. IMHO, generated C/F77/whatever code is useless if you don't
want to compile it.

Hence the Recommends field from fweb, which I don't want to update
each time a new compiler is packaged:

> Recommends: latex, gcc | fort77 | g77 | ratfor77
> Should-Recommend: c-compiler | c++-compiler | fortran-compiler | ratfor-compiler

Note that the fact we now have 'pgcc' packaged makes this field
obsolete, and I should update it, thus uploading a full binary
package, which will differ from the present one only by this very

Really, I prefer to do it once and for all...

 > If we want a complete list, I'm sure we can come up with much more
 > examples. And, why stop with languages that have less than two
 > compilers? Surely a complete list also provides for the possibility
 > of other compilers to appear? So, if this were the aim, I'm sure
 > there will be a storm of new vritual packages, that will never be used.

Yes, sure. But here the only one that may be useless is
ratfor-compiler, which AFAIK would be provided by only one
package. But maybe I'm even wrong here.

 > So, to be practical, I'd say: only define a new virtual package
 > if you can show us why anyone would need it, not when you can
 > show us that it's possible to create it.

Is this demonstration sufficient ?

Yann Dirson  <dirson@univ-mlv.fr>        | Stop making Bill richer & richer,
alt-email: <ydirson@a2points.com>        |    support Debian GNU/Linux:
                                         |       more powerful, more stable !
http://www.a2points.com/homepage/3475232 |

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: