Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Ciaran McCreesh]

On Sun, 24 Jul 2016 00:04:53 +0200
"Andreas K. Huettel"  wrote:
> 1) If a package only ever had one slot, it cannot ever have two
> versions installed at the same time. That guarantee (of only ever one
> slot) can be given for the portage tree (sic). Obviously it doesn't
> work for overlays, but there are many things we don't care about for
> overlays. [A]

Outright wrong, as has already been explained in this thread several
times.

> 2) If a package manager leaves two versions of a non-slotted package 
> "installed" somehow, that package manager is fundamentally broken and
> its author should forever refrain from specifying anything. It's not
> our job to work around Paludis failure modes. [B]

This is not a Paludis issue. It happens with Portage too. The install
sequence is carefully designed to install the new version of the
package, and then remove the old one (and if you think about it for a
few seconds, you can see that it *has* to be this way). If an error or
ctrl+c occurs at the wrong point, both versions remain installed, and
importantly, there is a safe way to recover from this.

-- 
Ciaran McCreesh

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Ciaran McCreesh]

On Sun, 24 Jul 2016 00:30:39 +0300
Andrew Savchenko  wrote:
> Oh, nice: strictly follow PMS no matter what, right? Then let me
> remind you that not so long time ago I advocated for strictly
> following PMS [1,2], which _allows_ || ( A:= B:= ) construct [3].
> 
> But I was _enforced_ by QA to _violate_ PMS and remove the valid
> syntax blocks [4]. This decision was made because of $reasons:
> - we lack ||= operator;
> - || ( := ) behaviour is not implemented properly in existing PM;
> - "it doesn't make *any* sense";
> - other valid and unquestionable $reasons ...
> 
> So the result is that common sense and practical considerations
> take over PMS. And what we have in the REPLACING_VERSIONS case?
> It doesn't matter that such situation never happened and will
> likely never happen, but one must follow PMS strictly no matter
> what. Such attitude is not fair at least.

No. You have simply failed to understand the reason || ( A:= B:= )
doesn't work. It may superficially appear correct, but you either need
to think carefully about the implications, or just accept wisdom from
people who have. I remind you that PMS does not explicitly prohibit a
dependency upon =A-1 =A-2 where A is not slotted, either: it's a
nonsense dependency, but syntactically valid.

Please stop trying to use your common sense in areas where you lack the
intuition and experience to have accurate common sense.

> Do we ever had such case like multiple versions of the same
> single-slotted package installed or recorded as installed in the
> real world? I'm not sure even in this, but I may assume that it may
> happen one day.

Yes, this happens with failures on uninstalls and upgrades.

> Do we have any proof that PM can recover from such situation,
> where VDB is a mess and installed files can also be a mess? I'm not
> sure in this at all.

Yes, things have been designed quite carefully to allow this to happen.
You recover by installing a new version, and using it to replace the
two installed versions simultaneously.

> Do we have any test suits for portage (as the most popular PM
> implementation) for such cases? I doubt this, I can find none. I'm
> not sure if such tests are implemented in other PM test suits too.

Portage doesn't exactly have many tests...

-- 
Ciaran McCreesh

[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Duncan]

Andreas K. Huettel posted on Sun, 24 Jul 2016 00:04:53 +0200 as excerpted:

> 1) If a package only ever had one slot, it cannot ever have two versions
> installed at the same time. That guarantee (of only ever one slot) can
> be given for the portage tree (sic). Obviously it doesn't work for
> overlays,
> but there are many things we don't care about for overlays. [A]

This is incorrect.  It arguably /might/ be correct if systems were 
guaranteed never to crash in the qmerge or old-version unmerge phases, 
but... the package manager must be able to deal with and recover from 
such crashes, and portage has done so for well over a decade, at least.  

(When I became a gentooer in 2004 I had faulty hardware, and the system 
would regularly crash during merges, sometimes repeatedly.  When I 
rebooted, all I had to do was restart the merge, and portage could pick 
up the pieces and deal with it, even back then.)

