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
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 <email@example.com> | Stop making Bill richer & richer,
alt-email: <firstname.lastname@example.org> | support Debian GNU/Linux:
| more powerful, more stable !
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to email@example.com .