ng lots of things of the form:
src_unpack() {
default
patch blah
eautoreconf
}
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, Aug 19, 2008 at 12:12 PM, Steve Long
<[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
>> If you're doing new phases... Exheres has been using src_prepare, after
>> src_unpack, to avoid having lots of things of the form:
>>
>> src_unpac
On Tue, 19 Aug 2008 23:31:17 +0530
Arun Raghavan <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > The benefit is that it's a logically separate action, and will avoid
> > all the silliness of people repeatedly changing their minds about
> > which phase should
On Tue, 19 Aug 2008 21:27:03 +0100
Steve Long <[EMAIL PROTECTED]> wrote:
> > On Tue, 19 Aug 2008 23:31:17 +0530
> > Arun Raghavan <[EMAIL PROTECTED]> wrote:
> >> Ciaran McCreesh wrote:
> >> > The benefit is that it's a logically separate action,
the function what you like (or add a new phase with the hooks)
> it's still logically one point in time. For a live ebuild it's to
> prepare the src, for a normal one to (possibly) unpack and prepare.
Uhm. I think you're completely misunderstanding src_prepare. Go bac
like any other
> ebuild, including execution of all of the normal ebuild phase
> functions that would be executed for any other ebuild that does not
> exhibit the "virtual" property.
So are all zero-install-cost metapackages virtuals now? What about, for
instance, kde-base/kde?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 25 Aug 2008 12:06:35 -0700
Zac Medico <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > So are all zero-install-cost metapackages virtuals now? What about,
> > for instance, kde-base/kde?
>
> Looking at the dependencies of kde-base/kde, it seems lik
believe it is,
> and find it every bit as clear and actually much less confusing than
> zero-install-cost.
So what does 'virtual' actually mean then, and how is it related to the
defined behaviour of this property?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
e appropriate, and as you
> say, 'virtual' is less confusing for a user than 'zero-install-cost',
> especially within Gentoo.
Users don't need to see it. Heck, most developers don't need to see it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
least[2], makes it easier for
> the PM user-base to work with.
virtual is a well-understood term that does not mean what the property
being discussed will mean.
> It's a cultural "people understand this already" point as opposed to a
> technical make-it-as-ex
rol ordering).
Er, no you can't. There is no way of using existing version components
to get the correct ordering.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ls
The property proposed corresponds to only the last of these.
> An analogy to "virtual" is a virtual method in OO programming - it
> sits at a high level, does nothing in itself, but causes underlying
> methods to perform the work.
Virtual methods in OO can do lots. You're thinking 'pure virtual' or
'abstract'.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ultislot which will workaround
> the problem with "invariancy of the SLOT"?
Uh, how would that work?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
r you have to introduce even more variables to cover
> more cases.
The proposal is not designed to replace all cases. It's designed to
replace the common 50%.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
s
> thread. The reduction in lines of code/characters seems to introduce
> an uglier syntax which is harder to read with questionable benefits.
Try using it for a few weeks. Once you're used to it it's considerably
nicer than going through and implementing pointless src_configures
to cache results, sourcing package with all
> different USE flags combinations during cache generation.
a) PROPERTIES can't be used to implement any mandatory feature, and b)
multiply half a second to however many packages there are using this
feature and add that to the resolution time. The metadata cache is
necessary.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
oo might not
possess it -- for example, vim plugins generally do a vim tag
regeneration upon pkg_postinst, so they're not 'quick' to install even
if all they do is provide one text file.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ectly and handle
error cases properly?
The DEFAULT_* variables make it *easier* to write packages because half
the time you don't need to arse around writing src_* functions. Every
src_* function written by someone is another place there can be a
non-obvious screwup.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
uilds to
> crib from any more.
Sure they will. There'll still be a significant number of ebuilds that
fall somwwhere between "easy enough to handle with the defaults" and
"horrid complex mess".
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 9 Sep 2008 00:58:52 + (UTC)
Duncan <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh <[EMAIL PROTECTED]> posted
> [EMAIL PROTECTED], excerpted below, on Tue, 09 Sep
> 2008 00:38:48 +0100:
> > People shouldn't be writing ebuilds to do that at all. They shoul
any objections to this proposal?
>
> I won't approve it for use in the tree before it's written as a GLEP
> in order to avoid the fiasco with EAPI 1 (it's still not documented
> properly). I can however approve the list of items.
What about the PMS EAPI 1 docum
solution, but this
probably isn't an EAPI 2 timeframe feature.
In addition, having nonfatal versions of commands is also useful in
practice. Exheres has a 'nonfatal' command, so you can do 'nonfatal
dodoc foo bar baz'. This also needs discussing before deciding upon a
spec.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
away later "the
parser must also do bar and baz for EAPI 1".
> Perhaps I'll try sending you a patch with something like that, if I
> have time, and if it would be appreciated.
We've discussed having a purely informative appendix with a summary of
changes between EA
devmanual.
If you want the new pkg_* ordering to go through at all, it really
needs a lengthy discussion on its own and it mustn't apply to any
action that involves any existing EAPI.
I'd like the Council to say that for anything involving EAPIs 0, 1 or 2
we stick to the pkg_* phase orde
On Mon, 08 Sep 2008 23:34:28 +
"Jorge Manuel B. S. Vicetto" <[EMAIL PROTECTED]> wrote:
> So we're talking about adding the following to EAPI-2:
Are we treating PROPERTIES as purely optional and having no defined
values for EAPI 2 then?
--
Ciaran McCreesh
signat
ml, can the council
> members discuss this proposal and consider voting it?
> Does anyone have any objections to this proposal?
I've prepared patches for PMS for this lot. They can be found on the
branch 'eapi-2' at git://git.overlays.gentoo.org/proj/pms.git . Can we
use these
at the eapi-differences-summary branch on
git://git.overlays.gentoo.org/proj/pms.git . Is that roughly what
you're after?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
API process.
How much research did you do before sending your email? Did you read
"EAPI and PMS for people who haven't been paying attention"?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 12 Sep 2008 14:14:51 -0400
Jim Ramsay <[EMAIL PROTECTED]> wrote:
> Unrelated topic: What packages are actually required to 'make
> pms.pdf' so I can actually read it? I get:
Have a look at the dependencies for app-doc/pms.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
> course already does this for me quite nicely).
Allowing multiple slots per version would require significant VDB
changes. Unfortunately we're still stuck with using VDB as-is whilst
EAPIs 0, 1 or 2 hang around...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sun, 14 Sep 2008 23:51:11 +0300
Petteri Räty <[EMAIL PROTECTED]> wrote:
> Hopefully someone formats it to a real GLEP before that.
git clone git://git.overlays.gentoo.org/proj/pms.git
git diff origin/master..origin/eapi-2
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ed as implicit members
> > of IUSE and therefore they shouldn't be explicitly listed in in
> > IUSE.
>
> Yes, IMO mainly because they should never explicitly be set by users,
> so they shouldn't get a hint they can set it either.
That's covered by USE_EXPAN
mailing list so discussions & patches aren't lost
> on the pms-bugs alias [cardoe].
This is bug 237427. No response on it yet.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
#x27;t get
upgraded or reinstalled?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
for example. Any specified flags should
apply to the entire set. But what about set-property packages?
Sets and packages aren't the same thing, and shouldn't be treated as if
they are.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
t the same thing either, but glep 37
> virtuals fit quite well into the existing ebuild framework. It seems
> to me that set-property packages will also fit nicely into the
> existing ebuild framework.
GLEP 37 effectively abolishes virtuals. It doesn't try to overload new
behaviour onto packages.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
does this do in package.use?
cat/foo monkey
What does this do in package.mask?
cat/foo
What about this?
>=cat/foo-2
What about this?
=cat/foo-2
What about this?
emerge -uDpv \http://paludis.pioto.org/configuration/sets.html
--
Ciaran McCreesh
signature.asc
Description: PGP signature
> >
>
> Perhaps can use something like you've got there in addition to the
> PROPERTIES=set approach.
Why the need for multiple solutions at all? PROPERTIES=set is too weird
and involves too much nonsensical behaviour to be useful.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
switching EAPI is a fairly major change that could cause
unexpected breakages, but that's purely a QA issue.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
@RDEPEND(=foo/bar-1.23) . No need for any PROPERTIES or mapping
mess at all...
> Does this seem like a good approach? Are there any suggestions for
> improvements or alternative approaches?
This looks to me as if you're trying to find uses for PROPERTIES,
rather than trying to find ways to solve a problem.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
oo? Some things
in there are EAPI dependent... It'd have to stay at 0 for quite a long
time, of course.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
API<2?
Export it if and only if EAPI is 2.
Note that this means EAPI really really has to be set as the first
thing in the ebuild (*cough* or in the file extension).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
eapi would help too.
An EXPORT_FUNCTIONS ignoring incorrect usage makes one less place
checking for eclass screwups...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
culties with eclasses, it might be
worth doing an EAPI 3 quickly with just this addition...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
or trying to be too clever?
It's illegal, according to PMS. It also won't work with Paludis, since
phase function definitions aren't made available until just before that
phase executes (there is a reason for this -- it provides us with a way
of identifying whether a package has a particular phase or not).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sun, 5 Oct 2008 21:48:09 +0200
Ulrich Mueller <[EMAIL PROTECTED]> wrote:
> All our documentation (devmanual, ebuild howto, skel.ebuild, pms)
> recommends "econf || die".
I've fixed PMS.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
e case?
> Considering that they can already call 'die' in global scope I don't
> see it as being that urgent.
If we're considering global scope die to be a usable solution, we need
to start defining its behaviour and providing a way of tracking it in
metadata.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sun, 5 Oct 2008 03:44:20 -0700
"Robin H. Johnson" <[EMAIL PROTECTED]> wrote:
> Either we need special cases to declare that it no longer has a
> homepage, or we need to allow the empty HOMEPAGE.
HOMEPAGE="( )"
--
Ciaran McCreesh
signature.asc
Description: PGP signature
hat way is the best option.
Strange how you repeatedly seem to pop up in favour of doing whatever
you think will cause most inconvenience to Paludis, though...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
scope of the changes? I think it'd be easiest to discuss
this if you posted an informal summary describing the differences in
terms of which bits of PMS are affected.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ons would be encouraged... We
have to do *something*, though, because this is hitting users already
(see bug 240684 for one).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
t's too late to ask the Council to discuss the "EAPI 2 is
brokened :(" thread? What would be the earliest the Council would be
able to make a decision upon that? Unfortunately it's something that
could get messy if left for too long.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
that? Unfortunately it's
> > something that could get messy if left for too long.
>
> I think that you may be overreacting. The python-2.6 ebuild from bug
> 240684 is still hard masked in package.mask and I'm doing a
> sys-apps/portage-2.2_rc12 release to
On Thu, 09 Oct 2008 17:47:36 -0400
Doug Goldstein <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > Unfortunately Portage and Pkgcore have broken EAPI 2
> > implementations.
>
>
> Ciaran, I would think at this point you know this since you've seen
>
le bug reports in almost any form).
If you want bug reports via trac instead of IRC, get your trac to
respond faster.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
personal BS that bleeds into your posts.
I'm not the one going around levelling personal attacks at everyone.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
are?
> I can not understand why this is dragged on. It was a bug, it is
> fixed. The sky is not falling and EAPI-2 is not broken - there was a
> bug in the implementation that is fixed.
The point of EAPI is to avoid these kinds of problems. The process is
failing and the fallout needs to be handled.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
to be worked out, it'd fairly clearly be something that could just go
straight in to the next EAPI, with duplicated base system packages in
an overlay to avoid having to use new EAPIs for core things in the
main tree.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ss prefix is reimplemented to require no package manager
changes for the install to / case, PROPERTIES is out.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
fy and mandate existing behaviour here, so it's not really
something that should be left up to PMS to decide and enforce.
I mean, if the Council's comfortable with PMS being used to force
package manager changes for things that aren't obviously bugs, we could
do it without asking,
ime this comes up.
> custom-cflags 9
Shouldn't be there at all.
> multislot 6
Utterly illegal, needs to die.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
s anything to do with
performance, you are even more sadly mistaken than usual, and I
suggest you lay off the GLEP 55 bashing until you've bothered to read
it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
t; perhaps you're just feeling defensive about your trap boo-boo?
Those of us who have tried trap have fairly conclusive proof it won't
work. Perhaps you'd like to show how wrong we are and provide a working
demonstration.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 15 Oct 2008 20:53:14 +0100
Steve Long <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 15 Oct 2008 18:36:32 +0200
> > Markus Meier <[EMAIL PROTECTED]> wrote:
> >> server16
> >
> > Already been discussed
On Wed, 15 Oct 2008 14:47:06 -0700
"Robin H. Johnson" <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 15, 2008 at 05:43:38PM +0100, Ciaran McCreesh wrote:
> > Utterly illegal, needs to die.
>
> Why? I don't agree that it needs to be the global useflags, but I
>
roblem.
I'll explain it for you in much simpler terms: equipping a car with a
new kind of engine and fuel system that is much safer in the case of an
accident is a good thing, but not if it also reduces the car's top
speed to 30mph.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
e what it breaks, if you can.
Well, which part of the previous times it's been explained to you didn't
you understand?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
comes to distcc?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
reason why distcc with a sane compiler can't be used
with kernel modules. If this is the case, wouldn't it be better to get
the hardened compiler fixed?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
tcc for parallelisation bugs
that aren't distcc related but that happen to be easier to reproduce
when distcc is enabled. Do you have any examples of problems that are
definitely caused by distcc, rather than general parallelisation bugs
or user misconfigurations? RESTRICTing distcc doesn&#x
cc won't fix), a user
configuration issue (which RESTRICT=distcc won't fix) or a hardened
toolchain bug (for which RESTRICT=distcc is massive overkill, and thus
the wrong solution). You've decided upon a solution before you've
worked out what the problem is.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
estion in all this is why does a third party who
> has demonstrated his anti-Hardened (and anti-Gentoo) slant on
> multiple occasions define what goes in our PMS?
Uh, that's your answer to technical objections to a proposal? You
aren't prepared to defend your proposal on its merits?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
it's being disabled for everyone rather than by the
small number of users who might need it. In addition, you can't
demonstrate any cases where this option is genuinely useful, other than
as a workaround for a hardened bug that you haven't contacted upstream
about, and when used to work around said hardened bug the scope of the
change isn't limited to hardened.
You still haven't explained why you don't do something like:
broken_hardened_compiler && export DISTCC_HOSTS=localhost
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 05 Nov 2008 21:20:07 +0100
Thomas Sachau <[EMAIL PROTECTED]> wrote:
> Do you really think, a package that supports parallel make while
> compiling fails support for parallel make support on install?
Yup, that's fairly common.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ducing the kind of "us vs them" behaviour
that a few package maintainers like to engage in where arch teams are
treated as being in the way rather than there to help.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
be OK for some people to say "well, we
warned you, so tough luck", it makes life very difficult for developers
who end up having to deal with hordes of users with broken systems...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
> punted only when said library provides a good alternative (like
> > a .pc file with correct libs.private field).
>
> Perhaps writing a .la to .pc converter would be a worthwhile endeavor.
One of these things is not like the other.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
, enough fuss has been made about this that too many
people will look bad if it's decided to do nothing, so things have
reached the "find the least bad something to do" stage...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
sn't (and won't)
> work on an arch, that's really bad for me.
What is the cost of keeping it there and not changing it?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 26 Nov 2008 09:42:07 +0100
Peter Alfredsen <[EMAIL PROTECTED]> wrote:
> > This seems like a really strange strategy for checking whether a
> > certain item is in a list.
>
> I disagree.
You do? Why do you think it's better than 'has'?
--
Ciaran Mc
uot;definitely illegal":
if use foo ; then
src_configure() {
blah
}
fi
This is of course a good thing.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ll this really needs is per-package eclasses.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
rogram would
> take much less time to parse XML that an ebuild).
Search programs don't parse ebuilds. They parse the metadata cache,
which is an awful lot easier to parse than XML.
--
Ciaran McCreesh
show_homepage.rb
Description: application/ruby
signature.asc
Description: PGP signature
ope to hang themselves and every single user -- per package
eclasses don't alter this in any way.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
y single user -- per package
> > eclasses don't alter this in any way.
>
> Nope, I assume we are all humans and even careful people do mistakes.
> If package works do not to touch it.
We're talking for new packages, not for retroactively going and making
everything in the tree EAPI 3.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
> And the fact that you can ask the package manager for something is
> for me not a valid reason to avoi moving something in a more
> approchable place for other software.
"More approachable" is a decent package manager API. If you had that
you wouldn't need to mess around with XML APIs.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
entoo.org/gentoo-dev/msg_5ba467bbd5a0820e040210683702a67f.xml
* RFC: DEFINED_PHASES magic metadata variable
http://archives.gentoo.org/gentoo-dev/msg_8c34d8efbc0d31ab28c517403dc83f62.xml
--
Ciaran McCreesh
signature.asc
Description: PGP signature
y out potential enhancements
rapidly, a long track record of getting it right and the growing
recognition that most people doing package manager work for Gentoo
aren't doing it with Portage.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
lopers who don't use tools properly don't like it because it
stops them clipboarding it. The solution, of course, is to do it lots
so those people have to learn to do things the right way.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
dencies are this:
flag? ( whatever )
Use dependencies are this:
foo/bar[flag]
Much confusion arises if the distinction isn't made.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Thu, 27 Nov 2008 19:43:59 +
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> The DEFINED_PHASES variable will contain a space separated arbitrarily
> ordered list of phase names. A phase name is listed in DEFINED_PHASES
> if and only if the ebuild or an eclass used by that ebu
ked
eselect with a bit more functionality, particularly in the "make it
easier to write foo-config style alternativesish modules" area:
http://git.exherbo.org/?p=eclectic.git;a=summary
--
Ciaran McCreesh
signature.asc
Description: PGP signature
se of getting things done. Going through Gentoo requires finding a
Gentoo maintainer, endless bikeshed arguments about how to implement
things like the new alternatives framework and then months of waiting
for approval.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
t entirely in favour of open and
public debate. It's just that they don't exactly have a positive
experience of that happening within Gentoo...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 8 Dec 2008 20:28:58 +0200
nikos roussos <[EMAIL PROTECTED]> wrote:
> On Mon, 8 Dec 2008 17:44:34 +
> Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> > None of the people involved in the decision to fork eselect rather
> > than work on it for Gentoo are anyt
with the
> new EAPI stable for 60 more days so that the new EAPI related code in
> portage can be tested properly.
The "can be tested properly" phase is when it's in ~arch...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
extensive set
of unit tests, which can cover this with targetted accuracy with much
more reliability than making sure random ebuilds still work.
What you're suggesting here is making everyone wait four more months
for no increase in safety.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
e
> will be no objections I'll add new 'gzip-dict' global USE flag in 2-3
> days from now.
What's the point of having this as an option at all? Is it really
something that affects the end user in any way? Or is it just
gratuitous choisiosity?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
uncompresses) all of them at startup
anyway, what's the point in compressing them at all?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 19 Dec 2008 19:56:02 +0300
Peter Volkov wrote:
> В Птн, 19/12/2008 в 14:45 +0000, Ciaran McCreesh пишет:
> > If it reads (and presumably uncompresses) all of them at startup
> > anyway, what's the point in compressing them at all?
>
> It makes size smaller: bot
701 - 800 of 3510 matches
Mail list logo