> 2) If a package manager leaves two versions of a non-slotted package
> "installed" somehow, that package manager is fundamentally broken and
> its author should forever refrain from specifying anything. It's not our
> job to work around Paludis failure modes. [B]

Not if it's the hardware that's broken, not the PM.  A good PM must be 
able to recover from the crash, and sort things out from it on a second, 
or third or tenth, attempt to actually get the upgrade done, this time 
/without/ crashing part way thru.

And broken ebuilds that can't deal with the situation don't help matters 
at all. =:^(

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Duncan]

Andrew Savchenko posted on Sun, 24 Jul 2016 00:30:39 +0300 as excerpted:

> Do we ever had such case like multiple versions of the same
> single-slotted package installed or recorded as installed in the real
> world? I'm not sure even in this, but I may assume that it may happen
> one day.
> 
> Do we have any proof that PM can recover from such situation,
> where VDB is a mess and installed files can also be a mess? I'm not sure
> in this at all.
> 
> Do we have any test suits for portage (as the most popular PM
> implementation) for such cases? I doubt this, I can find none. I'm not
> sure if such tests are implemented in other PM test suits too.

Think of how a package is upgraded (by portage, I don't know enough about 
the others to describe the process for them).  The package is built, then 
installed to a temporary location, then "qmerged" from the temporary 
location to the live filesystem, replacing the previous version's files 
and recording the new one in the installed-package database, then the old 
version is unmerged and its record removed from the installed-package 
database.

What happens if there's a crash in either the qmerge or old-version 
unmerge steps?

Right, now there's parts of two versions in the installed-package 
database, and who knows what files from each on the live filesystem.

I'm not a portage dev so won't comment on the test suite angle, but 
portage has been able to handle this with the user simply redoing the 
upgrade (whether from binpkg or full rebuild) for many years now (singe 
before I became a gentooer in 2004, I know as I had some faulty hardware 
at the time and regularly crashed during build and installs, which was 
likely before REPLACING_VERSIONS was a thing), and given the number of 
installations out there and the stress of parallel-building some packages 
while others are installing, the code to handle this is GOING to get 
regularly tested.

This needs to continue to work, thus the PMS rules, and ebuilds that are 
unprepared to deal with it aren't going to help.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

[Chí-Thanh Christopher Nguyễn]

Michał Górny schrieb:

Ensure that proper number of parameters is passed to each versionator
function; die otherwise. This prevents the functions from proceeding
with undefined behavior when mis-called.


You are making what versionator.eclass accepts stricter. That it used to work 
when passed multiple versions may be unintentional, but I think you need to 
introduce a new eclass or new function names in this case.



Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Freitag, 22. Juli 2016, 15:57:36 schrieb Ciaran McCreesh:

> > > Wrong. PMS specifically requests you to account for such a
> > > possibility.
> > 
> > Common sence must prevail over formal approaches. While PMS is
> > great, it is not perfect in all possible aspects, and this one is
> > one of them.

[snipping irrelevant blather]

> Slots are not the only way in which you can end up with multiple
> installed versions of the same package. Another way is if there's a
> fatal error during certain parts of the upgrade process.

1) If a package only ever had one slot, it cannot ever have two versions 
installed at the same time. That guarantee (of only ever one slot) can be 
given for the portage tree (sic). Obviously it doesn't work for overlays, 
but there are many things we don't care about for overlays. [A]

2) If a package manager leaves two versions of a non-slotted package 
"installed" somehow, that package manager is fundamentally broken and its 
author should forever refrain from specifying anything. It's not our job to 
work around Paludis failure modes. [B]


[A] Let's say there are overlays which package StarOffice, Go-OOO and some 
other random OOO fork. Do I have to block them all because of file collisions 
then?

[B] The package manager could be broken to leave some random files on the 
system too... maybe we need some more blockers or specific error handling in 
all ebuilds?



- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXk+oFXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB
NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkQwQQAM88pp4BmTT3CyrQ41QyAFOj
iPvhL2Qxv22Zp5hJB0lKatElsJkswDKGZiXbQvjvUqCaaywy9IbtjatNEnsLC7ku
CNgFNmbasAAp2E8LC/y10FiF2Uf/mWOr/b9D+22UrgiK82geXiRG1zpJR5pb9wDU
SyHX/GS308SSwgUoTYu8T8j7fAZy22632ve82LXOsvdCfLxQp6HwGKiDrVeKFg+b
xc9OFW7NKWZwzMCb0nKErNjaO9SuH+ZDK9jB3oERjMNRiihiI6VEmLSnyIKNyEt0
R6xLWQXSYmekjLBYogK2p+pG8LxKj00utlfGePhWoF0RJ0Z/U38sb4S78zAXh9mW
Dc+nurOBqE0y7so9NZMUXwyqvZqja9eGh2uJwnu6yRxG1D1F/ZAIa6YDjeBCH9vX
wLAzxzvpeB2GxQD2HE8QFmMdq87h3PPBY8mFodi4R1me3wt3av+OEuGGlM1L0HyX
WQ2ScxpABCrlY66ThZDG5mgiflYQxcQREtbwgXQYFblP/PVsm0wSkidcqj96eab6
YXqSgl4nplHQpG17PgyxRU2b6++38asyXQ8oD6cbPkciHvJS9mrDRbGCFtlzOnm5
q8FbP+5TtJRGSrpVSCuQBGVTW23uvhpObhw+JoGKKPW9J/VhCNzGBhoOMrEvldOy
aB8qXiP0UYzCvsBBwqVj
=/Qrt
-END PGP SIGNATURE-

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

On Fri, 22 Jul 2016 15:49:55 +0200 Michał Górny wrote:
> On Fri, 22 Jul 2016 16:41:56 +0300
> Andrew Savchenko  wrote:
> 
> > On Fri, 22 Jul 2016 13:14:23 +0200 Michał Górny wrote:
> > > Dnia 22 lipca 2016 13:00:42 CEST, Andrew Savchenko  
> > > napisał(a):  
> > > >On Thu, 21 Jul 2016 07:12:12 +0200 Michał Górny wrote:  
> > [...]
> > > >> Few important QA notes:
> > > >> 
> > > >> 1. < is lexicographical comparison, so e.g. 1.6.2.2 < 1.6.18.2 gives
> > > >> false,  
> > > >
> > > >Thanks, fixed.
> > > >  
> > > >> 2. REPLACING_VERSIONS can have more than one value,  
> > > >
> > > >While it can indeed, I see no way for this to happen if package
> > > >hasn't and never had multiple slots.  
> > > 
> > > Wrong. PMS specifically requests you to account for such a possibility.  
> > 
> > Common sence must prevail over formal approaches. While PMS is
> > great, it is not perfect in all possible aspects, and this one is
> > one of them.
> > 
> > I see no point in trashing ebuilds with dead code that will never
> > be used. Though if there will be a PMS or eclass function with
> > "proper" implementation, I don't mind, since extra code will be
> > moved from ebuild elsewhere.
> 
> So are you officially refusing to follow the PMS based on your idea of
> 'common sense' and ignoring the specific reasons it was written like
> that? I should put my QA hat on, and request official action upon your
> refusal.
 
No, but I do ignore threats, at least for the time being.

Best regards,
Andrew Savchenko


pgpXXfXwy4VYh.pgp
Description: PGP signature

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

