Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Corentin Chary <corentin.chary@...>
Subject: Re: RFC: Add new remote-id types in metadata.dtd
Date: Fri, 20 Apr 2012 13:21:42 +0200
On Fri, Apr 20, 2012 at 10:26 AM, Kent Fredric <kentfredric@...> wrote:
> On 20 April 2012 19:46, Corentin Chary <corentin.chary@...> wrote:
>> On Fri, Apr 20, 2012 at 9:37 AM, Kent Fredric <kentfredric@...> wrote:
>>> On 20 April 2012 03:31, Corentin Chary <corentin.chary@...> 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 )

Currently it uses SRC_URI and HOMEPAGE, but honestly it wouldn't be
hard to use any other environment variable and to do some checks on a
webservice.
Anyway for tricky cases it can still be done by hand.

> 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
>



-- 
Corentin Chary
http://xf.iksaif.net


Replies:
Re: RFC: Add new remote-id types in metadata.dtd
-- Kent Fredric
References:
RFC: Add new remote-id types in metadata.dtd
-- Corentin Chary
Re: RFC: Add new remote-id types in metadata.dtd
-- Kent Fredric
Re: RFC: Add new remote-id types in metadata.dtd
-- Corentin Chary
Re: RFC: Add new remote-id types in metadata.dtd
-- Kent Fredric
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: RFC: Add new remote-id types in metadata.dtd
Next by thread:
Re: RFC: Add new remote-id types in metadata.dtd
Previous by date:
Re: RFC: Add new remote-id types in metadata.dtd
Next by date:
Re: RFC: Add new remote-id types in metadata.dtd


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.