Re: Additional fields in debian/upstream?
Hi,
Petter Reinholdtsen wrote:
> This sound like a similar goal of my proposal to add CPE information
> to the Debian packages. Check
> <URL:http://wiki.debian.org/CPEtagPackagesDep> for the current draft
> of that proposal.
>
> Perhaps we could come up with a common proposal that fulfill both
> goals?
>
> My initial idea was to put the information in the Packages file, to
> allow it to be easily used on every Debian machine. Perhaps it is a
> better idea to put it ino debian/upstream? Btw, you should remember
> that some packages have multiple upstreams (for example packages with
> external libraries included in the tarball).
This is indeed the same problem. In the past I have seen opposition
against blowing up the Packages files with more info (although I agree
that this is the most convenient solution) -- so I guess that
debian/upstream would be the best compromise.
So I guess we are talking about a general purpose field (plus sub
fields) for mapping source and/or binary packages to a set of arbitrary
IDs representing some sort of alternative name of a particular
component/package in some other universe:
Examples:
source/binary package name -> CPE
source package -> freshmeat/source forge/... ID
binary package name -> binary package name in Fedora, Gentoo, ...
There are other people aiming for solving these kinds of problems too,
of course. But for the sake of coming to a viable solution in a
reasonable time frame I think we should limit our focus on asking what
kinds of mappings we want to allow:
ONLY: source package -> something
OR ALSO: binary package -> something
Depending on such decision, we would need to look into drafting a field
SPEC.
For this first case it could be something like:
AKA/Also-Known-As:
CPE: ...
SourceForge: ...
Gentoo: ...
NeuroLex: ...
The list of possible subfields would need to be maintained somewhere
(wiki?), but there should be no need for limiting the collection to
a particular subset.
Thoughts?
Michael
--
Michael Hanke
http://mih.voxindeserto.de
Reply to: