Re: Experiment to gather information about prospective packages (Was: [Blends-commit] r3275 - /blends/trunk/machine_readable/fetch-machine-readable)
On Sat, Apr 21, 2012 at 04:48:48PM +0900, Charles Plessy wrote:
>
> I see. This works well for some packages, but in other cases, it can be
> misleading, in particular because of the « viral » nature of the GPL . Perhaps
> you can mention document somewhere (in the « summary » section ?) that the
> license information is for the main work of a package, and does not consider
> the linkage to other libraries ?
I admit I consider this datum as the weakest of all I want to gather.
Perhaps I will go rather with the fact whether a package is in main or
in contrib / non-free and just use "DFSG free" as I'm currently using
for any Debian package in main. I actually do not see much value in
rendering the exact license because the final piece of information is
whether the potential taker would spend his time into a free or non-free
piece of software. I'd regard any gain for more detail as a waste of
time. As I said, this is some first experiment with uncertain outcome.
> > I get the Vcs-Data in the most direct way you might imagine: I'm
> > actually browsing the Vcs repositories of the Blends teams and thus I
> > *know* the Vcs fields in advance. My plan is to issue warnings about
> > impropely set Vcs fields in the debian/control file rather than trusting
> > them.
>
> Would you be interested in having the debian/control files gathered with the
> debian/upstream and debian/copyright files, or shall I rather focus on making
> the gatherer more robust first (such as detecting 404 errors, etc.).
IMHO, Umegaya and my scan for preliminary package information are
working on disjunct sets of information. You are gathering information
of *existing* packages. My importer will have a check like:
If source is in UDD then ignore the files for this package
The rationale behind this is that all information from debian/control
files of existing packages is just inside UDD. It would make no sense
at all to fetch this twice.
> > I admit I'd love to see more persons involved.
>
> At that point, I think that even comments without intention to contribute time
> or code would be welcome. These comments will arise anyway when we will
> present our work to a broader audience, so better reveiving them early.
Well, you are right that we should discuss this on the list and I
actually expect comments once we can show something. However, my
experience says that before there is something to present the interest
will remain low. Even if the issue is very burning (like for instance
with BiBref issues where I know for sure at least three persons who were
very interested) people claim to have no time and loose track in the
discussion. (Just been there, explained the main important points of
the BibRef gatherer in PM after I was told that the discussion was
basically ignored.)
So my plan is to try to collect whatever I can gather and once I
consider it useful I will eventually come up with something for
discussion. My code is not yet functional (you might have read my
requests for help for the python-debian module - I probably will do some
manual parsing which is also not very hard, just to get something to
show which is worth discussing). I do not expect that people are
really keen on commiting changes to half-baked code in Vcs.
Kind regards and thanks for your comments
Andreas.
--
http://fam-tille.de
Reply to: