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 08-10-2012, 02:21 PM
Jeroen Roovers
 
Default SRC_URI in metadata.xml

On Fri, 10 Aug 2012 14:03:23 +0200
Gilles Dartiguelongue <eva@gentoo.org> wrote:

> Since you are proposing this, a side question is:
> Why should we write SRC_URI in ebuilds if that info is now available
> in metadata.xml ? (granted that we might still want to keep
> over-riding this information in ebuilds)

1) The information in metadata.xml is inaccurate, it's a hint. When it
fails, nothing of value is lost since the ebuild (supposedly) has
what you want.
2) SRC_URI is precise.
3) SRC_URI can change over time, and across versions (even with all the
variables in place).
4) Backward compatibility.
5) The inversion of your question: Why should we start handling SRC_URI
outside ebuilds and eclasses? Or, how would that be practical,
advantageous, an improvement on the current situation.


jer
 
Old 08-10-2012, 02:24 PM
Diego Elio Pettenò
 
Default SRC_URI in metadata.xml

On 10/08/2012 07:21, Jeroen Roovers wrote:
> 3) SRC_URI can change over time, and across versions (even with all the
> variables in place).

I agree with Jeroen here — in particular see things that come from
alioth such as sys-apps/pcsc-lite and app-crypt/ccid: the SRC_URI
actually has to change for each ebuild because there is one extra number
that is used...

--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
 
Old 08-10-2012, 08:05 PM
Corentin Chary
 
Default SRC_URI in metadata.xml

On Fri, Aug 10, 2012 at 4:21 PM, Jeroen Roovers <jer@gentoo.org> wrote:
> On Fri, 10 Aug 2012 14:03:23 +0200
> Gilles Dartiguelongue <eva@gentoo.org> wrote:
>
>> Since you are proposing this, a side question is:
>> Why should we write SRC_URI in ebuilds if that info is now available
>> in metadata.xml ? (granted that we might still want to keep
>> over-riding this information in ebuilds)
>
> 1) The information in metadata.xml is inaccurate, it's a hint. When it
> fails, nothing of value is lost since the ebuild (supposedly) has
> what you want.
> 2) SRC_URI is precise.
> 3) SRC_URI can change over time, and across versions (even with all the
> variables in place).
> 4) Backward compatibility.
> 5) The inversion of your question: Why should we start handling SRC_URI
> outside ebuilds and eclasses? Or, how would that be practical,
> advantageous, an improvement on the current situation.

Right, our proposal is not here to replace SRC_URI, it's here to fix
the cases where SRC_URI can't be sanely used to guess new upstream
versions (strange mangling rules, unbrowsable directories, etc...).

--
Corentin Chary
http://xf.iksaif.net
 
Old 08-10-2012, 08:12 PM
Diego Elio Pettenò
 
Default SRC_URI in metadata.xml

On 10/08/2012 13:05, Corentin Chary wrote:
> Right, our proposal is not here to replace SRC_URI, it's here to fix
> the cases where SRC_URI can't be sanely used to guess new upstream
> versions (strange mangling rules, unbrowsable directories, etc...).

Yes I guess Jeroen was just saying why we shouldn't abandon it as Gilles
proposed.

FWIW for the rest it feels right to me. Although this starts to add up
to the reasons why at least metadata.xml should be validated by schema,
and not DTD.

--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
 
Old 08-11-2012, 11:55 AM
Corentin Chary
 
Default SRC_URI in metadata.xml

On Fri, Aug 10, 2012 at 10:12 PM, Diego Elio Petten
<flameeyes@flameeyes.eu> wrote:
> On 10/08/2012 13:05, Corentin Chary wrote:
>> Right, our proposal is not here to replace SRC_URI, it's here to fix
>> the cases where SRC_URI can't be sanely used to guess new upstream
>> versions (strange mangling rules, unbrowsable directories, etc...).
>
> Yes I guess Jeroen was just saying why we shouldn't abandon it as Gilles
> proposed.
>
> FWIW for the rest it feels right to me. Although this starts to add up
> to the reasons why at least metadata.xml should be validated by schema,
> and not DTD.

