FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 04-19-2012, 03:31 PM
Corentin Chary
 
Default RFC: Add new remote-id types in metadata.dtd

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|gito rious|pecl|pear|bitbucket) #REQUIRED>

<!-- category/package information for cross-linking in descriptions
and useflag descriptions -->

--
Corentin Chary
http://xf.iksaif.net/
 
Old 04-19-2012, 04:54 PM
Michał Górny
 
Default RFC: Add new remote-id types in metadata.dtd

On Thu, 19 Apr 2012 17:31:11 +0200
Corentin Chary <corentin.chary@gmail.com> wrote:

> - <!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|gito rious|pecl|pear|bitbucket)
> #REQUIRED>

Wouldn't it be better if we kept them sorted?

--
Best regards,
Michał Górny
 
Old 04-19-2012, 06:08 PM
"Paweł Hajdan, Jr."
 
Default RFC: Add new remote-id types in metadata.dtd

On 4/19/12 5:31 PM, Corentin Chary wrote:
> Add rubygems, github, gitorious, pecl, pear, bitbucket.
> All of them are handled by my remoteids.py script.

Just making sure: do github, gitorious and bitbucket provide file
hosting? I know they host repos, but for most ebuilds where remote-id
would be useful, we need tarballs.
 
Old 04-19-2012, 06:57 PM
Michał Górny
 
Default RFC: Add new remote-id types in metadata.dtd

On Thu, 19 Apr 2012 20:08:09 +0200
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:

> On 4/19/12 5:31 PM, Corentin Chary wrote:
> > Add rubygems, github, gitorious, pecl, pear, bitbucket.
> > All of them are handled by my remoteids.py script.
>
> Just making sure: do github, gitorious and bitbucket provide file
> hosting? I know they host repos, but for most ebuilds where remote-id
> would be useful, we need tarballs.

Yes, they do.

--
Best regards,
Michał Górny
 
Old 04-19-2012, 07:32 PM
Corentin Chary
 
Default RFC: Add new remote-id types in metadata.dtd

On Thu, Apr 19, 2012 at 6:54 PM, Michał Górny <mgorny@gentoo.org> wrote:
> On Thu, 19 Apr 2012 17:31:11 +0200
> Corentin Chary <corentin.chary@gmail.com> wrote:
>
>> - * * *<!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|gito rious|pecl|pear|bitbucket)
>> #REQUIRED>
>
> Wouldn't it be better if we kept them sorted?

There were not, so I just appended them, but I can provide another
patch sorting them too if preferred.


--
Corentin Chary
http://xf.iksaif.net
 
Old 04-19-2012, 08:00 PM
"Robin H. Johnson"
 
Default RFC: Add new remote-id types in metadata.dtd

On Thu, Apr 19, 2012 at 05:31:11PM +0200, Corentin Chary wrote:
> Add rubygems, github, gitorious, pecl, pear, bitbucket.
> All of them are handled by my remoteids.py script.
Can we get Launchpad added as well?

--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
 
Old 04-20-2012, 07:37 AM
Kent Fredric
 
Default RFC: Add new remote-id types in metadata.dtd

On 20 April 2012 03:31, Corentin Chary <corentin.chary@gmail.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|gito rious|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,auth or,date,download_url

http://api.metacpan.org/release/_search?q=distribution:BioPerl&fields=archive,auth or,date,download_url

vs


http://api.metacpan.org/module/_search?q=module.name:Bio::Perl&fields=distributio n,author,release



--
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
 
Old 04-20-2012, 07:46 AM
Corentin Chary
 
Default RFC: Add new remote-id types in metadata.dtd

On Fri, Apr 20, 2012 at 9:37 AM, Kent Fredric <kentfredric@gmail.com> wrote:
> On 20 April 2012 03:31, Corentin Chary <corentin.chary@gmail.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|gito rious|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,auth or,date,download_url
>
> http://api.metacpan.org/release/_search?q=distribution:BioPerl&fields=archive,auth or,date,download_url
>
> vs
>
>
> http://api.metacpan.org/module/_search?q=module.name:Bio::Perl&fields=distributio n,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
 
Old 04-20-2012, 08:26 AM
Kent Fredric
 
Default RFC: Add new remote-id types in metadata.dtd

On 20 April 2012 19:46, Corentin Chary <corentin.chary@gmail.com> wrote:
> On Fri, Apr 20, 2012 at 9:37 AM, Kent Fredric <kentfredric@gmail.com> wrote:
>> On 20 April 2012 03:31, Corentin Chary <corentin.chary@gmail.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|gito rious|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,auth or,date,download_url
>>
>> http://api.metacpan.org/release/_search?q=distribution:BioPerl&fields=archive,auth or,date,download_url
>>
>> vs
>>
>>
>> http://api.metacpan.org/module/_search?q=module.name:Bio::Perl&fields=distributio n,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
 
Old 04-20-2012, 11:21 AM
Corentin Chary
 
Default RFC: Add new remote-id types in metadata.dtd

On Fri, Apr 20, 2012 at 10:26 AM, Kent Fredric <kentfredric@gmail.com> wrote:
> On 20 April 2012 19:46, Corentin Chary <corentin.chary@gmail.com> wrote:
>> On Fri, Apr 20, 2012 at 9:37 AM, Kent Fredric <kentfredric@gmail.com> wrote:
>>> On 20 April 2012 03:31, Corentin Chary <corentin.chary@gmail.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|gito rious|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,auth or,date,download_url
>>>
>>> http://api.metacpan.org/release/_search?q=distribution:BioPerl&fields=archive,auth or,date,download_url
>>>
>>> vs
>>>
>>>
>>> http://api.metacpan.org/module/_search?q=module.name:Bio::Perl&fields=distributio n,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
 

Thread Tools




All times are GMT. The time now is 04:15 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org