public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Enough about GLEP5{4,5}
Date: Mon, 8 Jun 2009 19:35:22 +0100	[thread overview]
Message-ID: <20090608193522.751a66a3@snowcone> (raw)
In-Reply-To: <2144523.vh3QGIWsHC@news.friendly-coders.info>

[-- Attachment #1: Type: text/plain, Size: 3922 bytes --]

On Mon, 08 Jun 2009 19:17:56 +0100
Steven J Long <slong@rathaus.eclipse.co.uk> wrote:
> If the problem had been adequately communicated in the first place
> (which is pretty much required for any proposal ime) instead of people
> being told they "don't understand so go away" we could have agreed
> then, that the issue was simply about knowing the EAPI before
> sourcing.

That is not what the issue is. That is half of what the issue is.

> As it is, we _finally_ have grudging submission that tightening the
> PMS to reflect QA reality works but is not "the best solution."

No, it would not be to reflect reality. We would have to tighten the
rules in such a way that it breaks things people have already done, and
if we were to do so it would either impose performance penalties or not
allow us the full scope of changes, and it would still require us to
wait a year or more before going ahead with any of these changes.

> (Even though the case for changing version format has not been made,

The Council disagrees.

> the argument applies to the other incompatible changes affecting
> global environment.)

No, that's a separate issue, and does not have the same performance
implications.

> Firstly, and most significantly, this only applies when the mangler
> does not have the ebuild metadata in cache.

Not true.

> Bear in mind portage automatically caches overlays
> under /var/cache/edb

You are confusing the dep cache with the metadata cache. They are not
the same thing.

> Secondly, for the mangler to determine the "best-visible", EAPI is
> not the only item under consideration. So again, there is a lie
> implicit: whether from cache or from file, the mangler will ALWAYS
> need some metadata on the ebuilds; CPV + EAPI is insufficient.

It currently, and will still with 55, require metadata from only *some*
ebuilds (usually just one). You're talking about making it require
metadata from all of the ebuilds.

> At very best, all EAPI in filename (wherever it is) does, is limit
> the set of ebuilds to those with a supported EAPI before the cache
> has to be consulted. For Gentoo users (who update as recommended)
> using Gentoo product, that's _every_ ebuild in the tree and overlays.

Er, no. It means we only have to consult any file at all for the best
version, and then go backwards down versions until we find a visible
version.

> So what practically are we accomplishing for our users?

We are letting package manager people make the changes needed so that
developers can write better ebuilds.

> And how much developer time would be wasted to do so, and indeed has
> already been wasted on this?

Thanks to emails like yours, lots.

> (If you don't think it is a problem, please feel free to say
> so /without/ resorting to insult over reason. If you think the
> proposal had merit: how come we've only now got agreement that
> easily-extractable EAPI works?)

Easily-extractable EAPI either has change scope limitations or a
considerable performance impact.

GLEP 55's getting nowhere because a small group of religious fanatics
are doing anything they can to derail it because it came from "the
wrong people". If you want to know the kind of arguments that are being
thrown against GLEP 55 now, just have a look at:

22:54 < ciaranm> it's been established by precedent that gleps propose
an enhancement, and that competing enhancements get their own gleps
22:55 < bonsaikitten> well, we claim precedent on this one
22:55 < bonsaikitten> so there :)
22:55 < ciaranm> point to your precedent please
22:55 < bonsaikitten> it is the precedent
22:56 < ciaranm> bonsaikitten: uh... i don't think you know what that
means..
22:56 < bonsaikitten> ciaranm: you refuse to accept time travel

Yup, the argument of the week against GLEP 55 is that we refuse to
accept time travel.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  parent reply	other threads:[~2009-06-08 18:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-07 15:54 [gentoo-dev] Enough about GLEP5{4,5} Rémi Cardona
2009-06-07 16:16 ` Roy Bamford
     [not found]   ` <2144523.vh3QGIWsHC@news.friendly-coders.info>
2009-06-08 18:35     ` Ciaran McCreesh [this message]
2009-06-08 20:20       ` Roy Bamford
2009-06-08 20:41       ` Patrick Lauer
2009-06-08 21:03         ` Dawid Węgliński
2009-06-08 21:32           ` Ulrich Mueller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090608193522.751a66a3@snowcone \
    --to=ciaran.mccreesh@googlemail.com \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox