On Wed, 17 Dec 2008, Daniel Ruoso wrote:

It also allows one source package to generate different binary packages
(for instance, having scripts, libs and docs splitted), and makes it
easier to do an uninstall, because a "binary"/"installable" package
would have a fixed list of files.

I agree on the usefulness of a source distribution, but I'd argue that, as far as a binary distribution goes, we'd be better off turning everything into native packages, and building the binaries from there; from a Fedora point of view, there'd be a CPAN RPM repository; I'll leave you to figure out what it'd be from a Debian point of view.

In summary, I think inheriting most of the concepts from Debian is
something almost consensual, and there's much alignment in both
documents in that respect.

I agree with taking most of the concepts from Debian, but I'm afraid my point is being overlooked; I want to make an object that will model package data, whether CPAN packages or something else, and I want to try to support all Metadata that might reasonably be used by multiple package managers (as well as having an area for custom data). Pretty much everything I can see in the Debian spec is something I'd want to support as part of the main (rather than custom) data; the only exception is "Standards-Version", which I see as being Debian-specific.

To help give an example of what I'm talking about, the design document for the Perl5 version of this metadata model is here:


        Click on the number in the "Rev" column to see the actual document.

It would probably make sense to refactor S22 into a more spec-like document.

Agreed; it may need to be split into two, or something. I'll send a separate message to the list about it.


| Name: Tim Nelson                 | Because the Creator is,        |
| E-mail: wayl...@wayland.id.au    | I am                           |

Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI++++ D G+ e++>++++ h! y-

Reply via email to