Re: [gentoo-dev] RFC: Add new remote-id types in metadata.dtd

[Kent Fredric]

On 20 April 2012 19:46, Corentin Chary <corentin.chary@×××××.com> wrote:
> On Fri, Apr 20, 2012 at 9:37 AM, Kent Fredric <kentfredric@×××××.com> wrote:
>> On 20 April 2012 03:31, Corentin Chary <corentin.chary@×××××.com> wrote:
>>> Add rubygems, github, gitorious, pecl, pear, bitbucket.
>>> All of them are handled by my remoteids.py script.
>>>
>>> ref: https://bugs.gentoo.org/show_bug.cgi?id=406287
>>> ref: https://github.com/iksaif/portage-janitor/blob/master/remoteids.py
>>>
>>> --- a/metadata/dtd/metadata.dtd 2010-03-02 18:52:11.000000000 +0100
>>> +++ b/metadata/dtd/metadata.dtd 2012-04-19 14:22:14.077954310 +0200
>>> @@ -61,7 +61,7 @@
>>>     <!ELEMENT bugs-to (#PCDATA)>
>>>     <!-- specify a type of package identification tracker -->
>>>     <!ELEMENT remote-id (#PCDATA)>
>>> -      <!ATTLIST remote-id type (freshmeat|sourceforge|sourceforge-jp|cpan|vim|google-code|ctan|pypi|rubyforge|cran) #REQUIRED>
>>> +      <!ATTLIST remote-id type (freshmeat|sourceforge|sourceforge-jp|cpan|vim|google-code|ctan|pypi|rubyforge|cran|rubygems|github|gitorious|pecl|pear|bitbucket) #REQUIRED>
>>>
>>>   <!-- category/package information for cross-linking in descriptions
>>>     and useflag descriptions -->
>>>
>>> --
>>> Corentin Chary
>>> http://xf.iksaif.net/
>>
>>
>> I suggested last week on #gentoo-perl that it might be nice to have
>> 'cpan' and 'cpan-module'  ( or something like that ) to disambiguate 2
>> queryable terms. ( where 'cpan'  => 'the package name on cpan' )
>>
>> For some purposes, its most convenient to use the distribution name,
>> and for other purposes, (ie: cpan clients) its more convenient to use
>> a Module name, and its not easy to translate between the two, as
>> Module names sometimes switch between packages  they're shipped in.
>>
>> For instance, a while ago, the BioPerl module was shipped in a
>> distribution 'bioperl' , which has only recently been changed to
>> BioPerl
>>
>>
>> http://api.metacpan.org/release/_search?q=distribution:bioperl&fields=archive,author,date,download_url
>>
>> http://api.metacpan.org/release/_search?q=distribution:BioPerl&fields=archive,author,date,download_url
>>
>> vs
>>
>>
>> http://api.metacpan.org/module/_search?q=module.name:Bio\:\:Perl&fields=distribution,author,release
>
> Looks sane since the goal of remote-id is being able to identify the
> package upstream.
> Do you think you could patch remotesid.py to generate tags for cpan /
> cpan-modules ? Or at least give me a pseudo-algo that does the trick.
> Thanks :)
>
> --
> Corentin Chary
> http://xf.iksaif.net
>


That is sadly not straight forward.  Extracting the package name can
be straight forward if you have the URL, because the package name is
literally the same as the archive name in SRC_URI , sans version
information.

However, if you look at many perl ebuilds, you'll notice many lack
this field and we've got other things in place, so the current parsing
technique you use to detect uses of SRC_URI wont work there ( I could
be wrong, I don't fully grok your python code )

And more-over, determining the value of 'cpan-module' may be
impossible without access to the tar.gz itself, or querying the
MetaCPAN API.

Usually, upstream are sensible and have package names which closely
correspond with the module names, ie: "Dist::Zilla" is shipped in
'Dist-Zilla-$VERSION.tar.gz',  but there are many packages which dont
do this, such as this notable example:
https://metacpan.org/release/Scalar-List-Utils  , which has no modules
corresponding to the package name, and no way to divine the/a 'main'
module from the package itself. ( and this is exacerbated by packages
changing names, or package joins ( 2 packages becoming 1 via releasing
modules together ),  and package splits ( 1 package rips into 2 sets
of modules ).

Essentially, using a cpan-module as an identifier is somewhat
"forwards only" , and even then, what it will resolve to is governed
by time.

This is fine for CPAN clients, which do the resolution hot, using the
whole of CPAN as their data, if a user asks for "Foo::Bar", their cpan
client will ask a cpan server ( or regularly (hourly) updated list )
as to what package that module can be found in ( and this only returns
the most recent package, so name changes and so-forth are invisible to
the user ).

And being helpful to CPAN clients is one of the reasons we want this
value as a specifiable option in the first place. For us, its easier
to track the package name, and then when that has to change we can
manually resolve the issue

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz