Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
Santiago M. Mola wrote: The GLEP should be updated. "Motivation" section does not seem to justify the changes. IMO Meatoo [1] (and its hipothetical rewrite using Doapspace [2]) would be the right tool to detect version bumps. Maybe metadata.xml should contain a Freshmeat or DOAP entry so meatoo could get more automation. Anyway, I don't know how much would take the new version of meatoo. Pythonhead, could you give us some news about it? Or it's just planned for the long-term future? [1] http://meatoo.gentooexperimental.org/ [2] http://blog.doapspace.org/ Sorry, I missed this email, but I'll be at the council meeting to listen in on talk about GLEP 46. Having Freshmeat, SourceForge etc. project id's in metadata.xml sounds great. I would gladly write a tool to go through SourceForge and Freshmeat's metadata and match project names to ebuild package names using HOMEPAGE. I already have code to parse FLOSSMole's[1] metadata, so it'd be simple to whip up quickly. doapspace.org has an API that lets you give a SourceForge, Freshmeat, PyPI and RubyForge project name and get metadata back, so having a link to the DOAP's URL in metadata.xml isn't really needed for those. For self-hosted projects, we could either put a link to the DOAP in metadata.xml, or simply make sure the HOMEPAGE matches the homepage in the DOAP itself. The second is preferable because the URL to the DOAP could change. Meatoo will be much more accurate after I cross-reference metadata from FLOSSMole to map Gentoo package names to other forge/package index names. Once that's done, we'll have very accurate version bump info that can be looked up by herd/maintainer, from SourceForge, RubyForge, Freshmeat etc. Rob [1] http://ossmole.sourceforge.net -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
On Sat, 19 Jan 2008 16:24:53 +0100 "Denis Dupeyron" <[EMAIL PROTECTED]> wrote: > On Jan 19, 2008 2:07 PM, Tiziano Müller <[EMAIL PROTECTED]> wrote: > > Your oppinion? > > Would this be the right time to discuss about moving other variables > to metadata.xml ? How about HOMEPAGE, DESCRIPTION and LICENSE ? Those > hardly change and if they ever do we can restrict them to specific > versions. I know there could be technical hurdles, but what do you > think of the idea at least ? At least LICENSE is no go, since the package manager needs it. Having DESCRIPTION and HOMEPAGE available to the package manager even when XML goes splat is probably useful too... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
On Jan 19, 2008 4:24 PM, Denis Dupeyron <[EMAIL PROTECTED]> wrote: > On Jan 19, 2008 2:07 PM, Tiziano Müller <[EMAIL PROTECTED]> wrote: > > Your oppinion? > > Would this be the right time to discuss about moving other variables > to metadata.xml ? How about HOMEPAGE, DESCRIPTION and LICENSE ? Those > hardly change and if they ever do we can restrict them to specific > versions. I know there could be technical hurdles, but what do you > think of the idea at least ? > I'm not sure about HOMEPAGE and DESCRIPTION, but I think LICENSE should be per-ebuild variable. A license change is not so strange (GPL-3, double licensing the source, or adding new artwork licensed with a more restrictive license). Moreover, a license change does not need to be retroactive, so using a global variable in metadata.xml could lead to accidentally show a wrong license for old versions. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
On Jan 19, 2008 2:07 PM, Tiziano Müller <[EMAIL PROTECTED]> wrote: > Your oppinion? Would this be the right time to discuss about moving other variables to metadata.xml ? How about HOMEPAGE, DESCRIPTION and LICENSE ? Those hardly change and if they ever do we can restrict them to specific versions. I know there could be technical hurdles, but what do you think of the idea at least ? Denis.
Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
Tiziano Müller wrote:
Current state: "Deferred"
Wanted state: "Accepted/Implemented" (at least by me)
Open questions from last discussion (March 2006):
- Is it possible/should it be possible to have more than one
entry?
Yes
- Is recording an upstream-status (active/inactive) a good idea?
Maybe, leaning to No.
What about packages that have multiple slots, e.g php-4, php-5? one
slot could be inactive the other not, does that make upstream active?
Possibilities:
An element: {active/inactive}
Status of what? seeing you have proposed a upstream-status and a
maintainer status. what else is there left to status :P
An attribute: ...
No. As i'm pretty sure that every inactive maintainer won't go around
updating their packages metadata.xml
- Is an additional element needed to link to upstream docs
Interesting. what about the situation where upstream documentation sucks
but there is a "better" resource provided by a third party, could we
link to that? e.g. http://tldp.org for bash is an excellent resource
Multiple doc links?
could provide
that. Only concern I see is that this could relate to an endorsement of
thirdparty websites, which may change negatively ( porn on tldp.org ) or
my just become outdated.
Actually without the multiple official/unofficial doc tags I would have
to say No. as 99% of the time it would just be "${HOMEPAGE}/doc" or
there would be a big fat link from the homepage and therefore would be
of no real benefit.
Alistair
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
Tiziano Müller <[EMAIL PROTECTED]> said:
>
> Current state: "Deferred"
> Wanted state: "Accepted/Implemented" (at least by me)
Yea, this sounds like a good thing from reading over the GLEP, unless
I'm missing some glaring problems with it.
> Open questions from last discussion (March 2006):
> - Is it possible/should it be possible to have more than one
> entry?
Yea, agree.
> - Is recording an upstream-status (active/inactive) a good idea?
> Possibilities:
> An element: {active/inactive}
> An attribute: ...
Definately. We have several packages in the tree that once they become
broken, we'd have to start developing ourselves. This will help the
treecleaner project as well so they can tell if a package has several
open bugs and upstream is inactive, its a very good candidate for
getting booted from the tree.
> - Is an additional element needed to link to upstream docs
Sounds reasonable.
> - Must the type of be controlled/listed/checked?
I'd say we should come up with a good list to start with. We can come
up with updates to the allowed values at a later date, but I do think we
should keep this under control.
--
Mark Loeser
email - halcy0n AT gentoo DOT org
email - mark AT halcy0n DOT com
web - http://www.halcy0n.com
pgpPXq07yrA1j.pgp
Description: PGP signature
Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
On Jan 19, 2008 2:07 PM, Tiziano Müller <[EMAIL PROTECTED]> wrote: > > Current state: "Deferred" > Wanted state: "Accepted/Implemented" (at least by me) The GLEP should be updated. "Motivation" section does not seem to justify the changes. IMO Meatoo [1] (and its hipothetical rewrite using Doapspace [2]) would be the right tool to detect version bumps. Maybe metadata.xml should contain a Freshmeat or DOAP entry so meatoo could get more automation. Anyway, I don't know how much would take the new version of meatoo. Pythonhead, could you give us some news about it? Or it's just planned for the long-term future? [1] http://meatoo.gentooexperimental.org/ [2] http://blog.doapspace.org/ -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
[gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
Current state: "Deferred"
Wanted state: "Accepted/Implemented" (at least by me)
Open questions from last discussion (March 2006):
- Is it possible/should it be possible to have more than one
entry?
- Is recording an upstream-status (active/inactive) a good idea?
Possibilities:
An element: {active/inactive}
An attribute: ...
- Is an additional element needed to link to upstream docs
- Must the type of be controlled/listed/checked?
My answers to this:
- yes
- yes. Remark: do we need to specify when upstream has to be marked as
active/inactive or can we use our common sense ?
- yes.
- not yet. Can be defined later.
Your oppinion?
--
gentoo-dev@lists.gentoo.org mailing list
