Hi!
And sorry for not-replying to the first mail, I was very busy with
some stuff and the mail somehow fell through the cracks.
> Le Sat, Jan 05, 2013 at 05:16:38PM +0900, Charles Plessy a écrit :
>> Dear DEP 11 drivers and everybody,
>>
>> in the course of the discussion about DEP 12, which is about storing upstream
>> metadata on file per source package, formatted in YAML, it was asked the
>> relationship between our projects and the possibilities of convergence.
>>
>> Personally, I am in favor of convergence if it is practical, that is, if it
>> does not postpone the achievement of our goals by setting the bar too high.
>>
>> I note a couple of key differences between DEP 11 and DEP 12, and would be
>> interested in hearing your opinion about.
>>
>> - DEP 11 targets binary packages, and DEP 12 targets source packages. For
>> DEP
>> 12, recording the information per binary packages would create a lot of
>> duplication. One solution would be to use the Debian source package
>> control
>> file (debian/control), with the fields in the binary package paragraphs
>> taking
>> precedence over the fields in the header paragraph. However, following
>> that way would strongly change what a source package control file looks
>> like,
>> and I am afraid that it would take a long time to reach a consensus.
DEP-11 describes technical details of binary packages, e.g. which
Python-modules they contain, which libraries are in it and (important
for AppStream) the data of any application present in a binary
package.
>> - DEP 11 is mostly about the production of a single archive-wide file, while
>> DEP 12 is about the production of one file per source package (which is
>> used
>> to feed the Ultimate Debian Database). It would be straightforward for
>> volunteers to take upstream metadata and inject it either the
>> ComponentMetadata
>> file proposed by DEP 11 or in another file. Given that DEP 12 is only
>> about
>> the format of the metadata, I do not see a conflict here.
DEP-11 is mainly autogenerated data (if not only). Users don't have to
inject any new data, as everything is extracted by automatic tools.
>> - DEP 11 looks mostly relevant for binary packages shipping Desktop
>> applications, while DEP 12 is relevant to all non-native packages. It is
>> still very unclear to me what will be the source of the data in DEP 11.
>> Will
>> it be the FreeDesktop Desktop Entry files found in the upstream sources ?
>> If
>> it is the case, we would have different data flows, as for DEP 12, most
>> upstream sources do not contain files with the metadata, which justifies
>> the
>> creation of an entirely new file, while in the case of DEP 11, the best
>> way to
>> update the metadata would be to send patches upstream.
I think DEP-12 extends DEP-11 with some extra upstream metadata which
we cannot extract.
DEP-11[1] consists mainly of two tasks:
* Provide application data for binary packages (app name, icons,
etc.) to be used in a software center
* Provide component metadata, such as contained mime information,
python modules, library etc. to describe the contents of binary
packages in a distro-agnostic way.
DEP-11 is not designed in a way users would have to inject new data. I
am not sure if adding upstream data makes sense, as the extra file is
limitted to applications, and DEP-12 covers all source packages.
However, some of the DEP-11 data could maybe be used to extend DEP-12
data automatically.
Cheers,
Matthias
[1]: http://wiki.debian.org/DEP-11
--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caknhny83qm2eln_faajk_w9v6dwk6tlj27g50eg0fhdwuuc...@mail.gmail.com
