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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
