Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-28 Thread Peter Volkov
EAPI inside ebuild is the best solution. If we really have to put it
inside filename, keep it out of extension, like 2) b) suggests.

-- 
Peter.




[gentoo-dev] Re: perl-module.eclass -- review - 2

2009-02-28 Thread Torsten Veller
* Torsten Veller ml...@veller.net:
 Please review the attached perl-module.eclass.
 Patch linked below.

Thanks Bo Ørsted Andresen for feedback

 Changes
 ~~~
  - use emake
  - more quoting
  - call perlinfo only once

As I've not seen any ebuild doing the replacement in line 156,
I've added a temporary ewarn. If you hits you, tell me.

 git://github.com/tove/perl-eclass.git
 http://people.gentoo.org/tove/files/perl-module.eclass.diff
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/perl-module.eclass,v 1.112 2008/09/30 
08:28:44 robbat2 Exp $
#
# Author: Seemant Kulleen seem...@gentoo.org

# @ECLASS: perl-module.eclass
# @MAINTAINER:
# p...@gentoo.org
# @BLURB: eclass for perl modules
# @DESCRIPTION:
# The perl-module eclass is designed to allow easier installation of perl
# modules, and their incorporation into the Gentoo Linux system.

inherit eutils base

case ${EAPI:-0} in
0|1)
EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst pkg_prerm 
pkg_postrm src_compile src_install src_test src_unpack
;;
*)
EXPORT_FUNCTIONS src_unpack src_prepare src_configure 
src_compile src_test src_install
;;
esac

DESCRIPTION=Based on the $ECLASS eclass

LICENSE=${LICENSE:-|| ( Artistic GPL-2 )}

[ -z ${SRC_URI} -a -z ${MODULE_A} ]  MODULE_A=${MY_P:-${P}}.tar.gz
[ -z ${SRC_URI} -a -n ${MODULE_AUTHOR} ]  \

SRC_URI=mirror://cpan/authors/id/${MODULE_AUTHOR:0:1}/${MODULE_AUTHOR:0:2}/${MODULE_AUTHOR}/${MODULE_SECTION}/${MODULE_A}
[ -z ${HOMEPAGE} ]  \
HOMEPAGE=http://search.cpan.org/dist/${MY_PN:-${PN}};

SRC_PREP=no
SRC_TEST=skip
PREFER_BUILDPL=yes

PERL_VERSION=
SITE_ARCH=
SITE_LIB=
VENDOR_LIB=
VENDOR_ARCH=
ARCH_LIB=
pm_echovar=
perlinfo_done=false

perl-module_src_unpack() {
base_src_unpack unpack
has ${EAPI:-0} 0 1  perl-module_src_prepare
}

perl-module_src_prepare() {
if [[ -n ${PATCHES} ]] ; then
base_src_unpack autopatch
fi
esvn_clean
}

perl-module_src_configure() {
perl-module_src_prep
}

perl-module_src_prep() {
[[ ${SRC_PREP} = yes ]]  return 0
SRC_PREP=yes

${perlinfo_done} || perlinfo

export PERL_MM_USE_DEFAULT=1
# Disable ExtUtils::AutoInstall from prompting
export PERL_EXTUTILS_AUTOINSTALL=--skipdeps

if [[ ${PREFER_BUILDPL} == yes  -f Build.PL ]] ; then
einfo Using Module::Build
perl Build.PL \
--installdirs=vendor \
--libdoc= \
--destdir=${D} \
--create_packlist=0 \
--extra_linker_flags=${LDFLAGS} \
${myconf} \
 ${pm_echovar} \
|| die Unable to build! (are you using 
USE=\build\?)
elif [[ -f Makefile.PL ]] ; then
einfo Using ExtUtils::MakeMaker
perl Makefile.PL \
PREFIX=/usr \
INSTALLDIRS=vendor \
INSTALLMAN3DIR='none' \
DESTDIR=${D} \
${myconf} \
 ${pm_echovar} \
|| die Unable to build! (are you using 
USE=\build\?)
fi
if [[ ! -f Build.PL  ! -f Makefile.PL ]] ; then
einfo No Make or Build file detected...
return
fi
}

perl-module_src_compile() {
${perlinfo_done} || perlinfo

has ${EAPI:-0} 0 1  perl-module_src_prep

if [[ -f Build ]] ; then
./Build build || die compilation failed
elif [[ -f Makefile ]] ; then
#emake ${mymake} OPTIMIZE=${CFLAGS} OTHERLDFLAGS=${LDFLAGS} 
|| die compilation failed
emake ${mymake} OTHERLDFLAGS=${LDFLAGS} || die compilation 
failed
fi
}

perl-module_src_test() {
if [[ ${SRC_TEST} == do ]] ; then
${perlinfo_done} || perlinfo
if [[ -f Build ]] ; then
./Build test || die test failed
elif [[ -f Makefile ]] ; then
emake test || die test failed
fi
fi
}

perl-module_src_install() {
local f
${perlinfo_done} || perlinfo

[[ -z ${mytargets} ]]  mytargets=pure_install

if [[ -f Build ]] ; then
./Build ${mytargets} || die
elif [[ -f Makefile ]] ; then
emake ${myinst} ${mytargets} || die
fi

#   einfo Cleaning out stray man files
find ${D} -type f -name *.3pm -delete
find ${D}/usr/share/man -depth -type d -empty -delete 2/dev/null

fixlocalpod

for f in Change* CHANGES README* ${mydoc}; do
[[ -s ${f} ]]  dodoc ${f}
done


Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-28 Thread Fernando J. Pereda
 2) EAPI in file extension
   - Allows changing global scope and the internal format of the ebuild
   a) .ebuild-eapi
 - ignored by current Portage

This is the solution that solves most problems. Going with something
else is just a way of doing it wrong for the sake of it.

- ferdy



pgpfhEMRKGC35.pgp
Description: PGP signature


Regarding live sources management proposals (Was: [gentoo-dev] Gentoo Council Reminder for February 26)

2009-02-28 Thread Luca Barbato

Ciaran McCreesh wrote:

On Thu, 26 Feb 2009 21:40:26 +0100
Luca Barbato lu_z...@gentoo.org wrote:

Be specific. Explain how this works when, say, 0.34.4 is current,
you have a 0.34.5_live and 0.34.5 comes out.

being live working as substitute for 0.34.5_preN (_live) component
the appearance of 0.34.5 will be higher than those. If we consider
the .live alternative you'd have 0.34.live that is shadowed only by
0.35.x


So it doesn't work Right.


I'd like to have more details on this point since it works the very same 
-scm does: the version component substituted gets higher than any other 
value when is resolved.



That is pretty much the same you get with -scm, what happens is that
in the case of live template you have portage installing 0.34.5_preN
with revision informations and adding the template to the live set.


No, with -scm the order works correctly.


works correctly

You are always not stating what correctly is in your opinion or why 
other solutions are broken.


In my opinion is correct to mark a version component as it will be the 
higher within that boundary, so 1.2.live means 1.2.x when x is the 
highest value, no matter which are the others at that time. Using a 
timestamp to replace x is the simplest way to grant this property.



How do I track an upstream who has a 0.34 branch (which is equal
to or ahead of the most recent 0.34.x release), a 0.36 branch
(which is equal to or ahead of the most recent 0.36.x release) and
a master branch (which is ahead of any release) using the live
property?

the live property doesn't tell much about versioning
so you could use  as the x version component or .live or -scm,
the live property just makes portage aware that the sources are live.

This situation is one in those pkg-scm and pkg.live work better, but 
just for one branch.


As you said you could address the problem using useflags, so you
could by extension you can use the same way to address the single
case in proposals not supporting the tip of a single non version
branch as well:

have the all the ebuilds in a package having IUSE=-live that if
enabled triggers the live property and changes the src_uri to the
live branch you desire.


