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
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-dev@g.o
From: Kent Fredric <kentfredric@...>
Subject: Re: Re: euscan GSoC project - requesting feedback
Date: Sat, 30 Jun 2012 04:43:23 +1200
On 29 June 2012 17:32, Duncan <1i5t5.duncan@...> wrote:
> I don't know how difficult that would be for euscan to pickup on, but
> since this would have no bearing on actual package behavior, only on
> euscan, I'd guess it shouldn't require going thru the formal PMS process,
> tho specifying it well enough to know whether it can be a function or
> must be a straight variable assignment, etc, as well as whether quotes
> are required or not, would be useful, and that's normally part of the PMS
> process so at least getting input from them would be useful.
> Alternatively, define some formula that can be placed in the package's
> metadata.xml.  That's perhaps a better functionality match (we're talking
> about metadata, after all), but getting a formula that can deal with all
> the corner-cases is likely to be more difficult (and take longer) than
> simply specifying a variable to be defined for each ebuild that euscan
> can't immediately get correct.

The problem is with this approach, some devs will want to set
EUSCAN_VERSION automagically using mangling $PV

As it is, we *already* have something equivalent to EUSCAN_VERSION for
things derived from perl-module.eclass, MODULE_VERSION=

Its not 1:1 identical to the intent of EUSCAN_VERSION, MODULE_VERSION
is only really required in the generation of SRC_URI , but because of
this, there is a loose MODULE_VERSION <-> distfile mapping, and a much
looser $PV <-> MODULE_VERSION association.

Sure, its fine for MODULE_VERSION to be made by mangling $PV, but the
problem is that the *reason* people mangle $PV to make MODULE_VERSION
is so they don't have to update MODULE_VERSION manually when bumping
the package.

Adding a non-bash non-$PV-manglable field EUSCAN_VERSION field will
possibly make manually incrementing this value a mandatory thing.

Not to mention, if it turns out to be "wrong" on the EUSCAN index,
some dev has to drop the change into the repository, do all the
manifest updating and commit signing and pushing it to CVS nonsense,
when really, its metadata only relevant to euscan, so its really in
the wrong place to start with.

Having it handled as an exception list on the euscan would be much
tidier, and the path from noticing the problem to solving the problem
becomes substantially shorter.


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

euscan GSoC project - requesting feedback
-- Federico \"fox\" Scrinzi
Re: euscan GSoC project - requesting feedback
-- Kent Fredric
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: euscan GSoC project - requesting feedback
Next by thread:
prune_libtool_files is NOT a direct replacement for, example, find "${D}" -name '*.la' -delete
Previous by date:
Re: grub:2 keywords
Next by date:
Re: euscan GSoC project - requesting feedback

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.