On Sat, 23 Jul 2016 15:38:26 +0100 Ciaran McCreesh wrote:
> On Sat, 23 Jul 2016 17:23:48 +0300
> Andrew Savchenko  wrote:
> > On Fri, 22 Jul 2016 14:57:36 +0100 Ciaran McCreesh wrote:
> > > On Fri, 22 Jul 2016 16:41:56 +0300
> > > Andrew Savchenko  wrote:  
> > [...]
> > > > I see no point in trashing ebuilds with dead code that will never
> > > > be used. Though if there will be a PMS or eclass function with
> > > > "proper" implementation, I don't mind, since extra code will be
> > > > moved from ebuild elsewhere.  
> > > 
> > > Slots are not the only way in which you can end up with multiple
> > > installed versions of the same package. Another way is if there's a
> > > fatal error during certain parts of the upgrade process.  
> > 
> > If setup is broken to the point when several version within single
> > slot are installed (or are reported to be installed), then:
> > 
> > 1) There is no way to tell which version is valid and all of them
> > may be invalid. That's why REPLACING_VERSIONS is of no use at all
> > in such situation.
> > 
> > 2) System is severely broken and mistakenly shown (or not shown)
> > ewarn message will be the least problem for a user of such system.
> 
> Uh, nope. The PM can recover from that situation, so long as people
> don't go around writing broken ebuilds that make unwarranted
> assumptions that the spec specifically tells them not to make. Don't
> get into the habit of writing broken code.

Oh, nice: strictly follow PMS no matter what, right? Then let me
remind you that not so long time ago I advocated for strictly
following PMS [1,2], which _allows_ || ( A:= B:= ) construct [3].

But I was _enforced_ by QA to _violate_ PMS and remove the valid
syntax blocks [4]. This decision was made because of $reasons:
- we lack ||= operator;
- || ( := ) behaviour is not implemented properly in existing PM;
- "it doesn't make *any* sense";
- other valid and unquestionable $reasons ...

So the result is that common sense and practical considerations
take over PMS. And what we have in the REPLACING_VERSIONS case?
It doesn't matter that such situation never happened and will
likely never happen, but one must follow PMS strictly no matter
what. Such attitude is not fair at least.

> Or to put it another way: you are wrong, and you don't know enough
> about the situation to understand why you're wrong, and you clearly
> have no interest in learning, so just do as you're told.

I don't deny that I may be wrong on this matter, but I demand a
proof, an experimental one. And I see no such proof, only
theoretical considerations without any practical confirmation.

Do we ever had such case like multiple versions of the same
single-slotted package installed or recorded as installed in the
real world? I'm not sure even in this, but I may assume that it may
happen one day.

Do we have any proof that PM can recover from such situation,
where VDB is a mess and installed files can also be a mess? I'm not
sure in this at all.

Do we have any test suits for portage (as the most popular PM
implementation) for such cases? I doubt this, I can find none. I'm
not sure if such tests are implemented in other PM test suits too.

[1] 
https://archives.gentoo.org/gentoo-dev/message/abd0c82b058aa0109c12050ae837fba0
[2] https://bugs.gentoo.org/show_bug.cgi?id=586238#c1
[3] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-780008.2
[4] https://bugs.gentoo.org/show_bug.cgi?id=586326

Best regards,
Andrew Savchenko


pgpe7YIXYhr4n.pgp
Description: PGP signature

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Ciaran McCreesh]

On Sat, 23 Jul 2016 17:23:48 +0300
Andrew Savchenko  wrote:
> On Fri, 22 Jul 2016 14:57:36 +0100 Ciaran McCreesh wrote:
> > On Fri, 22 Jul 2016 16:41:56 +0300
> > Andrew Savchenko  wrote:  
> [...]
> > > I see no point in trashing ebuilds with dead code that will never
> > > be used. Though if there will be a PMS or eclass function with
> > > "proper" implementation, I don't mind, since extra code will be
> > > moved from ebuild elsewhere.  
> > 
> > Slots are not the only way in which you can end up with multiple
> > installed versions of the same package. Another way is if there's a
> > fatal error during certain parts of the upgrade process.  
> 
> If setup is broken to the point when several version within single
> slot are installed (or are reported to be installed), then:
> 
> 1) There is no way to tell which version is valid and all of them
> may be invalid. That's why REPLACING_VERSIONS is of no use at all
> in such situation.
> 
> 2) System is severely broken and mistakenly shown (or not shown)
> ewarn message will be the least problem for a user of such system.

Uh, nope. The PM can recover from that situation, so long as people
don't go around writing broken ebuilds that make unwarranted
assumptions that the spec specifically tells them not to make. Don't
get into the habit of writing broken code.

