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
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Ciaran McCreesh <ciaran.mccreesh@...>
Subject: Re: RFC: PROPERTIES=funky-slots
Date: Sat, 23 Jun 2012 17:53:24 +0100
On Sat, 23 Jun 2012 18:47:26 +0200
Justin <jlec@g.o> wrote:
> On 23.06.2012 18:17, Ciaran McCreesh wrote:
> > On Sat, 23 Jun 2012 18:13:23 +0200
> > Justin <jlec@g.o> wrote:
> >> Did you read what you wrote and thought about what you request from
> >> others? Probably you better should.
> > 
> > Uh huh, and I think we all know there's a huge difference between
> > knowing what versions and slots are and knowing what "a multilib"
> > is.
> > 
> 
> Might be right, but that doesn't allow you to break your own rules.
> Plus I still don't get the problem of using SLOTS in the way they are
> used now.

"My own rules" are that enough material is presented that the relevant
people understand it. If you look at simple proposals like usex, silent
rules or EBUILD_PHASE_FUNC, you'll see quite clearly that we ask for
very little in the way of text in cases where the change is easily
understood.

> And I can't find this out by simply googling. In contrast, an
> explanation of multilib in context of linux distribution and more
> specific gentoo can be found easily.

Oh really? I was under the impression that there wasn't even general
agreement upon whether or not multilib applied to "C" or to "C, and
Python, and things like it".

> Stop acting in this arrogant way you are doing right now.

Come on. Submitting a simple proposal with at least as much detail as
was provided for other, equally simple proposals is "arrogant" now?

> > That's covered in the devmanual and in the user documentation, so
> > there's no need to repeat it here.
> 
> Ever heard about references. They are good, if you don't like to
> repeat what is written, but which are necessary context to understand
> what you are writing. You should use them for the sake of
> understanding, if you are to lazy to write it out again.

Please take a look at the proposal for EBUILD_PHASE_FUNC, and say where
it references what "phase functions" are, or the proposal for usex and
say where it references what "use flags" are, or the proposal for
silent rules where it references what "econf" is.

> >> To me, it doesn't solve the root cause, but actually I can't judge
> >> this, because I am missing a description of what is really going
> >> wrong.
> > 
> > As I've already said, this isn't about solving the root cause. It's
> > about reducing the impact of damage that's already been done until
> > the root cause is solved properly.
> 
> My clear vote is No. We shouldn't implement anything which allows bad
> coding anywhere, just for the sake of having it "solved" now.

The bad coding has already happened. Are you volunteering to revert the
Ruby virtuals?

-- 
Ciaran McCreesh
Attachment:
signature.asc (PGP signature)
Replies:
Re: RFC: PROPERTIES=funky-slots
-- Pacho Ramos
Re: RFC: PROPERTIES=funky-slots
-- Justin
References:
RFC: PROPERTIES=funky-slots
-- Ciaran McCreesh
Re: RFC: PROPERTIES=funky-slots
-- Ciaran McCreesh
Re: RFC: PROPERTIES=funky-slots
-- Justin
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: RFC: PROPERTIES=funky-slots
Next by thread:
Re: RFC: PROPERTIES=funky-slots
Previous by date:
Re: RFC: PROPERTIES=funky-slots
Next by date:
Re: RFC: PROPERTIES=funky-slots


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.