On Sat, 23 Jun 2012 14:16:13 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> What we *also* need is to document this requirements to let people
> present that work directly instead of losing days figuring out what is
> needed or what not

The requirement is that the PMS team needs to be able to understand the
proposal, and that someone needs to do however much work is necessary
(which varies massively from proposal to proposal -- multilib is
at least a thousand times more complicated than adding a new function
that outputs stuff based upon a use flag) to be able to present it in a
form acceptable to the Council. That's all there is to it. There is no
lengthy form P123b.5 to fill in or anything like that.

--
Ciaran McCreesh

El sáb, 23-06-2012 a las 13:16 +0100, Ciaran McCreesh escribió:
> On Sat, 23 Jun 2012 14:11:28 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> > Looks like you have now opted to use Brian's comment as a kind of
> > "shield" of similar and discuss only about multilib, even when this
> > thread was more general and we were talking to the problems shown in
> > recent discussions (from forcing rebuilds issue, optional deps
> > problems to some trivial questions like know where we can see what
> > things are being worked out for eapi5).
>
> For optional deps, we're close to having two proposals. That's moving
> forwards. Whether or not it will be in EAPI 5 depends solely upon
> timing, and whether the Council ends up liking at least one of the two
> proposals.
>
> For "forced rebuilds", there's a proposal already, and Zac has just
> done implementation work, and most of the PMS patch was written ages
> ago for kdebuild-1 and the original EAPI 3. So again, whether or not
> that ends up in EAPI 5 is just a matter of timing and Council approval.
>
> For "what's being worked on", you just need to look at the PMS list.
>
> So I'm really not sure what your problem is there...
>

Your cynicism, that is the problem I see

Rich Freeman posted on Sat, 23 Jun 2012 07:12:29 -0400 as excerpted:

> You can't fix it by beating people up.

Volunteers do it on their own terms... or don't do it. The outliers can
be moderated to some degree and thankfully the list isn't what it once
was, but get too strict and people simply find other things to do. Of
course there's a line where letting them find something else to do is
best, and some have crossed it, but...

> 1. While perhaps a different leader might give people a warmer feeling
> about it, I think many of these issues are just inherent to the nature
> of the problem - PM features don't write themselves. Others might
> disagree, and that is fine.
>
> 2. I don't see anybody else stepping up.

Good points. (Whole post actually, but snipped for brevity.) To some
extent, the job of coordinating PMS is going to be a (nearly) thankless
task, and it does take a specific kind of person to keep at it. Not
everybody's cut out for it. You're right, others /aren't/ stepping up
for it and I can't blame them. Thanks for pointing out what we likely
all knew if we thought about it, but many (me included) sometimes forget.


Back to my original point, tho. Seeing people working on other PMs make
the point as well, helps, and I hope to see both a bit more of that and
more reminders of it in other subthreads/replies, where appropriate. I
know that helps me keep a bit better perspective. =:^)

--
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

On Wednesday 20 June 2012 16:39:42 Maxim Kammerer wrote:
> On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao wrote:
> > Multilib (and/or multiarch) support
>
> Sorry for a possibly ignorant question. Does multilib support include
> the ability to build Busybox against uclibc (on a glibc system)?

i'm not sure Richard knows exactly what he is asking for. multilib does not
cover different C libraries, but multiarch does. the former is what Thomas has
been working on (multilib portage) while the later is basically cross-
compiling (use crossdev) and is unrealistic for EAPI=5 integration (and i
might even say isn't really a problem anymore that needs "solving").
-mike

On Wednesday 20 June 2012 16:25:30 Richard Yao wrote:
> Multilib (and/or multiarch) support

Thomas already has multilib documents put together for review. multiarch
doesn't make sense for us, and even if it did, there's no way it'd be spec-ed
out in a reasonable time frame for EAPI=5 (or even 6 or 7 or ...).

> The current binaries cause a great deal of pain, particularly when a
> user does not want to upgrade something. I had this problem with WINE
> and glibc because I wanted to avoid the reverse memcpy() fiasco on my
> systems. This situation would have been avoided entirely if the package
> manager supported multilib.

i don't buy this argument and makes me think when you say "multilib", you
don't actually mean "multilib".

> Automated epatch_user support
> Users should be able to test patches without modifying their ebuilds.
> This also saves developer time because we don't need to navigate the
> portage tree (or an overlay), make a change and test it. We could just
> dump the patch in the appropriate directory and build.

putting forth an idea is one thing. working out the technical aspects is
different. this sounds like something destined for EAPI=6: currently,
epatch_user uses epatch, and that provides a lot of dynamic patch support that
doesn't fit well with being spec-ed out / encoded in PMS.

> Parallel make checks

SGTM

> POSIX Shell compliance
> There has been a great deal of work done to give the user full control
> of what is on his system and there is more that we can do there. In
> particular, I think a lean Gentoo Linux system should be able to use
> busybox sh and nothing else. That requires POSIX shell compliance.
> OpenRC init scripts support this and the configure scripts support this.
> The few exceptions are bugs that are addressed by the Gentoo BSD
> developers. As such, I think we should make EAPI=5 use POSIX shell by
> default. If an ebuild requires bash, we can allow the ebuild to declare
> that (e.g. WANT_SH=bash), but that should be the exception and not the
> rule.

not a chance, and your logic about "choice" really makes no sense in the
ebuild context. read the archives wrt Roy Maples (sadly) burning out for in-
depth details as to why this is a no-go.
-mike

On Thursday 21 June 2012 08:11:27 Homer Parker wrote:
> On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote:
> > In case you're not aware, the first time Gentoo did multilib, it was
> > done as a series of random changes to Portage that no-one really
> > thought through or understood. As you can see, that didn't work...
>
> No, but paved the way for other distros as they had nothing even close.
> I'm sure you remember back then. Don't be an ass.

many distros still don't. ever try Debian on ppc64 ?
-mike

On Thursday 21 June 2012 03:00:39 Ciaran McCreesh wrote:
> In case you're not aware, the first time Gentoo did multilib, it was
> done as a series of random changes to Portage that no-one really
> thought through or understood. As you can see, that didn't work...

yes yes, it's very easy to throw rocks in hindsight at developers who, quite
literally, were in completely new waters. not just in the Gentoo/PMS world,
but in multilib *anywhere* (other distros, upstream packages, etc...). i'd
say it's almost as easy as shooting fish in a barrel, but mythbusters proved
that's actually kind of hard.
-mike