So if you do that, how does the package manager know that one version
is less than another if a particular use flag is enabled, but greater
than it if it is disabled?


The same argument is valid about the case of more than one tip branch 
you'd like to follow, how pkg-scm[master] is higher than pkg-scm[pu]?


With property live you just know that it was from a live sources, so you 
can consider it always new when it comes to resolve it and that pretty 
much gives you the same behavior you get out -scm as is detailed in the 
glep-54


With live template you know when you installed it and what you installed 
so you can re-emerge or update depending on what you want and you get at 
least the timestamp giving some more information.


If you throw in the mix SLOT alteration depending on or not on useflags 
or timestamps then you may also archive the property of having multiple 
version installed within any proposed framework. (e.g SLOT=$branch)


Still this is something could enjoy some more discussion.

As I stated long ago the main issue with the glep you proposed are the 
lack of informations in the document. You can fill every detail in 
mailing list as you like but if the document remains this way it doesn't 
get more informative.


lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero




Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-28 Thread Peter Volkov
В Втр, 24/02/2009 в 16:14 +0200, Serkan Kaba пишет:
 lucene-contrib eclass in java-experimental [1] sets EAPI to 1 to use
 slot deps. And I think that's a valid usage.
 
 1:
 http://overlays.gentoo.org/proj/java/browser/java-experimental/eclass/lucene-contrib.eclass

It's better (the only way...) to die in case an ebuild sets lower EAPI,
like kde4-functions.eclass does:

case ${EAPI} in
2) : ;;
*) die No way! EAPI older than 2 is not supported. ;;
esac

-- 
Peter.


signature.asc
Description: Эта  часть  сообщения  подписана  цифровой  подписью


Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-28 Thread Matthias Schwarzott
On Samstag, 28. Februar 2009, Peter Volkov wrote:
 В Втр, 24/02/2009 в 16:14 +0200, Serkan Kaba пишет:
  lucene-contrib eclass in java-experimental [1] sets EAPI to 1 to use
  slot deps. And I think that's a valid usage.
 
  1:
  http://overlays.gentoo.org/proj/java/browser/java-experimental/eclass/luc
 ene-contrib.eclass

 It's better (the only way...) to die in case an ebuild sets lower EAPI,
 like kde4-functions.eclass does:

 case ${EAPI} in
 2) : ;;
 *) die No way! EAPI older than 2 is not supported. ;;
 esac

I still dislike die in global scope, why not do it like autotools.eclass?
It does:
DEPEND=INCORRECT-WANT_AUTOCONF-SETTING-IN-EBUILD

Regards
Matthias



Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-28 Thread Robert Bridge
Petteri Räty wrote:
 2) EAPI in file extension
   - Allows changing global scope and the internal format of the ebuild
   a) .ebuild-eapi
 - ignored by current Portage
   b) .eapi.ebuild
 - current Portage does not work with this
   c) .eapi.new extension
 - ignored by current Portage

I have been thinking about this specific option. I will admit I don't
know if this has already been noted, but would this create the
possibility of multiple ebuilds with the same $C/$P-$PV?

Currently the filesystem enforces the uniqueness of that tuple, will
that uniqueness be allowed to lapse? (i.e. allow multiple ebuilds for
the same $C/$P-$PV with different EAPIs?)

If not, how is anyone proposing to enforce the uniqueness here?

Just a silly thought...
RobbieAB



Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-28 Thread Ciaran McCreesh
On Sat, 28 Feb 2009 19:39:36 +
Robert Bridge rob...@robbieab.com wrote:
 I have been thinking about this specific option. I will admit I don't
 know if this has already been noted, but would this create the
 possibility of multiple ebuilds with the same $C/$P-$PV?

GLEP 55 forbids it.

Note that it's already possible to have multiple equal versions of the
same thing (1.0_alpha0 equals 01.0_alpha-r0), and it's already
illegal. None of this is altered by any of the proposals.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-28 Thread Kumba

Kumba wrote:


