:
#* Copyright etc
more multiline stuff
*#
let EAPI = 3
Unfortunately, we have to care about these things when doing the formal
spec... There're developers who'll pull all kinds of insane crap in the
tree...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Thu, 26 Feb 2009 20:34:07 +0100
Luca Barbato wrote:
> Ciaran McCreesh wrote:
> > Anyone but Luca please. Luca's been busy selectively ignoring
> > problems with his proposal, refusing to answer objections to it and
> > claiming it solves problems that it doesn't.
i to the
> live branch you desire.
So if you do that, how does the package manager know that one version
is less than another if a particular use flag is enabled, but greater
than it if it is disabled?
> Again it had been answered in the summary anyway.
I thought you had a better answer than "it doesn't work" that I was
just missing. Evidently not...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
t it's already possible to have multiple equal versions of the
same thing (1.0_alpha0 equals 01.0_alpha-r0), and it's already
illegal. None of this is altered by any of the proposals.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
what you're trying to achieve,
whilst ignoring how things are currently defined or what is or is not
possible. Then we can look at that and work out whether it can be
mapped to an existing solution or some easily-implementable new
solution. Starting with implementation is the wrong approach.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
e.mask so we just made sure those packages had the proper
> keyword visibility.
So if you could mask 'testing'ish things that're in the overlay
(already possible), and provide an easy, consistent way for users who
choose to to unmask and keyword a particular group of packages, w
a user who has USE="foo bar" is
going to end up with a differently configured package depending upon
what he happens to have installed up-front, which is something that's
not supposed to happen.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
e_with() and use_enable() to accept multiple sets of
> arguments (alternately, making custom, similar functions that will
> take multiple args).
How would that work? I can't see an obvious way of doing it that isn't
more or less as verbose as just using multiple calls.
--
Cia
ess properly really requires package manager support for
multiple ABIs (for some value of B that includes things like Python
versions). I doubt this is fixable in the timeframe that seems to be
being considered here.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ting).
* Calling unpack on an unrecognised extension should be fatal, unless
--if-compressed is specified. The default src_unpack needs to use
this.
* pkg_info should work on things that aren't installed, as well as
things that are.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 09 Mar 2009 13:56:19 -0700
Zac Medico wrote:
> Ciaran McCreesh wrote:
> > * Limit values in $USE to ones in $IUSE (bug 176467). The existing
> > behaviour's majorly annoying; time for the package manager to
> > start enforcing things strictly.
>
> M
On Mon, 9 Mar 2009 22:33:11 +0100
Christian Faulhammer wrote:
> Ciaran McCreesh :
> > Next, some probably easy but long standing features:
> >
> > * src_test run unless RESTRICTed or explicitly disabled by the user
> > (bug 184812)
>
> A big no. This will lead
we
> introduce an IMPLICIT_IUSE profile variable to enumerate specific
> ones which are implicit members of IUSE?
I'd rather we were explicit about what's implicit. All forced / masked
flags is a pretty large set.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
;s a very good sign that something's broken, and you shouldn't
be carrying on.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
> immediately affect all packages in tree.
Uhm. See this thread being about EAPI 3?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ck foo.bar', where .bar is
an unsupported archive format, unpack just does nothing. This isn't a
good default behaviour; if a package really wants something to be
ignored silently, it should have to say so.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
emented without an EAPI bump?
If we screw up the specification and catch it early enough on, then
yes. But [use(+)] really isn't a bug fix...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
test suite on the first is no fun. As
> a user I would not accept two hours of build time. Test-driven
> development is great, but not so widely used as one could wish it to
> be.
And if you're on an especially slow platform, as a user you can turn
tests off.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 10 Mar 2009 10:08:06 +0100
Michael Haubenwallner wrote:
> Whats wrong with 'set -e' and doing '|| true' behind?
Waaay too many false positives.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
rather quickly ;)
Well, the alternative is to drop src_test all together. If a test
failure is meaningless, having the test is meaningless.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
if either of
the following conditions are met:
* ${A} is non-empty
* Any of src_unpack, src_configure, src_compile or src_install is a
defined phase.
Ebuilds where this would trigger a false positive would have to specify
S=${WORKDIR}.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
; run probably before productively using that software. But the user
> should opt for and not against it.
You're saying that users want to have something installed that they
aren't going to use productively?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 10 Mar 2009 17:11:56 +0100
Christian Faulhammer wrote:
> Ciaran McCreesh :
> > Then this is a legitimate problem that someone needs to know about
> > and fix. So having src_test turned on globally is a *good* thing.
> >
> [...]
> >
> > Again, findin
d ${A} to get that behaviour.
It's sometimes handy to have, and of course it's necessary for
default_src_unpack, but silently ignoring duff inputs isn't very
Unixy or very software engineeringy...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
d between the main repository and overlays, get
very messy. Working out exactly what happens when aliases disappear or
are inconsistent gets to be rather tricky.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
hing stable that can handle .xz
files?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
also only allowed to call EXPORT_FUNCTIONS once
per eclass. I seem to recall this being for historical reasons.)
--
Ciaran McCreesh
signature.asc
Description: PGP signature
t see this going anywhere any time soon for
Gentoo...
[1]: http://lists.exherbo.org/pipermail/exherbo-dev/2009-March/000409.html
--
Ciaran McCreesh
signature.asc
Description: PGP signature
at the user wants (they might
be doing an emerge -e, for example).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
* Am I to take it src_test is to remain in its current worthless state?
I've probably missed some more things, but I don't know what they are,
so if anyone can find any please list them.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
s, if you really don't want to see it, you can just make it all
invisible with one easy switch.
We've been over all this before. Unless you have something new to add,
kindly avoid wasting people's time.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
red ten times previously. I really
don't want to see the Council sit around and not approve EAPI 3 until
we have the whole kdebuild discussion again.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
fixed.
With the current situation, src_test is worthless because a failure
doesn't mean there's a problem worth investigating. But if EAPI 3
starts making src_test "run unless explicitly RESTRICTed or disabled",
any src_test failure in an EAPI 3 package will tell people something
requires attention.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
debuild-1's
status.
Also, this has nothing to do with EAPI 3. Please stop flogging this dead
horse so that the noise doesn't drown out what we're trying to get done
here.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
h this.
*shrug* PROPERTIES="slow-tests". Of course, then people will abuse it...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 17 Mar 2009 10:50:17 +0300
Peter Volkov wrote:
> If failures are non fatal I don't object to having src_test enabled by
> default and I'll all for this even.
...and src_test becomes utterly worthless again.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
rball but no
functions is likely to make it all the way through past the install;
previously it would die on the custom-written src_install.
Note that the wording is such that this will only matter for ebuilds
that install things. Blank ebuilds that install nothing will still work.
--
Ciaran McCree
ED_PHASES + A. If you're interested in the gory details, either
wait until I push the next PMS draft or have a look at [1].
[1]: http://lists.exherbo.org/pipermail/exherbo-dev/2009-February/000396.html
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 16 Mar 2009 20:47:17 +
Ciaran McCreesh wrote:
> http://github.com/ciaranm/pms/tree/eapi-3
Updated draft:
* S to WORKDIR fallback conditional for EAPI 3
* EAPI 3 has unpack --if-compressed, new src_unpack
* Formatting: -- should be -{}- for econf things
* RDEPEND=DEPEND gone
t, thanks to a formatting screwup. I've fixed that now.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ng moving things that definitely aren't
in the least bit likely to be a system dep on a bump, sure. Making 1 or
2 the default for new packages, sure. But rewriting existing things?
That's just an accident waiting to happen.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
riting
> > existing things? That's just an accident waiting to happen.
>
> What kind of accident do you expect to happen?
The same kind that always happens when lots of ebuilds get changed.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ge developer.
There is no added complexity. Those things are already there.
> > The same kind that always happens when lots of ebuilds get changed.
>
> ... lots of new features and a few bugs that get fixed the next day?
You must be new around here.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
t what features
> are where and what syntax is valid and all that.
Fortunately, you won't be. As the person who probably will be, I can
assure you that killing off EAPI 0 won't help in the slightest. It
won't mean we can remove all mention of EAPI 0 from the documentation,
since package managers need to support EAPIs indefinitely for
uninstalls.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
row is used, the filename used when
saving to \t{DISTDIR} shall instead be the name on the right of the
arrow. When consulting mirrors (except for those explicitly listed on
the left of the arrow, if \t{mirror://} is used), the filename to the
right of the arrow shall be requested instead o
for EAPI 3
18) EAPI 3 has unpack --if-compressed, new src_unpack
19) RDEPEND=DEPEND gone in EAPI 3
20) EAPI 3 has doexample.
21) REPLACING_VERSIONS and REPLACED_BY_VERSION in EAPI 3
22) EAPI 3 has nonfatal, utilities die
--
Ciaran McCreesh
signature.asc
Description: PGP signature
an
existing one is that some of the existing do* utilities don't take just
a single simple filename, so overloading would make the command line
somewhat convoluted.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
gt; the permissions if file/directory is protected.
The package manager shouldn't be messing with permissions on existing
directories at all (directories are a shared resource). If you want to
change permissions on an existing directory, do it in pkg_preinst.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
done using a simple tag.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 25 Mar 2009 10:19:12 +0100
Luca Barbato wrote:
> Ciaran McCreesh wrote:
> > Uhm. Do you think these ideas of yours through at all before posting
> > them?
>
> Being rude doesn't make you cool. (Nor make your points more
> effective)
That's not being r
ge to be able to
evaluate the merits of proposals, I invite you to rethink those
comments and deliver your apology.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ies. Also I could be wrong, but wouldn't you
> want to be able to cache this and show smart pretend output, etc?
I think you're misunderstanding what this is for. It's to allow
packages to work out whether they're upgrading / downgrading /
reinstalling / whatever, since Zac broke the devmanual-documented and
PMS-required way of doing it using has_version and refuses to revert it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
n 11.1.1, but in
> that section is nothing about it.
I'm still not sure a) whether we want those, b) how exactly they work
or c) whether there's any chance at all of Portage supporting this in
the time we're after.
> > 20) EAPI 3 has doexample.
> Including "-r&q
one picked up on and documented (with
incorrect examples). It's *already* special, weird behaviour, and it's
special, weird behaviour that can't be used correctly.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
, which he didn't know about
before he implemented the changes, he went and fixed some, but probably
not all, things relying upon it in a big commit spree...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ll we're
> just specifying previously unspecified behavior - but it will help
> Paludis.
No, an EAPI bump is necessary. Older (post-EAPI) Portage versions do
something different, so any ebuild relying upon particular behaviour is
already broken.
- --
Ciaran McCreesh
-BEGIN PGP
done_docs="${done_docs} ${d%/}${d:+/}${doc}"
dodoc "${doc}"
fi
done
done
done
if [[ -n ${d} ]]; then
docinto "${docdesttree}"
odoc failed"
Spaces... Also, the || die bit for EAPI 3 will be wrong.
> else
> for x in AUTHORS ChangeLog NEWS README; do
> if [ -e ${x} ]; then
Is -e really better than -s?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 30 Mar 2009 21:07:42 +0300
Petteri Räty wrote:
> should have || die where appropriate
It's EAPI 3, so it doesn't need it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ompiles is way beyond what we can get
done for EAPI 3. They're a lot harder than one might initially think.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
we all agree that shorter code is always better, since having
less to read makes things easier to understand.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
he necessary changes to make it
mainstream.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
lso, we still get people who just post their paludis --info. Could
> you please put in *bold letters* at the top of that output that it's
> not the info they'll need when reporting bugs.
It's in bright pink at the bottom. If people aren't reading that, tell
t
paradigm.
Were we after keeping IUSE_IMPLICIT? That whole part is still fairly
vague, since I'm not sure what Portage is going to be able to do with
it in time for EAPI 3.
- --
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAknXs5wACgkQ96zL6DUtXhE
via a number of
special magic profile variables, so you'd either have to list it
everywhere or use one of the profile variables. Once you do that, how
you mask / force it is up to you, unless you need some kind of special
package manager handling for that flag.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ing the spec up-front". Writing code before you know
what problem that code is trying to solve is even worse than writing a
spec first and coding from that.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
o and what would be suitable or ideal for main tree use.
I think we'd all benefit from a proper discussion of goals and details
of how various problems will be solved before moving prefix to an
official EAPI.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
rrent dependency format, and have nothing to do
with := and :* themselves.
They're not real limitations, either, since as Tiziano points out, in
the real world there's a neat correspondence between version ranges
and slots, and if there aren't you can't deal with them anyway.
horrible section of PMS devoted to explaining its quirky behaviour.
> I'm not even sure anymore where to find a list of items that is
> current for what's on the table for EAPI-3 right now...
Do a git log on the PMS draft (or look at the summary table in the
appendix). It's fairly close to one commit per EAPI item.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
that there's .lzma, .xz and so on, so it could know which
> build-time deps are necessary - repoman warning anyhow, later some
> alternative unpacker might surface.
Uh. Unknown types doesn't mean "fail on lzma if lzma's not installed".
Please check the PMS draft for what it does mean.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
wer in relation to binary distributions.
PROPERTIES="slow-tests" then.
We've been over all of this several times previously.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ly, it looks like this proposal's one of those things that
some people will hate for ideological reasons no matter what. I just
hope there're enough people on the Council for whom QA and user systems
not breaking is sufficiently important that they'll vote in favour of
it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
osal. As packages are
moved to EAPI 3, any package with broken tests can, at the maintainer's
choice, either get RESTRICT=test (which they should have been given
already) or get fixed tests.
This is no more work for maintainers. All it does is makes sure they do
something they should be doing
gure scripts. We
already pass various weird things through econf, so any configure
script that dies on unrecognised options is probably going to break
anyway. No-one's managed to name a configure script that would be
broken by this change that isn't already not using econf anyway.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
t
>paludis output to feel like emerge output
>
> to solves this issue? Would that technically
> be possible?
Sure, but we're not going to do it. All the information provided by
paludis --info is necessary and useful. Taking any of it out would be
removing things that are requ
On Mon, 13 Apr 2009 23:50:07 +0200
Sebastian Pipping wrote:
> Ciaran McCreesh wrote:
> > Taking any of it out would be
> > removing things that are required to determine the cause of a bug.
>
> I doubt that's true in most cases: The information needed to
> finding
able to keep up with
the workload otherwise...
- --
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAknnrusACgkQ96zL6DUtXhEZBgCffO/OlEDubIUdVyyOtJ73gwuW
+BQAoKz/D5u2ihDY9icN+ZOyQpoATFce
=jB6X
-END PGP SIGNATURE-
ures selected by the Council
members who responded to the "PMS EAPI 3 more or less ready" thread
[1], or with features selected by the PMS editors if a majority of the
Council hasn't replied at least 24h before the meeting.
[1]: http://tinyurl.com/ccn5h8
--
Ciaran McCreesh
signature.asc
Description: PGP signature
me on EAPI 4. We
all know that these things are pending, so why not just have them as
being early on the list of things to discuss once EAPI 3's out of the
way?
Otherwise I see us sitting around debating things for EAPI 5 with the
EAPI 3 list still not decided or approved...
--
Ciaran McC
oing to do that, why not do it as an EAPI thing? This has
the added bonus that there's a clean migration path...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
[use(+)] dependencies are
rather crippled. You can't do [linguas_en(+)] against any existing
EAPI, for example.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ed,
there are a load of standard questions (versions of libraries that
aren't in the usual info_pkgs list, configuration questions, ...) that
need to be asked. This is a way of automating it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ppears to have a legitimate use case. The latter in particular would
only encourage abuse (people might mistakenly think it's a solution to
the Python / Ruby ABIs thing).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
on saved
> environment? Any suggestion into the spec which way to use for
> checking if the package in question is already installed or not?
has_version works there.
> > * UNPACK-IF-COMPRESSED
>
> query
> I think the spec draft reads that it will be an error to pass regular
&g
t, or comments in replies.
It's always possible to override it if necessary.
> --enable-fast-install is completely new to me for consideration under
> EAPI-3. Maybe I just missed it when reading PMS draft before, and it
> wasn't listed in the other summaries.
No, it's been th
re-20090421/work/linux-firmware-20090421/*':
> No such file or directory
>
> Yet the files are really in that directory.
It's looking for a file literally named '*'.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ere're any
symlinks under there, behaviour is undefined.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
much useful
information as it can, though. In particular, it shouldn't do things
like "if we're installed, don't display this information", since people
might be having trouble with a reinstall.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Thu, 23 Apr 2009 01:29:11 -0700
Brian Harring wrote:
> On Wed, Apr 22, 2009 at 02:57:34PM +0100, Ciaran McCreesh wrote:
> > On Wed, 22 Apr 2009 16:56:08 +0300
> > Petteri Räty wrote:
> > > Ok. So people should then be using has_version in pkg_info if they
>
something or
> otherwise being horribly long.
Uh, you just do econf --enable-dependency-tracking.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
with some
> future syntax regarding list of slots. The feature concept itself
> seems sound and reasonable, but I think we might be able to do better
> with the syntax for the long run when slot lists come into play.
It fits in fine with the syntax we've been thinking of using for slot
groups and version ranges.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
dly changing
behaviour" thing. Without a resolution to this all the EAPI work we're
doing is a waste of time.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
et to
> whatever other items came after this one.
Might as well hold off GLEPs 54 and 55. They're both effectively EAPI 4
territory anyway.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
#x27;m
happy presenting arguments that have already been made, and debunking
any untrue claims I happen to notice, but beyond that on this one I'm
happy to just see it go to vote...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
y, Gentoo has lost a lot of good people because they weren't
prepared to put up with EAPI stagnation.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
already have
ends up being spent fixing all the screwups made by people who were only
recruited to make up numbers. Gentoo needs better developers, not more
developers.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
within Gentoo.
> In terms of figures a conservative estimate would be 25% wouldn't
> have the necessary skills and another 25% would be unsuitable.
A conservative estimate would be that 90% of the people who decide to
be developers because of such an initiative would be unsuitable.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
emove two thirds of the
packages from the main tree.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
stions.
At the very least, before attempting any mass recruitment, the quiz
needs to be lengthened, brought up to date and split into "answer these
on the spot on IRC without having seen the question before" and
"research allowed" questions, and recruiters have to be prepared t
. But people need to be able to recognise mistakes even when they're
not looking for them, and to know when something's wrong even if they
haven't been told to find the mistake -- being able to do this requires
having a good immediate knowledge of certain parts of the material.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
901 - 1000 of 3510 matches
Mail list logo
