Hi Paul, On Fri, Aug 05, 2011 at 04:28:37PM -0500, Paul Elliott wrote: > On Friday, August 05, 2011 10:35:11 AM you wrote: > > Hi Paul, > > > > > What you want is not a virtual package but rather a meta-package. See > > xserver-xorg for example (or texlive or libreoffice) which pull in > > submodules from a central package that holds only central information or > > even only puts the Depends (like the gnome and gnome-desktop-environment > > package too). > > > > That way you can break apart sensible chunks into separate packages (up to > > 54) and join them back with the central "give me everything" package > > (which would be no. 55 at worst). > > > > I doubt however that it'll make sense to break apart more than ~10 packages > > but I'll leave the decision up to you or someone more experienced with the > > daily usage. > > A metapackage is basicly a package that does nothing but depends on other > packages, so that installing a metapackage forces a combination of other > packages to be installed. Right. > So if I created one package for every SE file, then I could define a metapackage > SE-data-all that would depend on all of them. Some one else could define a > packages that only depends on the modern data, SE-data-modern. Correct. > The problem with this is that it requires me to package each file individually. > I hoped to avoid doing this. They all still come from the same source. Not sure we're talking about the same thing here. I was referring to one source and spitting out a number of (binary) packages plus one/many meta-packages. That way all you need to do is put together goups or individual files as one binary package each. If you want to, you can script this to generate debian/control from a debian/control.in template and run it from the clean target. The pkg-gnome team uses something alike for setting Maintainer etc.. > If I define one virtual package for each file, I don't have to individually > package each file. I can create one package that provides and conflicts > with each individual virtual package=file and has a copy of all the data and > call this SE-data-all. From what I'd expect this is not as scalable. Can you sketch up a mini-example debian/control for what you have in mind? > Someone else later could create a package that contained only the modern data, > that would provide and conflict with each virtual package for which the > coresponding file contained modern data and in would include only those files. > They would call this SE-data-modern. Not sure what you mean here why this is someone else. Anyway, package names in Debian are always lowercase. > Application programs could decide which virtual packages they wanted to depend > on and recommend. > > Thus the maitreya astrology program could depend on the modern data and > recommend all the other. They can just do the same with meta packages. > At first my SE-data-all would be the only data package in existance, so > maitreya would be forced to bring in all the data. But if someone later > created SE-data-modern, the installer of maitreya could force only the modern > data to be installed for a low diskspace application even though all the data > would still be recommended. That sounds exactly like what meta packages would achieve. Just keep in mind that the default in Debian with both apt-get and aptitude is that Recommends is installed just like Depends. Only Suggests isn't. > My original question is, is this a legitimate use of the virtual package > concept? IMHO no. Virtual pakges are for "httpd" and "mail-server" and such where different functions are delivered to a system by totally different architectural and programmatic concepts yet their interface is the same among a number of packages. I'd still say what you want is a meta package. [...] -- Best regards, Kilian
Attachment:
signature.asc
Description: Digital signature