way it is now -- delivering at best the
same user experience now that it was several years ago, in an
increasingly difficult and more competitive environment.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ow where EAPI changes are discussed? (Google and the
> Bugtracker didn't yield a useful reply.)
The best way is to make a carefully thought out proposal, mail it to
this list and it'll get picked up.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
u've been
posting or ignorant enough to miss the point so badly. So please stop
pretending -- this issue would have gone through a long time ago were
it not for you and your ilk deliberately pretending to be retarded so
you can raise straw man arguments against it rather than addressing the
issues at hand. You're doing both yourself and everyone else a huge
disfavour by acting dumb and assuming everyone else is going to play
along with that.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
mean, hombre, did you even
> READ my email, or do you just apply prewritten text blocks in the
> hope of solving issues like most "technical" "support" does?
Please explain why you claimed GLEP 55 makes things slower. Until you
answer that, it's hard to take you for anything other than a troll.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Thu, 14 May 2009 21:09:58 +0200
Tomáš Chvátal wrote:
> Dne čtvrtek 14 Květen 2009 20:39:07 Ciaran McCreesh napsal(a):
> > Where on earth are you getting the idea that GLEP 55 makes things
> > slower? The only difference to the code with GLEP 55 is in checking
> > file
On Thu, 14 May 2009 13:17:24 -0600
RB wrote:
> On Thu, May 14, 2009 at 13:11, Ciaran McCreesh
> wrote:
> > Please explain why you claimed GLEP 55 makes things slower. Until
> > you answer that, it's hard to take you for anything other than a
> > troll.
>
> He
scope until the whole "can't
make global scope changes" thing is sorted out.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ntroducing any new cache
will only slow things down, not speed them up.
And you still haven't justified how glep 55 makes it slower.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ke appropriate action?
It can't, because it doesn't know the EAPI until it's sourced the thing
using bash. Using things like += in global scope will break older bash
versions to the point that they can't reliably extract EAPI.
- --
Ciaran McCreesh
-BEGIN PGP S
ompatible up until the EAPI declaration in the ebuild.
No, that still wouldn't help, because the package manager doesn't know
that what it thinks is the 'latest' EAPI (not that there really is such
a thing -- EAPIs aren't a linear sequence) actually is the 'latest'
EAPI.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
27;s the big one, not the other two.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
I is either
known or unsupported, but if known may be unspecified. If it is known
but unspecified, the package manager treats it as equivalent to EAPI 0.
Conceptually, these aren't the same thing.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 15 May 2009 14:43:29 -0500
William Hubbs wrote:
> On Thu, May 14, 2009 at 10:53:37PM +0100, Ciaran McCreesh wrote:
> > It can't, because it doesn't know the EAPI until it's sourced the
> > thing using bash. Using things like += in global scope will break
re in the second camp.
> In passing, I must express bewildered amusement at the idea of a
> format with an unlimited amount of extensions.
Not what's being proposed. We're proposing giving each format its own
file extension.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
is is a major nuisance, but is
unfortunately considered a feature.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
e. It's considered by some to be a QA violation, but EAPI's rules
are the same as the rules for any other metadata variable.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ety of changes
argument, people refuse to talk about it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
formats. We cannot AFFORD to look the other way
> while the distro rots away.
Part of the reason the distro is rotting away is that isn't delivering
anything new. I'll remind you that EAPIs 2 and 3 fix several extremely
major user complaints.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sat, 16 May 2009 15:50:39 +0100
Steven J Long wrote:
> Ciaran McCreesh wrote:
> > On Sat, 16 May 2009 11:27:10 +0200
> > Tobias Klausmann wrote:
> >> Change the spec, then.
> >
> > If we change the spec, we can't do anything with the change until
On Sat, 16 May 2009 11:15:58 -0400
Richard Freeman wrote:
> Ciaran McCreesh wrote:
> > You've missed the point. The point is, the EAPI process can't avoid
> > the "huge wait before we can use it" for certain types of change
> > that would be extremely u
On Sat, 16 May 2009 17:32:24 +0200
Tobias Klausmann wrote:
> On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > On Sat, 16 May 2009 11:27:10 +0200
> > Tobias Klausmann wrote:
> > > Change the spec, then.
> >
> > If we change the spec, we can't do anything w
On Sat, 16 May 2009 11:34:14 -0400
Richard Freeman wrote:
> Ciaran McCreesh wrote:
> > Had we gone with any of the other proposals a year ago, we'd be
> > waiting a year every time a new change came along.
>
> Only if that change prevented obtaining EAPI from wherever i
re do hope there are no plans on
> making those changes as often as new EAPIs.
Yes, those. The current rules include some pointless arbitrary
restrictions that are only there for historical reasons and that mean
people have to mess with convoluted MY_PV things.
--
Ciaran McCreesh
sign
obably will be, and we don't know what they all are yet.
Unfortunately we can't see the future.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sat, 16 May 2009 18:15:58 +0200
Tobias Klausmann wrote:
> On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > Tobias Klausmann wrote:
> > > > Yes, those. The current rules include some pointless arbitrary
> > > > restrictions that are only there for historical rea
On Sat, 16 May 2009 18:31:38 +0200
Tobias Klausmann wrote:
> On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for
> > > EAPI=3 etc? That would just be silly and it was the first idea I
> > > got when I
no
good reason, for example, that _alpha is legal but -alpha is not; both
are common.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
lems that we don't know
> exist easier.
Ok, what are all the things requiring format-break changes that we'll
want in the next ten years? Please provide a complete list.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
t need in two years? I suspect not. Neither do I (or just
> about anybody else). I just think the hoops we have to jump
> through now to tackle hypothetical problems in two (or ten) years
> aren't worth it.
That's my point -- I don't pretend to know what we'll need in the
future, so I don't advocate a solution that requires that we do know.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sat, 16 May 2009 22:24:04 +0530
Arun Raghavan wrote:
> On Sat, 2009-05-16 at 17:47 +0100, Ciaran McCreesh wrote:
> > Ok, what are all the things requiring format-break changes that
> > we'll want in the next ten years? Please provide a complete list.
>
> Don't
our package manager to give you the information you
require.
> And I don't pretend that I know a way to ensure that the change
> will be easy. So I advocate *not* going out of our way to comfort
> that possible Mother of All Changes.
This isn't some hypothetical possible change t
On Sat, 16 May 2009 22:39:46 +0530
Arun Raghavan wrote:
> On Sat, 2009-05-16 at 17:59 +0100, Ciaran McCreesh wrote:
> > > Don't care. Let's fix the problems we have *now* using solutions
> > > that we can agree upon, rather than try to foist solutions that a
>
it.
But eclasses have tried changing it. This is something people have
done, not some hypothetical.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
This is already how things work for existing equivalent but
not stringwise-equal versions.
> Bottom line: I see no gain for me as a developer, and a loss of
> consistency for users.
The only impact upon users is that the package manager will be more
likely to give them accurate outp
On Sun, 17 May 2009 00:42:58 +0530
Arun Raghavan wrote:
> On Sat, 2009-05-16 at 18:55 +0100, Ciaran McCreesh wrote:
> [...]
> > You have yet to provide an alternative for fixing the arbitrary and
> > pointless version format restrictions that are currently in place.
>
>
bjections *had* been included and discussed in the GLEP, and claims
that including such material made the GLEP less clear.
This is another of those issues where whichever way it's done, some
people complain.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
le are claiming GLEP 55 is bad because invisible
green cows are eating the moon.
> So, what do you think about my proposition ?
It's pretty clear that objections and voting aren't even being based
upon what the GLEP says these days, so I don't see any point.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
has to
be sourced to get EAPI. And you can't just say "use the metadata
cache", since the package manager has to know how to generate the
metadata cache in the first place.
Please make sure you're familiar with the basics of how metadata works
before commenting any further.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ill not.
This has already been covered at length, and is explained in the GLEP.
Why did you disregard this when posting your 'proof'?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ec is crafted
> such that the EAPI must be checked FIRST
...then the package manager has to inspect the metadata for every
version of a package before it can do anything, rather than just
starting at the best version and working downwards until it finds
something usable, which is a pretty hef
e basics of how metadata
> > works before commenting any further.
> >
> What has my understanding or lack of understanding of "metadata" have
> to do with my statement that other means exist to determine the EAPI
> of an ebuild before sourcing said ebuild? This
the EAPI mechanism is changed.
Second, by order of the Council, EAPI 3's feature list was locked
several weeks ago. If we ignore that for one thing, it just means
everyone else who had features that came along too late will start
demanding we reconsider those too...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
es that came along too late will start
> > demanding we reconsider those too...
>
> IMHO addition of this feature would be acceptable.
You could say that about any feature, but the Council chose to just go
with an absolute cutoff.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
27;s not obvious which one the
package manager should select.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ty
to allow versions like 1.2.3-rc1.
> As a consequence, the algorithm for picking best version of a package
> can be as simple as the following:
> 1- among all ebuilds filenames, filter out the ones with unrecognized
> version string
You don't know whether you recognise the version string until you know
the EAPI, though.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
change, so
you've got no excuse for posting such nonsense.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
, rcs, scm or something else. In the interests of getting
anything decided, Seemant made an executive decision and picked 'scm'.
History suggests that if it goes up for debate again, no decision will
ever be reached. Thus, the only sensible thing to do is to let the old
decision stand.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sun, 17 May 2009 21:57:40 +0200
Thomas de Grenier de Latour wrote:
> On 2009/05/17, Ciaran McCreesh wrote:
> > You don't define it quite like that. You define it by mapping EAPI X
> > _p onto super-EAPI _p0, and EAPI Y _p onto super_EAPI _pINFINITY.
> > That way t
3's approval is based upon implementation in Portage, not
implementation in every other package manager.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
sible version formats like
> 1-rc1, 1-alpha etc. to match upstream more closely."
> Apart from GLEP54, I believe our versioning scheme works reasonably
> well. I don't see any need to match upstream more closely. I'd rather
> like to keep the more uniform way of han
se we say so. We have chosen to do it a certain way. This works.
> It's uniform, it's simple, and therefor has a certain beauty to it. I
> see no pressing reason why we should start allowing alternative forms.
It's an utterly arbitrary restriction. Upstreams don't standardise
either way on - vs _, so there's no reason Gentoo should.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
gt; We have to draw the borderline somewhere, and I think our current
> rules are a reasonable compromise.
Forbidding -rc is not a reasonable compromise...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 18 May 2009 01:11:45 +0200
Ulrich Mueller wrote:
> >>>>> On Sun, 17 May 2009, Ciaran McCreesh wrote:
> >> 1_14 -> 1.14(app-emacs/limit)
> >> 12B5 -> 12.2.5 (dev-lang/erlang)
>
> > These we should handle
On Mon, 18 May 2009 01:30:26 +0200
Ulrich Mueller wrote:
> >>>>> On Mon, 18 May 2009, Ciaran McCreesh wrote:
> >> How? Both "limit-1_14" and "erlang-12B5" are valid package names,
> >> so how do you determine where PN ends and where PV s
es... There's no ambiguity so long as the definition is
sound.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 18 May 2009 06:59:36 +0200
Ulrich Mueller wrote:
> AFAICS, there _is_ an ambiguity.
There's no ambiguity. It means what we define it to mean.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ied upon strong blockers, hence the quickly-hacked-in !! blocker
hack) without EAPI control.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 18 May 2009 17:47:52 +0300
Petteri Räty wrote:
> Ciaran McCreesh wrote:
> > On Mon, 18 May 2009 13:04:27 +0300
> > Alex Alexander wrote:
> >> Unfortunately we've got reports from paludis users stating that
> >> they can't update QT from qting-e
inally lets us kill that off has to be good...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 18 May 2009 17:28:00 +0200
Jeroen Roovers wrote:
> On Mon, 18 May 2009 16:16:46 +0100
> Ciaran McCreesh wrote:
> > Why do you think I wrote the awful hack that is versionator?
>
> Why don't you explain why, historically, you put that in the tree? It
> would
rovided
solution combined with a reduced need for MY_PV hacks would give.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
qt-core" when a new Qt
> version becomes available?
It wouldn't, although it would be fixed as soon as someone tried to
install a package with a Qt dep.
Dependencies the way they are now aren't really expressive enough to
handle what you're after -- split packages are c
by
similar issues, so we can work out what exactly it is we'd be looking
to fix.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ecause of abuse of that feature. Had blocks
kept their original meaning, people would not have abused them to the
same extent.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
as before Zac
went and broke blockers in Portage. Such a way would:
* work by explaining the reason for the blocker, rather than sort-of
stating the expected resolution.
* provide mechanisms for explaining the block in detail to the user,
along with instructions on how to resolve it.
* be based around tree requirements, not some side effects of some code
someone happened to write without considering the implications.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
and did his
thing, and the overwhelming view was that a solution based around the
things I've been discussing was what was wanted.
> As you seem to understand the problem domain I'd expect a coherent
> unambiguous proposal instead of vague accusations and emotional terms
> that do not help in any way to improve the situation.
See the discussions we had back when the only kind of blocker was a
hard, single ! block.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ouncil agreed to step in
when Portage did that kind of thing. In fact, the blocker changes were
one of the things that lead to the Council saying "in future, we'll
package.mask Portage if it does that kind of behaviour change again".
> > and the overwhelming view
>
> a minority view, but let's not get distracted by such subjective
> matters.
Please point me to people involved in the discussion who did not agree
with the views presented. Provide a list of message IDs to support your
claim.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
an up to date cache.
The Gentoo rsync mirrors do not always ship up to date cache,
particularly if someone's just changed a widely used eclass.
Newer bash is not something that can be done as an EAPI change with
current mechanisms.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ould result in mass user confusion. The whole 'EAPI' thing
wasn't an arbitrary whim.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
es, so this one's
probably not very straight-forward... It supports overlays, which means
only one thing is ultimately visible for a c/p-v.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sun, 24 May 2009 22:50:45 +0530
Nirbheek Chauhan wrote:
> Won't this just lead to dependency hell? With horrible dependencies
> between different overlays?
It's primarily a user feature. It's not a good way of solving most
inter-repository dependency issues.
that everyone has to
comply with PMS or get p.masked, and that we'll do new EAPIs whenever
there are features available, and that they considered the EAPI 3
feature list to be appropriate, I doubt you'll get very far.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
hould be required, I
> think you have a misunderstanding of the user-base.
You still haven't read GLEP 55?
> Some of us prefer to know that a human has both tried the ebuild out,
> and gone through repoman. And that that person takes pride in their
> name on the commit, and st
al problem. Stop pretending that it
isn't.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 26 May 2009 10:13:51 +0200 (CEST)
lx...@sabayonlinux.org wrote:
> So, "::" vs "@" apart, is it something that is worth looking and
> implementing in future EAPIs?
Isn't it just a user issue, not one we want used anywhere where EAPI
rules are in effect?
--
oposed implementaion is bad
> practice, so GLEP 55 should be rejected in its present form.
You have not made a single technical argument in your entire message.
Please don't add yet more noise to the discussion.
- --
Ciaran McCreesh
-BEGIN PGP SIGNATURE---
as not made any quantitive technical arguments
> for it being the best solution. There is already plenty of posts on
> this list suggesting it isn't.
The only solutions that have been proposed that solve the entire
problem are the extension ones
it has already been stated:
> "Adding metadata to the filename is not required and is bad system
> design practice"
Stating something doesn't make it true. You could just as easily argue
that having PV in the filename is bad.
> Now if there is an actual technical reason, a reason that isn't
> present in GLEP55, then it is further proof that GLEPP55 is not
> suitable for the task and needs to be rejected in its present form
The reason is that there is no equally good alternative.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Thu, 28 May 2009 01:48:34 +0200
Jeroen Roovers wrote:
> On Thu, 28 May 2009 00:45:18 +0100
> Ciaran McCreesh wrote:
> > On Wed, 27 May 2009 23:26:25 + (UTC)
> > Mark Bateman wrote:
> > > NOT once within GLEP55 [...]
>
> > Not once has there been
API from the ebuild
> are the best and remain unchanged. Thats unlikely, as not a lot of
> work has been done it yet.
It is the best. If we're requiring EAPI before trying to parse PV, all
the EAPIs have to be known to do any ordering.
- --
Ciar
tements?
Please go back to your "nothing subjective" comment.
> > > Now if there is an actual technical reason, a reason that isn't
> > > present in GLEP55, then it is further proof that GLEPP55 is not
> > > suitable for the task and needs to be rejected in its present form
> >
> > The reason is that there is no equally good alternative.
>
> The reason is that GLEP55 is no reasonable alternative to the rest.
We've already established that a fix is necessary. Now we're just
discussing which fix is best, and GLEP 55 conclusively provides the
answer.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
; possibility that other people may have opinions that do not agree
> with you).
The only issue of opinion is whether or not .ebuild-X and .eapi-X.eb
look pretty. The rest is purely technical and entirely objective.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
remove the ability to change how versions are
handled. This is not a subjective matter.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
t; > The only issue of opinion is whether or not .ebuild-X and .eapi-X.eb
> > look pretty. The rest is purely technical and entirely objective.
>
> I think I have pointed you a few times at objective statements
> disagreeing with your subjective opinion. I hate repeating myself.
And yet you keep ignoring the part where GLEP 55 demonstrates
objectively that the extension solution is better than the alternatives.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Thu, 28 May 2009 12:42:02 -0700
Josh Saddler wrote:
> GLEP55 has not effectively shown that there *is* a problem, otherwise
> we wouldn't have had months of discussion on that topic.
Uh. Did you miss the part where we need global scope changes in ebuilds?
--
Ciaran McCreesh
si
llowed.
No-one is suggesting making changes to match silly upstream versions.
What we are suggesting is making changes to match sensible and
reasonable upstream versions.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
s not a question of benchmarks. It's a question of being slower by
design. Allow me to explain:
If GLEP 55 were to include benchmarks, they would be dismissed as "well
we can make that code faster", which would be missing the point -- that
it's a design penalty regardless of
> because after a long time you suddenly accept reason :)
No, we don't allow 1.1-rc1, which is a sensible and reasonable upstream
version.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
implemented in
> portage 2.2 (masked).
The main show-stopper for this last time it came up was all those X
packages using their package name as a licence. Have you thought of how
to get that glaring QA issue addressed?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
best long term solution. Perhaps you could ask
the Council to see if they could nominate it as a special priority
project and encourage every developer to fix one package.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
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
signature.asc
Description: PGP signature
maintainer groups. Each
> packager manager can have a rep speak on their behalf and we can plow
> through this topic fairly quickly.
Paludis has been ready to go whenever for a few weeks now.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ound doing their own
thing in different places. What we do need is for a single
waterflow-like workflow with a good way of coordinating it that doesn't
rely upon the PMS team chasing everyone up and trying to keep track of
everything.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
I'd rather not see Portage go stable with an EAPI before that
EAPI's been tested in the main tree for packages that are used by a
half decent number of ~arch users.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
.
Just do your own unpack if you can't handle it.
Also, is that really the best way of generating SRC_URI? Can't you
remove the need to put anything in ebuilds?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ing the overlays listed in layman?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
vent one malicious person from
running arbitrary code on the system of anyone using any layman overlay?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
nd it
> usually works ...
There's a big difference between the levels of verification done for
developers and that which is done for overlay maintainers. Currently,
any overlay maintainer can root any box on which their overlay is used
(whether or not anything from that overlay is installed)
ly lengthy discussion, so
I'd rather not prejudice you with my preconceptions. If you're not
prepared to spend time discussing this, you'll definitely end up with
something that's either highly limited in scope or that opens up a
whole new avenue of abuse.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
desirable. But can you give a concrete example
> where such a thing happened?
Yup. Some of leio's huge drawn out objections to EAPI 3 that wasted
huge amounts of my time were based upon him only having read the short
name we chose for things.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
1001 - 1100 of 3510 matches
Mail list logo
