Re: more formally indicating the registration URL
Andreas Tille wrote:
> On Wed, Aug 05, 2009 at 11:38:02AM +0900, Charles Plessy wrote:
>> I have been thinking a bit on the issue. How about the following workflow:
>>
>> - Create a new file with a ???Name: contents??? field syntax in the Debian source
>> packages, for ???online meta-data??? that typically require internet access to
>> be useful.
>
> Sounds reasonable.
I agree.
Could we somehow prototype what we want to achieve?
>
>> - Write a script to use this file to feed the Ultimate Debian database, that
>> would be authoritative. This way, the meta-data does not need to be added to
>> the Packages and Source files of the Debian mirrors.
>
> While it makes sense to create an UDD table featuring
>
> packagename, version, release, metadatatag, metadatavalue
>
> or something like this, I'm wondering how to reliably fetch this data.
> For the moment this seems to end up in browsing all Vcs-* locations for
> such a file which sounds not really reliable to me considering the different
> ways a repository layout might be buildet. While it sounds doable it looks
> like "not the kind of jobs I really want to do" for me personally ...
It could be some RDF file to store the data.
>> - Keep the meta-data file up to date in our version control systems, but do
>> not trigger an upload only for this. When we will be tired to call the UDD
>> updated by hand, we can perhaps write commit hooks for this.
>
> Ahhh, this brings up the idea of pushing data to UDD or some intermediate
> file which might be read later. Hmmm, currently UDD gatherers are written
> to gather information from a certain place (like fetching Packages.gz files)
> and then read this file into UDD. But at DebCOnf we thought about alternative
> methods to handle Package Entropy Tracker (PET) which also is more like
> pushing the data in than fetching a large chunk of data at once.
We need to know "who the boss is". It seems like we are starting to collect data
redundantly, because of different ways to update the info. I personally like the
idea to talk back to the online repositories of the packages to get the latest info,
but, still, we need ways to deal with semantic conflicts.
>> With this workflow, we get the best of all systems we were thinking about:
>>
>> - The blends task files get a central point where to find the data.
>> - The packages maintainers have an easy way to update the meta-data.
>> - Offline users who have access to the source packages have a copy of
>> the meta-data that was up to date at the time of the last upload.
>
> Yes to all 3 items.
Fine.
>> The flaw is that it may be difficult in some cases to push meta-data for
>> packages that we are not maintaining ourselves. But my feeling is that the
>> packages for which registration is really an issue are in our hands.
>
> Well, we might announce this option once it is solved for our packages.
>
>> If you like the idea, I will wrap up a more detailed proposal, and submit it on
>> -blends and -science and then on -devel.
Could you pair that with an incremental implementation plan? And ask for help were you
want help?
Cheers,
Steffen
Reply to: