Re: Dummy packages and metapackages (call for consistency in the descriptions)
On Wed, 02 Nov 2005, Andreas Tille wrote: On Tue, 1 Nov 2005, Henrique de Moraes Holschuh wrote: Well, I'd expect meta packages to have nothing on them Why? Was there any other definition than the link I posted that leads to this assumption? The link you posted has never bothered me before, I have zero contact with CDDs other than talking to Otavio a lot (and not about CDDs either). But from context, I'd assume that the link would tell me that meta package can contain non-metadata... (checks)... that's correct. Your links do *NOT* lead to the assumption that meta-packages only contain packaging system metadata, in fact, they are quite explicit on the opposite. And I don't recall ever reading any document that would lead me to believe that meta-packages contain useful packaged data (as opposed to metadata for the packaging system), other than the CDD URL you posted, and which I just read for the first time. Let me do something I should have done before: google-search for the earliest results of 'meta-package' in our lists. Read http://lists.debian.org/debian-policy/1999/07/msg00340.html. That was a huge deployment inside Debian, and it certainly fixed in memory what many of us expected meta-packages to mean: packages whose only function is to depend on/recommend/conflict/suggest others. I am quite sure these efforts (that begun well before 1997/07) were the source for the it contains only packaging system metadata definition of meta-package I am used to. I have found other uses of meta-package, most of them limited to one thread or another (and not something that hit the archive). Some of those implied packages that have content (such as lists.debian.org/debian-devel/1997/01/msg00268.html). After that (non-exaustive) search, IMHO it is CDD who is trying to change the meaning of meta-package, sorry. So, I still think CDD should drop the meta- prefix from anything that contains useful data. CDD meta-packages are really superstructure packages, IMHO you should name them accordingly. I personally have no problem with packages using the CDD definition of meta-packages *as long as* any and ALL package descriptions of either meta- prefixed packages, or that claim that a package is a meta-package, fully describe the package's contents so that it is obvious it has more than packaging metadata in it. Heck, maybe you guys already put all that information inside the package descriptions, I didn't check. What I mean with the above is, that a debian-med package would, if it includes meta-package anywhere in its description, also state that it includes menu definitions, configuration for other packages, etc. If it doesn't do it already, which it might. But I still like This is the Debian Med superstructure package better. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dummy packages and metapackages (call for consistency in the descriptions)
On Mon, 31 Oct 2005, Andreas Tille wrote: The meta packages builded by cdd-dev for instance contain data for building user menus which might override the menu entries of the dependant packages for the special purpose. This is definitely something else than debian/control but sounds to me definitely well placed in this kind of packages. Moreover the package might contain extra documentation for the dependant packages which seems to be reasonable in the meta package context. IMHO, drop the Meta prefix, then. There is no shame in doing so. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dummy packages and metapackages (call for consistency in the descriptions)
On Tue, 1 Nov 2005, Henrique de Moraes Holschuh wrote: IMHO, drop the Meta prefix, then. There is no shame in doing so. Well, just dropping the meta is a little bit to simple. There is an extensive documentation about the Custom Debian Distribution techniques and the tools that are used at http://people.debian.org/~tille/cdd/ It makes IMHO no sense to invent just another prefix in front of package instead of meta just because there might be some additional (optional) information inside these packages which is not contained in debian/control, but reasonably is called meta information for the relevant task. It makes no sense to play wording games just because there are some people who think that the definition we gave on http://people.debian.org/~tille/cdd/ch-technology.en.html#s-metapackages does not fit into the scope they would give the name meta package. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dummy packages and metapackages (call for consistency in the descriptions)
On Tue, 01 Nov 2005, Andreas Tille wrote: does not fit into the scope they would give the name meta package. Well, I'd expect meta packages to have nothing on them and I'd be surprised to find relevant data inside them. If you have to keep that meta, you'd better do some work on the package descriptions to make sure they make it very clear that the package has data inside it (other than packaging metadata, that is). This avoids bad surprises for others like me, that are used to meta-packages being packages of packaging system metadata only. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dummy packages and metapackages (call for consistency in the descriptions)
On Tue, 1 Nov 2005, Henrique de Moraes Holschuh wrote: Well, I'd expect meta packages to have nothing on them Why? Was there any other definition than the link I posted that leads to this assumption? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dummy packages and metapackages (call for consistency in the descriptions)
On Mon, 31 Oct 2005, Henrique de Moraes Holschuh wrote: The principle of least surprise, and the meaning of meta are good enough reasons for me to never have ANYTHING but debian/control in a meta package. If the package packages something, it is NOT a meta-package, it is a package. IMHO anyway. The meta packages builded by cdd-dev for instance contain data for building user menus which might override the menu entries of the dependant packages for the special purpose. This is definitely something else than debian/control but sounds to me definitely well placed in this kind of packages. Moreover the package might contain extra documentation for the dependant packages which seems to be reasonable in the meta package context. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dummy packages and metapackages (call for consistency in the descriptions)
On Sat, 29 Oct 2005, Adeodato [iso-8859-1] Simó wrote: Would it be unreasonable to ask that metapackages have to be _empty_, i.e., that all their functionality it's in their control file? As long as you give no reasons to do so I would in deed call it unreasonable. Kind regards Andreas. -- http://fam-tille.de
Re: Dummy packages and metapackages (call for consistency in the descriptions)
On Sun, 30 Oct 2005, Andreas Tille wrote: Would it be unreasonable to ask that metapackages have to be _empty_, i.e., that all their functionality it's in their control file? As long as you give no reasons to do so I would in deed call it unreasonable. The principle of least surprise, and the meaning of meta are good enough reasons for me to never have ANYTHING but debian/control in a meta package. If the package packages something, it is NOT a meta-package, it is a package. IMHO anyway. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debtags-devel] Re: Dummy packages and metapackages (call for consistency in the descriptions)
[originally to debtags-devel, reposted to CCs] Enrico Zini wrote: Thanks for this, Enrico! * Dummy packages It may be too late to standardise on transitional packages, but I've always thought that was more self-explanatory. * Metapackages Adeodato Simó wrote: Would it be unreasonable to ask that metapackages have to be _empty_, i.e., that all their functionality it's in their control file? Compare gcc, which works similarly to pull in a gcc-*. I recently found that I had only gcc-* installed on a machine, not gcc itself, with the result that a user's compiles failed - the /usr/bin/gcc symlink is in gcc! But gcc doesn't claim to be a metapackage; it's a dependency package. That's hardly self-explanatory, but I agree that it's a distinction worth making. Indeed, if dummy transitional packages were all called transitional packages, we'd be able to distinguish between dummy metapackages and ones that contain files... -- JBR Ankh kak! (Ancient Egyptian blessing) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dummy packages and metapackages (call for consistency in the descriptions)
Hi, * Metapackages A metapackage is one of those packages used to pull in other packages. If they are removed, it's likely that something goes wrong. They are used for various reasons, such as ensuring that one out of many versions of a package is installed (like the python modules do) or ensuring that a specific set of functionality is present (like the med-* packages). Would it be unreasonable to ask that metapackages have to be _empty_, i.e., that all their functionality it's in their control file? Because the idea of tagging 'python' as a metapackage, when it provides the Python FAQ, the Python Policy, and more importantly, /usr/bin/python, does not sound too good to me. Cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Military justice is to justice what military music is to music. -- Groucho Marx -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
