that a Council
member cannot appoint a non-developer as their proxy. I see no mention
of either in GLEP 39, which only restricts voting of Council members to
developers, and only restricts proxies to not having one person with
multiple votes.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
the electorate can
vote in whoever they want, and council members can appoint whoever they
want so long as no-one has multiple votes at any given meaning. GLEP 39
is very clear and explicit about all the restrictions.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
and nothing to do with the attempts of a small number
of malcontents that anything involving me, Paludis or Exherbo is so
amazingly evil that it must be entirely ignored.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
to ensure that those contributions get
applied.
Again, this is not about me or Exherbo. It's about the Council's
unsubstantiated claim that the rules prohibit a Council member from
selecting a non-developer as a proxy.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
the "approved draft, to be accepted once Portage support is there" will
get 'in-eapi-4' instead.
Hopefully this'll make it easier to make sure we all know what's going
on, and harder for simple things to get missed because no-one remembers
them at the time.
[1]:
http://archives.gentoo.org/gentoo-pms/msg_927530a070199c51f553df8360337de2.xml
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 1 Jul 2009 15:45:29 +0300
Theo Chatzimichos wrote:
> Display-If-Installed: kde-base/kdelibs
Really? Anyone who has any version of kdelibs ever?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 1 Jul 2009 17:00:35 +0300
Theo Chatzimichos wrote:
> On Wednesday 01 July 2009 16:25:11 Ciaran McCreesh wrote:
> > On Wed, 1 Jul 2009 15:45:29 +0300
> >
> > Theo Chatzimichos wrote:
> > > Display-If-Installed: kde-base/kdelibs
> >
> > Really?
an't, why do they feel that and why haven't they said so?
Really, the only big issues we've had with EAPI work are getting Portage
support and working around a Council that wants to both micro-manage
every last detail of every last feature and only put in an hour of work
every two weeks
es, objections and alternatives
that were either already addressed, not at all relevant or obviously
unworkable. That's what dragged the process out for so long.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ting on bugs in competing managers
I've given up looking at pkgcore's code or trying to test it. The only
bugs I'm aware of in pkgcore are those that've been reported by other
people.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ation...
Are you sure that the way you're suggesting is the most elegant way of
doing things? The alternative proposal was:
IUSE="foo bar linguas: en fr"
which, admittedly, requires adding ( ) support to IUSE, but that's also
required by some of the other IUSE-related propo
" rather than a "we'll
definitely be using this". Flags that I'm aware of that regularly get
abused are:
IUSE_IMPLICIT="build debug"
Are people wanting to make those implicit? Are there any other flags
that people really don't want to put in IUSE? Bear in mind that any
flag that's implicit can't ever be used for a use dependency default.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
seen as ciaranm's domain, and
> we all know he doesn't set a collaborative tone, but rather one of
> conflict, which anyone on a clock can't be bothered with.
Please point to examples of conflict on the PMS mailing list. Also, I
shall remind you that the PMS list was a Council decision and that it
was primarily to replace the alias we were using for sending patches
for review -- that's still what it's being used for.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
or "Paludis to fail", and that
"opposing [me] and everything [I] do was an initiative [you] started
only after careful consideration", I'll kindly ask you to stop randomly
jumping out and flinging turds, since it adds nothing to the discussion
at hand and only serves to
On Tue, 7 Jul 2009 10:09:09 -0600
Denis Dupeyron wrote:
> On Tue, Jul 7, 2009 at 7:45 AM, Ciaran
> McCreesh wrote:
> > Perhaps you should consider that it's your behaviour that's the
> > issue here.
>
> It's both your behaviors, because they're extre
On Tue, 07 Jul 2009 18:34:32 +0200
Rémi Cardona wrote:
> Le 07/07/2009 18:20, Ciaran McCreesh a écrit :
> > I would be entirely happy if you could get the people whose stated
> > aim is to disrupt PMS and / or third party package managers to stop
> > poisoning the atmospher
iscussion, then you should ignore
the previous Council's decision and reconsider all the solutions that
have been presented.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
whitespace, quoting and indenting rules for
something that otherwise looks exactly like any other metadata variable
isn't going to cause problems?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
uilds already have to conform to a vast number of
> constraints that ordinary bash scripts do not. I think that it's
> perfectly reasonable for ebuilds to have a constrained syntax for
> EAPI assignments.
...and only EAPI assignments? Not for any other metadata variable?
Doesn'
On Thu, 08 Mar 2012 11:59:33 -0500
Alexandre Rostovtsev wrote:
> On Thu, 2012-03-08 at 16:29 +0000, Ciaran McCreesh wrote:
> > And you believe that having exactly one place inside ebuild text
> > where there are different whitespace, quoting and indenting rules
> > for som
e thing, is weird.
Having something break because you make full use of bash syntax, where
nothing else breaks if you do the same thing, is weird.
There are already a whole pile of subtle traps for ebuild writers and
complications for people learning the system. We should be aiming to
reduce
On Thu, 8 Mar 2012 18:30:47 +0100
Jeroen Roovers wrote:
> On Thu, 8 Mar 2012 17:14:58 +
> Ciaran McCreesh wrote:
> > Having a different, special rule for something that looks exactly
> > like lots of other things that do not have that different, special
> > rule
;s better to think of ebuilds as being
data. If you did have a /usr/bin/eapi5, it would have to be implemented
as something that invoked the package manager, not as a direct
interpreter.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
for EAPI 4. Same idea and impact as GLEP 55, except without as
much future proofing.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ou aren't executing ebuilds via an
interpreter. You're performing an action that involves using the data
and code in an ebuild multiple times and in multiple different ways,
and that may also involve doing the same to an installed package that
is being replaced.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
iolations of the HOMEPAGE rule
tell you a lot about what happens when something is made syntactically
valid but supposedly not legal.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ore having
to spawn a bash process isn't just about performance, it's also about
making ebuilds much less difficult to deal with.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ng a stable Portage version that
handles it around.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
does just that.
>
> [[ -z "${HOMEPAGE}" ]] && \
> HOMEPAGE="http://search.cpan.org/dist/${MY_PN:-${PN}}/";
>
> Not really comparable in entirety to EAPI.
The point is that there's a silly QA policy saying not to do that. It's
not a PMS rule.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
longer.
We have to support them indefinitely. It's not possible to uninstall a
package whose EAPI is unknown.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sun, 11 Mar 2012 16:14:33 +0100
Chí-Thanh Christopher Nguyễn wrote:
> Ciaran McCreesh schrieb:
> >> Is there really much of a benefit to this? I guess for anybody who
> >> runs scripts to mass-manipulate ebuilds it might be helpful, but I
> >> think all t
d from a package
manager. It might be worth revisiting this if we ever switch to EAPIs
that allow us to kill off VDB, for example.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
that really really needs to die...
Being able to replace VDB with something that doesn't suck is one of
the places where being able to kill off old code would actually matter.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
l of this is that we shouldn't have to guess
what future EAPIs will look like.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 12 Mar 2012 01:36:12 -0700
Brian Harring wrote:
> Also note that with the sole exception of g55
...
> and does so at the same robustness as everything sans g55
...
> G55 is the sole exception.
Interesting pattern, huh?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
lking about here? It's not the case that
ebuilds will always be bash 3, which is enough to make GLEP 55 the safe
option.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 12 Mar 2012 09:05:26 -0700
Zac Medico wrote:
> It's just a symptom of people not abiding by the KISS principle.
"Abiding by the KISS principle" is what got us into this mess in the
first place. EAPI as a metadata variable is too simple to allow us to
do what we want
o something unexpected.
This whole thing is just an exercise in trying to find excuses not to
use GLEP 55.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
wrote it is one of Satan's little minions. Also, change
is bad.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
x27;re down to "it's ugly and someone already said no and I'll
throw my toys out of the pram if I don't get my way" as the arguments
against GLEP 55 now?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ne is conveniently ignoring), it doesn't
require us to guess what's going to happen next and it can be
implemented immediately. That's a rather big deal.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 12 Mar 2012 19:50:36 +0100
Ulrich Mueller wrote:
> >>>>> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:
> > GLEP 55 is simple, it solves all the problems we have (including the
> > version issue, which everyone is conveniently ignoring), it doesn't
>
al versions (and it's illegal to do this), so it's
not relevant to the discussion.
- --
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk9eSAwACgkQ96zL6DUtXhGpEwCfWS9u6S4oqNebnRrofwqWKFAy
tGMAoNX/2T7dyBqW+sSVO+O5nSMp5NKm
=Y5Tt
-END PGP SIGNATURE-
if your package mangler is carefully
designed to avoid doing unnecessary I/O. It's just not the primary
point. The primary point is that it handles whatever we feel like doing
in the future, even the "conveniently ignoring" stuff that you're
conveniently ignoring.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
aw in our versioning system, and it can only occur
> in some corner cases where version components have leading zeros.
You know, if we had GLEP 55, we could fix that. Although it's debatable
whether it's a flaw, since we're trying to match upstream version
formats where
On Tue, 13 Mar 2012 02:41:13 -0400
"Walter Dnes" wrote:
> On Mon, Mar 12, 2012 at 05:12:28PM +, Ciaran McCreesh wrote
> > This whole thing is just an exercise in trying to find excuses not
> > to use GLEP 55.
>
> A filename should not be (ab)used as a databa
s, since they're clearly symptoms
of a larger "oops, we have too much coupling" problem, instead of
forcing a workaround onto large numbers of users?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
t something that should be done lightly.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
even less well handled than "stuff not in /usr" is just now. All using
an initramfs does is move the dependencies problem from somewhere where
we have a solution that used to work and that still mostly works to
somewhere where we don't have anything at all.
--
Ciaran McCreesh
s
RES?
If you want that, USE_EXPAND_IGNORE_CHANGES, like USE_EXPAND_HIDDEN,
would be cleaner. 'test' is already too special.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
that would be generated at any
given point in the build sequence.
So you can't rely upon IUSE having the "merged" value in an eclass.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
IUSE environment variable inside the ebuild.
> I think 'any point in the build sequence' is still
> post-eclass-inheritance isn't it?
Nope. It's also at any point during the sourcing of any of the files.
- --
Ciaran McCreesh
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 23 Mar 2012 12:32:05 -0400
Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 23/03/12 12:19 PM, Ciaran McCreesh wrote:
> > On Fri, 23 Mar 2012 12:14:39 -0400 Ian Stakenvicius
> > wro
ion when the function was introduced, and we were
assured that it "would only be used correctly"... The correct solution
is probably to have ebuilds define a variable like "OASIS_WANT_DOCS",
and to use that.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ing, make it easy to do the right thing.
Unfortunately, bash really doesn't make it easy for us to do that sort
of thing...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
matic installation of the appropriate
firmware) no longer supports /usr/portage on its own partition. But
that's ok, because extensive studies have shown that the only possible
reasons for putting /usr/portage on its own partition are historical,
since everyone has an SSD now.
--
Ciara
ge is bad at overlays
but the Summer of Code projects to fix it will solve all of that this
time around, honest.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
nix.
Do you really want to be advertising an awful hack that doesn't really
work, is conceptually unsound and that breaks all kinds of things in
subtle ways?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
't think of what other problems there are so it's fine". That's a
bad way of doing things.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
xample. So I think you're misunderstanding what constitutes
proof here -- "some evidence" certainly isn't it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
tc, take your pick.
No, what I actually say is *why* things don't work, and if it hasn't
already been explained, I say how to fix it. But the first step towards
getting something fixed is admitting that there's a problem, and you've
always been awfully reluctant to do that until the damage has already
been done.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ering "when it breaks, reinstall"
territory here.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ks,
> > reinstall" territory here.
> >
> Which is still more than 0%.
>
> I demand better trolls, this is getting boring.
So you think Gentoo should advertise as "the chances of it working are
greater than 0%"?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
automatically
imply that doing it is a good idea.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sat, 31 Mar 2012 18:39:21 +0300
Alex Alexander wrote:
> On Mar 31, 2012 5:57 PM, "Ciaran McCreesh"
> wrote:
> > On Sat, 31 Mar 2012 15:08:29 +0300
> > Alex Alexander wrote:
> > > No. I didn't say I think it works, I said I have proof it works.
>
On Sun, 01 Apr 2012 17:04:11 +0100
Steven J Long wrote:
> Ciaran McCreesh wrote:
> > No, what I actually say is *why* things don't work, and if it hasn't
> > already been explained, I say how to fix it.
> Oh? Where on Earth did you do that in this thread? All you'
, but most do not.
You're trying awfully hard to turn this from a discussion about a
feature into a discussion about people. Please don't try to confuse the
two -- attacking the messenger just prolongs getting a fix implemented.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
that will be available for the
build, but check-reqs is deliberately designed to be wildly inaccurate.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ow, as if it were designed under the
assumption that accuracy wouldn't be possible...
Or you could just post more noise to the list in an attempt to stir up
trouble. Your call.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
rk (bear in mind that some of the target
filesystems might not support caps).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
with this, the easiest
way would probably be to require that overridden src_prepare functions
call a magic function called "apply_user_patches_here" (and to barf if
a src_prepare finished without having called that function).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
package mangler could even make it fatal (at
pretend time, no less) if someone wants to apply user patches to an
ebuild whose EAPI doesn't support it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
o package.use.mask and package.use.force,
> except that the resulting rules are ONLY applied iff a stable keyword
> is in use
This means that an ebuild will effectively change when moved from ~arch
to arch. The point of ~arch is to test ebuilds before they're moved to
arch.
--
Ciaran McCreesh
if the user has patches
specified for a package that isn't EAPI 5.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ert that src_prepare contains an epatch_user call
> if EAPI is less than 5.
Why bother? That's hideously error prone. We have a simple way that's
guaranteed to work, and that is able to inform the user if their
expectations can't be met.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
r people who want strictness and can afford to wait for the
> relevant ebuilds to be converted to EAPI 5.
But there's no way the repoman check is going to give anything like
reliable answers if you're involving eclasses...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
roach. Meanwhile, it's relatively easy to to a manual audit of the
> src_prepare function of each eclass.
Providing unreliable functionality just leads to whining and
contortions when it doesn't work. This isn't a situation where
compromise is necessary, so there's no reason
ough to
> justify that.
Didn't we have a few other cheap things lined up?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
* EAPI parsing
* the things that were left out of 4:
+ slot operator deps
+ profile IUSE
* No -j1 for src_test
* Remove deprecated stuff
* Zero or one REQUIRED_USE operator
These might be cheap now?
* New bash version
* Get a versionator replacement into the PM
--
Ciaran McCrees
On Sat, 28 Apr 2012 10:52:07 +0200
Michał Górny wrote:
> On Fri, 27 Apr 2012 21:12:27 +0100
> Ciaran McCreesh wrote:
> > * Get a versionator replacement into the PM
>
> Why are we trying to make PM a brick instead of keeping stuff modular?
> What does the eclass lack which
On Sat, 28 Apr 2012 10:09:01 +
Francesco Riosa wrote:
> What's changed from 2006 in version handling?
The ordering rules, the handling of zeroes and the behaviour of
suffixes.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 4 May 2012 18:02:05 -0700
Greg KH wrote:
> And what are you going to do when dbus moves into the kernel itself
> (hint, it will be there soon)?
Why stop at dbus? Why isn't libxml2 in the kernel yet?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
who use packages
that have an emboss use flag, are those people likely to want emboss?".
--
Ciaran McCreesh
signature.asc
Description: PGP signature
worse the more clever tricks people come up
with to get around its inexpressivity.
I propose:
REQUIRED_USE="== ( qt webkit )"
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 7 May 2012 20:26:08 +0200
Ulrich Mueller wrote:
> REQUIRED_USE="^^ ( webkit !qt )"
Please provide an algorithm that will turn that into an appropriate
error message for displaying to a user.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
to make the
> expression easier to read.
Forget "easier to read". The important part is being able to produce
error messages for users.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
under discussion here is that tight coupling and vertical
integration means we are in effect forced to use rather a lot of
software that we would prefer not to.
- --
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEAREC
ou are forced to use anything. As was proven
> before, there are always alternatives.
That's a somewhat disingenuous claim when the alternatives are moving
steadily towards "don't use Linux at all" or "use the full GnomeOS
stack".
--
Ciaran McCreesh
signature.asc
Description: PGP signature
LICENSE from the ebuild (as long no former eclass sets
> its own LICENSE).
That's definitely not going to work if the 'inherit' comes at the top
of the ebuild, and is severely dodgy if it doesn't...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
B drive reports 0.
>
> And I'm sure it works fine with udev?
I dunno. Internet Explorer broke and now udev won't run.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
: the (public) superclasses of a class are part of
its API.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
That's wrong. SVN branches are just about as cheap as git branches,
[citation needed]
--
Ciaran McCreesh
signature.asc
Description: PGP signature
you don't merge things quickly. Encouraging
users to submit git format-patches or merge requests is a great way of
reducing developer workload.
- --
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAk++eQMACgkQ96zL6DUtXhF4kgCfZkdR7RTvUUlFdTgdNkyDHwGK
NlgAoKgSUKEWN6WnrihawHkhhrPbJlv2
=8RdD
-END PGP SIGNATURE-
We'll be able to turn that on in a controlled way in EAPI 6. Having
said that, if we're reaching the point where speed of bash code is
at all relevant, then ebuilds are doing something wrong...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
se their work on current master before
> they commit to master which would make the history clean.
So what's the point of switching to git if you want to ban the main
reason git exists?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 04 Jun 2012 22:52:25 +0200
"Andreas K. Huettel" wrote:
> No. What is signed is the "new data" plus the parent hash(es).
>
> No such thing as a "tree hash".
http://eagain.net/articles/git-for-computer-scientists/
Might clear things up a bi
troduced, it was supposed to be only for *important* messages,
but nearly everything sent to it now is a waste of users' time.
Perhaps the solution is to implement an ethisisimportanthonestlog
function, and require developers to get approval before using it, as
per news items.
- --
Ciar
lve with that. SLOT
operator dependencies are known to work for the problem, and have
received extensive testing both on Gentoo (with the old KDE packages)
and elsewhere. Why not just go with those plus blockers initially, and
then add in ABI_SLOT only if it turns out that developers really can&
know what the problem was.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
istent with this rebuilds forcing, but no idea what
> to do with system packages still needing to use eapi0 and maybe
> changing their ABI too :/
The situation for older packages remains the same.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
1101 - 1200 of 3510 matches
Mail list logo