Maybe .. We plan to use <watch xmlns="http://euscan.iksaif.net"> to
avoid editing metadata.dtd (for now).
What do you think about format propositions ? Current format looks
like what was given in the examples, but mgorny feels that something
more xmlish would be better.

--
Corentin Chary
http://xf.iksaif.net
 
Old 08-11-2012, 10:43 PM
Alec Warner
 
Default SRC_URI in metadata.xml

On Sat, Aug 11, 2012 at 1:55 PM, Corentin Chary <iksaif@gentoo.org> wrote:
> On Fri, Aug 10, 2012 at 10:12 PM, Diego Elio Petten
> <flameeyes@flameeyes.eu> wrote:
>> On 10/08/2012 13:05, Corentin Chary wrote:
>>> Right, our proposal is not here to replace SRC_URI, it's here to fix
>>> the cases where SRC_URI can't be sanely used to guess new upstream
>>> versions (strange mangling rules, unbrowsable directories, etc...).
>>
>> Yes I guess Jeroen was just saying why we shouldn't abandon it as Gilles
>> proposed.
>>
>> FWIW for the rest it feels right to me. Although this starts to add up
>> to the reasons why at least metadata.xml should be validated by schema,
>> and not DTD.
>
> Maybe .. We plan to use <watch xmlns="http://euscan.iksaif.net"> to
> avoid editing metadata.dtd (for now).
> What do you think about format propositions ? Current format looks
> like what was given in the examples, but mgorny feels that something
> more xmlish would be better.

If you want metadata.dtd patched; please file a bug against www@ and
someone will look at it (you may have to poke us a few times... )

>
> --
> Corentin Chary
> http://xf.iksaif.net
>
 
Old 08-11-2012, 11:53 PM
Diego Elio Pettenò
 
Default SRC_URI in metadata.xml

On 11/08/2012 15:43, Alec Warner wrote:
> If you want metadata.dtd patched; please file a bug against www@ and
> someone will look at it (you may have to poke us a few times... )

Can we have xmlschema instead? You know so that things like broken email
addresses in <maintainer> can be caught...

--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
 
Old 08-13-2012, 10:25 AM
Dirkjan Ochtman
 
Default SRC_URI in metadata.xml

On Sun, Aug 12, 2012 at 1:53 AM, Diego Elio Petten
<flameeyes@flameeyes.eu> wrote:
> Can we have xmlschema instead? You know so that things like broken email
> addresses in <maintainer> can be caught...

https://bugs.gentoo.org/show_bug.cgi?id=384457

IMO RELAX NG (or Schematron) would be much better than XML Schema.

Cheers,

Dirkjan
 
Old 08-13-2012, 10:51 AM
Gilles Dartiguelongue
 
Default SRC_URI in metadata.xml

Le vendredi 10 aot 2012 16:21 +0200, Jeroen Roovers a crit :
> On Fri, 10 Aug 2012 14:03:23 +0200
> Gilles Dartiguelongue <eva@gentoo.org> wrote:
>
> > Since you are proposing this, a side question is:
> > Why should we write SRC_URI in ebuilds if that info is now available
> > in metadata.xml ? (granted that we might still want to keep
> > over-riding this information in ebuilds)

I was not suggesting to erase SRC_URI from all ebuilds but for things
that have well defined rules like gnome packages, defining SRC_URI is
mostly a useless excercise.


5) The inversion of your question: Why should we start handling SRC_URI
> outside ebuilds and eclasses? Or, how would that be practical,
> advantageous, an improvement on the current situation.
>

I will add against my own question that eclasses currently handle this
(see gnome.org eclass) very well. So maybe there is nothing to debate
here
 
Old 08-13-2012, 02:50 PM
Diego Elio Pettenò
 
Default SRC_URI in metadata.xml

On 13/08/2012 03:25, Dirkjan Ochtman wrote:
> IMO RELAX NG (or Schematron) would be much better than XML Schema.

They are generally idempotent enough that you don't have to worry about
which one you choose... Relax NG works for me, I would have to convert
them to rnc anyway to load into emacs's nxml.

--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
 

Thread Tools




All times are GMT. The time now is 07:51 PM.

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