I was talking to Alec last night in -dev (yes, I'm still alive), and I 
tossed out the idea of using metadata.xml instead of mangling the ebuild 
filename or even sticking it as the first line in the ebuild (as a 
hashbang or something gentoo-specific, for example).


Fleshing out more (And to solicit more thought on this idea -- insane?).

Using mips-sources as an example:

# ls -l /usr/portage/sys-kernel/mips-sources/*.ebuild

total 116K
-rw-r--r-- 1 root root  19K Jan  9 04:10 mips-sources-2.6.20.18.ebuild
-rw-r--r-- 1 root root  18K Jan  9 04:10 mips-sources-2.6.27.10.ebuild
-rw-r--r-- 1 root root  18K Feb 23 16:43 mips-sources-2.6.28.7.ebuild


Would, to specify them as EAPI=2 in metadata.xml, be encoded as (just an example 
-- suggest other formats):


eapi pv=2.6.20.18 ver=2 /
eapi pv=2.6.27.10 ver=2 /
eapi pv=2.6.28.7 ver=2 /

pv = specifies the package version
ver = eapi version.

Better names for these values? Suggest!  I didn't want to re-use 'api' or 
anything.  Maybe pms pv=2.6.28.7 eapi=2 / ?



Anyways, after commiting to gentoo-x86 CVS, a backend script, similar to or the 
same as whatever parses out the use tags will run and extract this data, and 
update /usr/portage/profiles/eapi.list  (example name).


/usr/portage/profiles/eapi.list will resemble something like this:

sys-kernel/mips-sources-2.6.20.18:2
sys-kernel/mips-sources-2.6.27.10:2
sys-kernel/mips-sources-2.6.28.7:2


Upon installing the package by whatever package manager (portage is my example), 
it will process this eapi.list, much like it does use.desc and use.local.desc, 
and therefore know all it needs to know, then it can source the ebuild and use 
whatever logic it needs to follow that specific EAPI.  That is if my assumption 
is correct that the usr.desc/use.local.desc stuff is parsed prior to the ebuild 
itself being sourced.  If not, well, I dunno then.  I'm guessing here.



The pros of this that I can see:
- No changes to the current filename structure.  Things stay the name, CVS 
history is retained because existing files aren't renamed (we're not on git just 
yet).
- No special markers, comments, or bash vars inside the ebuild.  Covers some of 
the other cons that were presented.
- Older package managers won't read eapi.list, and can resume their default 
behavior of EAPI=0.  Allows backwards compatibility.
- Newer package managers will assume a non-entry in eapi.list to equal EAPI=0, 
so there won't be a big rush to update every package/metadata in the tree. 
Allows for slow, controlled adoption.


Cons that I can see:
- metadata.xml gets updated more frequently because specific versions can get 
cited (workaround idea, see below)
- Backend has to do extra work (minimal?  Can infra comment on the feasibility 
of this?)


I'm suggesting this mostly because both ideas of embedding the EAPI value in the 
filename and inside the ebuild seem like ugly workarounds.  Others are also 
noting other problems with both of these approaches.  EAPI also feels more like 
a metadata-type thing anyways.  I mean, if we're already storing local USE flags 
in it, why not EAPI stuff?  I'm a tad behind on the whole discussion, I know, 
but why not toss the idea out there.



Some other thoughts on the first con, of metadata being updated more frequently 
-- we allow the use of wildcards:


eapi pv=* ver=2 /
Would mark every ebuild in the directory for a given EAPI value (EAPI=2 in this 
case)


eapi pv=2.6* ver=1 /
Marks every ebuild version lower than 2.6 as EAPI=1.

Basically, the wildcard modifiers Portage currently understands would apply.  Or 
we could limit it to a subset of these wildcards (say, *, , , =, and =).