Or to put it another way: you are wrong, and you don't know enough
about the situation to understand why you're wrong, and you clearly
have no interest in learning, so just do as you're told.

-- 
Ciaran McCreesh

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

Hi,

On Fri, 22 Jul 2016 14:57:36 +0100 Ciaran McCreesh wrote:
> On Fri, 22 Jul 2016 16:41:56 +0300
> Andrew Savchenko  wrote:
[...]
> > I see no point in trashing ebuilds with dead code that will never
> > be used. Though if there will be a PMS or eclass function with
> > "proper" implementation, I don't mind, since extra code will be
> > moved from ebuild elsewhere.
> 
> Slots are not the only way in which you can end up with multiple
> installed versions of the same package. Another way is if there's a
> fatal error during certain parts of the upgrade process.

If setup is broken to the point when several version within single
slot are installed (or are reported to be installed), then:

1) There is no way to tell which version is valid and all of them
may be invalid. That's why REPLACING_VERSIONS is of no use at all
in such situation.

2) System is severely broken and mistakenly shown (or not shown)
ewarn message will be the least problem for a user of such system.

Best regards,
Andrew Savchenko


pgpGCutBSMD6r.pgp
Description: PGP signature

[gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

[Michał Górny]

Ensure that proper number of parameters is passed to each versionator
function; die otherwise. This prevents the functions from proceeding
with undefined behavior when mis-called. However, it does not cover the
most common mistake of passing an empty version that implicitly gets
replaced by ${PV}.
---
 eclass/versionator.eclass | 39 ++-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/eclass/versionator.eclass b/eclass/versionator.eclass
index 74e676ee..e42fc4d 100644
--- a/eclass/versionator.eclass
+++ b/eclass/versionator.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2014 Gentoo Foundation
+# Copyright 1999-2016 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Id$
 
@@ -46,6 +46,8 @@ get_all_version_components() {
local ver_str=${1:-${PV}} result
result=()
 
+   [[ $# -le 1 ]] || die "${FUNCNAME}: too many parameters ($#)"
+
# sneaky cache trick cache to avoid having to parse the same thing 
several
# times.
if [[ ${VERSIONATOR_CACHE_VER_STR} == ${ver_str} ]] ; then
@@ -101,6 +103,8 @@ get_all_version_components() {
 # 20040905->  20040905
 # 3.0c-r1 ->  3 0 c r1
 get_version_components() {
+   [[ $# -le 1 ]] || die "${FUNCNAME}: too many parameters ($#)"
+
local c=$(get_all_version_components "${1:-${PV}}")
echo ${c//[-._]/ }
 }
@@ -115,6 +119,8 @@ get_version_components() {
 # 20040905->  20040905
 # 3.0c-r1 ->  3
 get_major_version() {
+   [[ $# -le 1 ]] || die "${FUNCNAME}: too many parameters ($#)"
+
local c=($(get_all_version_components "${1:-${PV}}"))
echo ${c[0]}
 }
@@ -128,6 +134,9 @@ get_major_version() {
 #1-21.2.3   -> 1.2
 #2- 1.2.3   -> 2.3
 get_version_component_range() {
+   [[ $# -ge 1 ]] || die "${FUNCNAME}: no range provided"
+   [[ $# -le 2 ]] || die "${FUNCNAME}: too many parameters ($#)"
+
eshopts_push -s extglob
local c v="${2:-${PV}}" range="${1}" range_start range_end
local -i i=-1 j=0
@@ -161,6 +170,8 @@ get_version_component_range() {
 # 20040905->  (empty string)
 # 3.0c-r1 ->  0c-r1
 get_after_major_version() {
+   [[ $# -le 1 ]] || die "${FUNCNAME}: too many parameters ($#)"
+
echo $(get_version_component_range 2- "${1:-${PV}}")
 }
 
@@ -175,6 +186,9 @@ get_after_major_version() {
 # Rather than being a number, $1 can be a separator character such as '-', '.'
 # or '_'. In this case, the first separator of this kind is selected.
 replace_version_separator() {
+   [[ $# -ge 2 ]] || die "${FUNCNAME}: required parameters missing"
+   [[ $# -le 3 ]] || die "${FUNCNAME}: too many parameters ($#)"
+
eshopts_push -s extglob
local w c v="${3:-${PV}}"
declare -i i found=0
@@ -210,6 +224,9 @@ replace_version_separator() {
 # Replace all version separators in $2 (defaults to $PV) with $1.
 # '_' 1b.2.3-> 1b_2_3
 replace_all_version_separators() {
+   [[ $# -ge 1 ]] || die "${FUNCNAME}: no replacement provided"
+   [[ $# -le 2 ]] || die "${FUNCNAME}: too many parameters ($#)"
+
local c=($(get_all_version_components "${2:-${PV}}"))
c=${c[@]//[-._]/$1}
echo ${c// }
@@ -226,6 +243,9 @@ replace_all_version_separators() {
 # Rather than being a number, $1 can be a separator character such as '-', '.'
 # or '_'. In this case, the first separator of this kind is deleted.
 delete_version_separator() {
+   [[ $# -ge 1 ]] || die "${FUNCNAME}: no index provided"
+   [[ $# -le 2 ]] || die "${FUNCNAME}: too many parameters ($#)"
+
replace_version_separator "${1}" "" "${2}"
 }
 
@@ -235,6 +255,8 @@ delete_version_separator() {
 # Delete all version separators in $1 (defaults to $PV).
 # 1b.2.3-> 1b23
 delete_all_version_separators() {
+   [[ $# -le 1 ]] || die "${FUNCNAME}: too many parameters ($#)"
+
replace_all_version_separators "" "${1}"
 }
 
@@ -245,6 +267,8 @@ delete_all_version_separators() {
 # 1.0.1   ->  3
 # 3.0c-r1 ->  4
 get_version_component_count() {
+   [[ $# -le 1 ]] || die "${FUNCNAME}: too many parameters ($#)"
+
local a=($(get_version_components "${1:-${PV}}"))
echo ${#a[@]}
 }
@@ -257,6 +281,8 @@ get_version_component_count() {
 # 1.0.1   ->  2
 # 3.0c-r1 ->  3
 get_last_version_component_index() {
+   [[ $# -le 1 ]] || die "${FUNCNAME}: too many parameters ($#)"
+
echo $(($(get_version_component_count "${1:-${PV}}" ) - 1))
 }
 
@@ -267,6 +293,9 @@ get_last_version_component_index() {
 # only. May not be reliable, be sure to do very careful testing before actually
 # using this.
 version_is_at_least() {
+   [[ $# -ge 1 ]] || die "${FUNCNAME}: wanted version not provided"
+   [[ $# -le 2 ]] || die "${FUNCNAME}: too many parameters ($#)"
+
local want_s="$1" have_s="${2:-${PVR}}" r
version_compare 

Re: [gentoo-dev] [RFC] lua.eclass

[Michał Górny]

Dnia 20 lipca 2016 15:36:20 CEST, "Vadim A. Misbakh-Soloviov"  
napisał(a):
>Hi there!
>
>I've done (actualy, long time ago) lua.eclass to ease maintenance of
>dev-lua 
>packages in a way of dev-ruby and dev-python packages (including
>TARGETS and 
>so).
>
>All ebuilds in lua overlay is already ported to it (in basic way),
>although I 
>recently added GITHUB_* and BITBUCKET_* magic (like rubygems and perl
>CPAN 
>magic), and still not finished porting ebuilds to it (although, I maybe
>finish 
>it until tonight).
>
>So, I posting it to review and comments. And to ask your opinion about
>it's 
>inclusion in the tree.
>
>P.S. after few days (depends on comments in this thread) it may differ
>from 
>up-to-date version in overlay.

I'm going to review it in more detail when I am able to. However, from a quick 
glance -- please don't commit it. It requires a lot of work. In fact, it is the 
worst idea since base.eclass, and it looks like base.eclass reinvented tenfold.


-- 
Best regards,
Michał Górny (by phone)