Re: a "package-all" package

[Felipe Sateler <fsateler@gmail.com>]

Thibaut Paumard wrote:

> Hello,
> 
> I'm packaging an interpreted language, Yorick, and a bunch of add-ons
> for that language.
> 
> I'd like to provide a wrapper package that would depend on all the
> packages in this family present in main and suggest the one that is
> in non-free. I would like users to get a complete system with all the
> buzzes and whistles by typing
>   aptitude install yorick-almost-everything
> rather than
>   aptitude install yorick-dev yorick-doc yorick-imutil yorick-
> yeti...........
> 
> "almost" in the package name is their because I might miss recent
> packages, the package in non-free will in general not be installed
> automatically, and "almost" starts with an "a" so it's listed right
> after yorick in lexical order.
> 
> I realise that this package should be updated often, i.e. each time a
> new add-on enters the archive.
> 
> Initially, I wanted this package to be build from the "yorick" source
> package, which builds already yorick, yorick-data, yorick-dev and
> yorick-doc. But I wonder whether it's a good idea, because that would
> mean I would have to update the main "yorick" package each time I add
> a new add-on to the archive. On the other hand, it does seem silly to
> me to create a completely empty source package just for the sake of
> dependencies. I'm even wondering whether this package should be native.
> 
> Any opinions?

I'd say that in general, it is not such a good idea to make a metapackage
for packages from different sources, because it means all the problems you
listed.
In this case: why would you want to install *everything* yorick-related?
After all, users wouldn't want most of it, and developers can install what
they need to do their development (you don't see a C++-dev-all package that
depends on all c++ libraries ;).

-- 

  Felipe Sateler