Obviously, tools like repoman would need to be able to read metadata as well 
(can it?  I don't know) and make sure that the versions specified in the 'pv' 
value exist in the directory before commit.  Either by specific value or by 
expanding the wildcard notation and then cross-referencing the files listed in 
the directory and with CVS/git/whatever.



But to be honest, none of the ideas, even my own, seems like the best idea.  I 
think of mine as less intrusive to the tree and less visible to the end users 
and the package managers, but maybe there's other options not thought of yet?


--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org

The past tempts us, the present confuses us, the future frightens us.  And our 
lives slip away, moment by moment, lost in that vast, terrible in-between.


--Emperor Turhan, Centauri Republic



[gentoo-dev] dev-lang/python-2.6* unmask

2009-02-28 Thread Jesus Rivero

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello guys,

~ As some of you may know, Python-2.6 was launched on Oct 1st,  2008 
and have been sitting in the tree since Oct 5th. That is the official 
production version of the Python programming language. That means, 
python-2.5 is, according to the Python Project, officially old.


~  However, 2.6 version in the tree has been masked because some 
packages are affected by some minor changes in the language. We added a 
tracker bug [0] to keep maintainers informed of bugs/errors in their 
packages regarding the transition from 2.5 to 2.6.  This tracker was 
opened on June 30th 2008 and still has opened bugs.


~   The Python team has lay off a plan to unmask Python-2.6 in a 
month. In order to do so, we ask for your collaboration on fixing the 
bugs still opened in that tracker so we can unmask it safely. The 
majority of the bugs listed in there are relatively easy to fix and if 
you don't have the time to do it, please, don't hesitate to ask for our 
help, we'll be glad to give you a hand closing some of them (we just 
need a clear from the team or dev to do so)


~   Although those opened bugs are blocking the tracker already, 
I'll provide you with a compiled list so you don't even have to open a 
browser or open a shell to run bugz ;).


~   KDE Team:
~http://bugs.gentoo.org/show_bug.cgi?id=239233 - [PATCH] 
kde-base/superkaramba-3.5.10 should support dev-lang/python:2.6
~http://bugs.gentoo.org/show_bug.cgi?id=253582 - [PATCH] 
kde-base/dcoppython-3.5.10 fails with python-2.6


~Java Team:
~http://bugs.gentoo.org/show_bug.cgi?id=239479 - [PATCH] 
dev-java/javatoolkit fails with python-2.6
~http://bugs.gentoo.org/show_bug.cgi?id=246780 - 
dev-java/ant-core-1.7.1-r2 fails to build with dev-lang/python:2.6


~CJK Team:
~http://bugs.gentoo.org/show_bug.cgi?id=255210 - 
app-i18n/skim-1.4.5-r2 build fails with Python 2.6


~ SCI Team:
~http://bugs.gentoo.org/show_bug.cgi?id=258219 - 
dev-python/numpy-1.2.1 - selftest bugs though required for python-2.6 
compatibility


~Caster:
~http://bugs.gentoo.org/show_bug.cgi?id=243802 - 
app-office/taskcoach calls object.__init__ with arguments, which fails 
in python-2.6


~ Lack:
~ http://bugs.gentoo.org/show_bug.cgi?id=246786 - 
Version bump: dev-python/gdata-1.2.4


~  Proaudio:
~ http://bugs.gentoo.org/show_bug.cgi?id=251003 - 
[PATCH] media-libs/aubio-0.3.2-r1 not compatible with dev-lang/python-2.6


~  Matsuu:
~ http://bugs.gentoo.org/show_bug.cgi?id=258364 - 
sys-devel/distcc-3.1{,-r1} explictly compiles with python-2.5 even with 
python-2.6 selected


~ Thanks a lot for your help, we'll be waiting to hear from you.

~ Best regards,

[0] http://bugs.gentoo.org/show_bug.cgi?id=230205 - [TRACKER] Python-2.6 
incompatible packages



Jesus Rivero (Neurogeek)
Gentoo Python Team
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmqOmgACgkQdIssYB9vBoNryQCeICf6jUcfVdlhNEHRlKdPrK/d
VO8AnjCRDgbO/9zWw+Z2vBWt7egyrAYb
=8Xvr
-END PGP SIGNATURE-