Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 03:15:03 +0100
Luca Barbato lu_z...@gentoo.org wrote:
Let's try to start with a common workflow for the user:
- an user with an ancient version of portage syncs
- it requires a package
- it looks at the cache ($portdir/metadata/cache/)
- picks the best
the EAPI, you don't know which version of inherit to
call.
It it isn't invalid already...
(i hope i have this right. feel free to call me names if i don't)
Names!
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Luca Barbato wrote:
Ciaran McCreesh wrote:
Because your proposal addresses none of the underlying problems which
GLEP 55 was created to solve.
let's get some numbers to have an idea of the dimension of the problem.
domino portage # wc -l /dev/shm/eapi_files.list
2854 /dev/shm/eapi_files.list
lead.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
to:
dodoc examples
Your comments?
I like the idea, not sure if dodoc could take an -r or just accept
automatically directories.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Second step, shortcomings.
Luca Barbato wrote:
main problem:
- have the possibility to track upstream w/out having to take a manual
snapshot of their sources, but having portage automatically fetch them
from their tree.
This issue isn't and shouldn't something that touches directly our
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
I moved the discussion on -dev since it should be the right place to
discuss this.
Ciaran McCreesh wrote:
On Fri, 13 Feb 2009 20:33:31 +0100
Luca Barbato lu_z...@gentoo.org wrote:
Ciaran McCreesh wrote:
On Fri, 13 Feb 2009 18:20:34 +0100
Luca Barbato lu_z...@gentoo.org wrote:
Live template
the use
case I want to track a/any number of non version branch of a/any target
source controlled tree from upstream
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Ciaran McCreesh wrote:
On Fri, 13 Feb 2009 23:17:03 +0100
Luca Barbato lu_z...@gentoo.org wrote:
Ciaran McCreesh wrote:
No, but something can represent the most commonly used models. We
can't do -scm packages for upstreams that do utterly crazy stuff
anyway, so we'll stick to the reasonably
Ciaran McCreesh wrote:
On Fri, 13 Feb 2009 23:35:34 +0100
Luca Barbato lu_z...@gentoo.org wrote:
Hence -scm...
that cannot do as well for more than a single target w/out using use
flags.
Because it isn't supposed to. Versions and topics are not the same
thing, and treating topics as versions
to a different subthread before
noticing this post:
snip random idea :p
The simplest method I can think of is:
${PORTDIR}/tags/games/puzzles/ksudoku - ../../../kde-base/ksudoku
Sounds nice and has the added value to be possible to opt out and to
not hinder who do not care about it.
lu
--
Luca
contains everything comes from the main kde distribution.
What about both ways using symlinks: kde-games/ksudoku - games-puzzle/ksudoku ?
No symlinks and no aliases please.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
in the project, or look at the diffs), or as I
said in 'e)', use some tricks with /etc/portage/bashrc.
That looks interesting.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
/lib/gentoo, so I'd see all
gentoo-related files as
/var/lib/gentoo/eselect
/var/lib/gentoo/enews
/var/lib/gentoo/herdstat/
/var/lib/gentoo/module-rebuild
/var/lib/gentoo/portage
What do you think about?
Looks quite wrong. I'd do /var/lib/gentoo/enews - /var/lib/enews btw
lu
--
Luca Barbato
Since I'm planning to revamp the qemu ebuilds and provide a more
flexible way to pick which targets get built since most of the
interesting one are already supported by tcg thus building with gcc4
just fine, I'd merge back softmmu and user and export the available
targets this way.
lu
On 4-12-2008 21:29, Diego 'Flameeyes' Pettenò wrote:
One has to consider people might be using -l for parallel building too,
I'd have it in a separate variable as well, IFF another build system is
as nice as make towards parallel build.
lu
using an eclass and a nicer syntax IMHO...
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Zac Medico wrote:
The intention is for PROPERTIES=live to have a relatively pure and
simple meaning.
Ok.
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Andrew D Kirch wrote:
[...patches...]
Common practice is to work with upstream (if alive) and have the patches
merged asap. Nothing _that_ strange IMHO.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
that something like
RESTRICT=constant-sources would be better.
Like I've said before, that particular convention is pretty
worthless in my eyes. I'd much prefer RESTRICT=live-sources if we
want to use a longer name.
Looks fine to me.
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
Christian Birchinger wrote:
But no matter how wrong i think it is, i usualy respect the
upstreams wishes.
If upstream is wrong I think we should help them...
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
.
gconf is still problematic nonetheless.
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Adam Stylinski wrote:
The intel C Compiler (icc)
icc, xlc, llvm, sunstudio could be interesting fields of discovery.
Which are the pitfalls of using icc?
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing
Łukasz Damentko wrote:
Dear Gentoo Community,
Here are your verified and long-awaited results.
Gentoo Council for term 2008/2009 will be:
Donnie Berkholz (dberkholz)
Mark Loeser (Halcy0n)
Diego Petteno (Flameeyes)
Petteri Raty (Betelgeuse)
Luca Barbato (lu_zero)
Markus Ullmann (Jokey)
Tobias
rather like to have less bugs in their mailbox.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Tiziano Müller wrote:
What do you think of them?
Both seem good, I'm looking forward to see them completed =)
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
with compiler/linker specifics and
move there non sharable stuff and keep base leaner?
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
feature some
developers may like for tracking live sources (and the user should not
use), possible fut{ure,ile} changes in the ebuild format.
lu - putting in perspective
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org
Chris Gianelloni wrote:
On Fri, 2008-06-13 at 12:22 +0200, Luca Barbato wrote:
David Leverton wrote:
On Friday 13 June 2008 11:10:46 Nirbheek Chauhan wrote:
Interesting to note, however, that Paludis doesn't accept inline
comments, and this behaviour predates PMS.
There's a reason for Paludis
. Trollix may be a
good place to start...
Oh look, speaking of agendas
...are you issuing a press release for exherbo?
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
to wait forever ? It's probably better
to unmask it or revert the change at this point.
We could either pick a week and do a major ebuild update to remove .la
files when unnecessary or just append a notice about revdep rebuild.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
David Leverton wrote:
On Thursday 19 June 2008 08:51:15 Luca Barbato wrote:
We could either pick a week and do a major ebuild update to remove .la
files when unnecessary or just append a notice about revdep rebuild.
How do you decide when they're unnecessary?
.la are used for :
1 getting
David Leverton wrote:
On Thursday 19 June 2008 10:36:12 Luca Barbato wrote:
1 getting static libraries (pkg-config replaces this use)
Not for library consumers that use libtool but not pkgconfig.
2 load plugins using libtool support
Why only plugins? What's to stop an application from
action from us (the GDP), please
file a bug. We don't read every thread on the -dev ML.
I bugged the releng =)
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Ryan Hill wrote:
On Sat, 14 Jun 2008 22:16:36 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Bernd Steinhauser wrote:
Wow, impressive.
Actually, you can't be serious...
I am.
GLEP 54 for quite some time now and it works very well.
adds nothing to - and sets usage as is.
I just don't see
those post install in the vdb should suffice.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
to
update the ebuild thus makes sense use a next supposed version.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Ciaran McCreesh wrote:
On Sat, 14 Jun 2008 10:19:32 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
I'm confused. If I have a gcc-4.4.0.live ebuild which checks out
rev. 136737, after the merge do I have gcc-4.4.0_pre136737
or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc)
installed
Ciaran McCreesh wrote:
On Sat, 14 Jun 2008 11:53:51 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
On Sat, 14 Jun 2008 10:19:32 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
I'm confused. If I have a gcc-4.4.0.live ebuild which checks out
rev. 136737, after the merge do I
Ciaran McCreesh wrote:
On Sat, 14 Jun 2008 12:04:45 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
It will be available once you trigger again the generation or if
you put a normal ebuild with such name.
And what triggers said generation?
I already replied in this thread, I guess the information
open.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Santiago M. Mola wrote:
On Sat, Jun 14, 2008 at 10:19 AM, Luca Barbato [EMAIL PROTECTED] wrote:
Ryan Hill wrote:
I'm guessing the dev would need to change 0.26.live to 0.26.1.live when
0.26 was released. I already need to do this with my live ebuilds. Of
course, with some projects you never
or for the existence of keywords just for live ebuilds.
Agreed.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Ciaran McCreesh wrote:
On Sat, 14 Jun 2008 14:27:22 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Many of them applies as well to the alternative proposal, I wonder
how you could say we, council, had to vote the other proposal given
such (and other) issues were open.
No they don't.
False
acknowledge that you are experimenting.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
, you can keep tracking 4.1.1, have interim snapshot pushed in
portage to ~ if you are confident about them.
4.1 branch = 4.1.2.live (before 4.1.2 has been released)
4.1 branch = 4.1.3.live (before 4.1.3 has been released)
same reasoning.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux
Fernando J. Pereda wrote:
nope it would resolve as foo_pre1 - meaningless.
So your proposal is unable to handle that case, right?
You are forced to put a version, that's all.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev
option, if the pkg_scm_info value hasn't changed and it's a
reinstall, skip reinstalling.
* At user option, and not by default, do the fetch / info stage
*before* showing the this is what we'll install list.
Sounds quite interesting.
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
Ryan Hill wrote:
On Sat, 14 Jun 2008 17:55:27 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ryan Hill wrote:
So every user will have a different _preN version which would vary
depending on how often they rebuild the package and that has
absolutely no correlation with the revision number
have to deal with live packages
that much yet. (No offense.)
Beside e17 and ffmpeg you mean?
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Fernando J. Pereda wrote:
On 14 Jun 2008, at 19:36, Luca Barbato wrote:
Bernd Steinhauser wrote:
With your approach, we would have to fix the version after every
4.1.x release. That sounds awful, tbh. So:
No that enforce people update the deps or at least gives one more
reason to do. Keep
.
No.
And that includes the ordering.
No.
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Fernando J. Pereda wrote:
On 14 Jun 2008, at 20:02, Luca Barbato wrote:
Fernando J. Pereda wrote:
On 14 Jun 2008, at 19:36, Luca Barbato wrote:
Bernd Steinhauser wrote:
With your approach, we would have to fix the version after every
4.1.x release. That sounds awful, tbh. So
Fernando J. Pereda wrote:
On 14 Jun 2008, at 22:18, Luca Barbato wrote:
mainline glibc usually requires you to fix it or the rest of the world...
What?
I experienced that the hard way -_-
(btw they are single packages, emerge =python- works as should)
So what was your proposal all
Ciaran McCreesh wrote:
On Thu, 12 Jun 2008 21:40:28 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
* ordering for _pre is wrong.
hm?
foo-0.26-live would become foo-0.26_pre1, which would be 0.26. This
is clearly wrong.
No, it is correct and what you want. Upstream is aiming for 0.26, once
is the highest preN present, if present.
(Just in case you were thinking of letting the pm auto-masking/unmasking
foo_p${value+1}: this would be hackish and ugly).
Uh?
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org
them in PMS or not, therefore PMS doesn't allow
them. There's no evil conspiracy here, just pure logic.
Care to share the logic and wise reasoning ?
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Tiziano Müller wrote:
Luca Barbato wrote:
Tiziano Müller wrote:
@lu_zero: I don't think we can get away without having the pm know what a
live-ebuild exactly is and when to re-install it.
a live ebuild is a template, every time it has to be evaluated it acts
as a normal ebuild
revnos- git for example, which is reliant
on a hash (just the hash, afaik).
The revision has to be stored inside the generated ebuild so all you
need to have is:
- a way to know the revision you are checking out
- a way to store such revision withing the ebuild
lu
--
Luca Barbato
Gentoo
process.
The eapi process is something not defined so they cannot do much about
it, same for the portage people.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
and pkgcore developers are
complaining about eapi definition and PMS management.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
(better
management and automated snapshot generation from the live ebuild).
http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst
I'd like to see some comment on it (I put it in glep form just now so it
isn't exactly perfect)
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http
Ciaran McCreesh wrote:
On Thu, 12 Jun 2008 11:05:01 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Just for fun I took some of the ideas about alternative management of
the issue and specified the features it makes it worth changing
(better management and automated snapshot generation from
test built
in (such a small tree with dummy ebuilds and eclasses) to allow
automated validation. Stronger and well defined versioning should help
as well.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing
recommendations at best.
You are right.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
at least one major bug straight away.
http://www.pkgcore.org/trac/pkgcore/newticket
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Ciaran McCreesh wrote:
On Wed, 11 Jun 2008 07:53:21 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
A whole bunch of science packages have upstreams that say If you're
building from source, run 'make check' and if it fails don't carry
on.
Their rationale behind that is that their code is severely
importantly, it still means that people *know* that a failing
src_test is to be investigated. Currently they instead have to guess
whether it's a lazy developer issue or a genuine bug being shown.
Not really.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org
Ciaran McCreesh wrote:
On Wed, 11 Jun 2008 08:57:35 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
You assume that users have working, properly configured compilers.
It's fairly well established that a lot of them don't, particularly
on Gentoo.
if your code sucks isn't our
them used by the people that cares already.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Ciaran McCreesh wrote:
http://en.wikipedia.org/wiki/Straw_man
http://en.wikipedia.org/wiki/Quote_mining
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
aren't talking, you are babbling about undefined flaws that
nobody can evaluate, for which you aren't providing a way to reproduce
it and possibly doesn't exist.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org
by the eapi doesn't have sense since it doesn't
change anything by itself.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
to support a certain EAPI
but doesn't. If pkgcore had any actual users we'd have to consider
banning EAPI 1 in the tree and releasing EAPI 2 as being identical to
EAPI 1 just to work around this.
Apparently those users do not see the problem, you do, help those blind
people.
lu
--
Luca
Bernd Steinhauser wrote:
Luca Barbato schrieb:
Ciaran McCreesh wrote:
The point is to make pkgcore a better package manager by getting the
developers to do some basic testing. We're not talking some obscure,
weird bug here. We're talking a really obvious, major screwup that a
couple of quick
but you also do not know the bounds of it.
It really doesn't matter how it is specified. You have an implementation
of it and should make sure, that this implementation works.
Seems to works well enough for people using it.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http
to your claims.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
better.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
-version without sourcing the ebuild.
Check if exists a line EAPI=*$, if does and the rest of the string
matches an understood eapi, go on sourcing, otherwise ignore/mask it...
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev
.
The simplest way is to change the syncpoint in the new package manager
and leave the previous uri with a compatibility repo for the older ones.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
with the minimal eapi and the
minimal set of ebuilds needed to upgrade, one with the latest and greatest.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
you'd just need 2 trees, managed as overlay and a
marker for each tree on which eapi to use, but I dislike empty theories
or hardly searched corner cases that could be avoided with half of the
effort necessary to get there.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http
Fernando J. Pereda wrote:
No, it doesn't make parsing faster. Had you bothered to profile any
package manager you'd know that.
Do you have any number to share?
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org
Fernando J. Pereda wrote:
On 10 Jun 2008, at 15:48, Luca Barbato wrote:
Fernando J. Pereda wrote:
No, it doesn't make parsing faster. *Had you bothered to profile any
package manager you'd know that.*
Do you have any number to share?
What number are you interested in?
Profiling numbers
the
whole tree all at once. Users can still choose not to go with the default.
People will (and should) have -test in FEATURES anyway, good self-test
suites usually take more than twice the time to build and run, may have
additional dependencies that could take lots of time.
lu
--
Luca Barbato
.
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
the versioning
rules of an eapi.
Must be a superset being wrong does not mean entirely arbitrary
changes are OK is right.
You have actual usecases (eventually not thin air), which is your
counterproposal that works for them?
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http
Ciaran McCreesh wrote:
On Wed, 11 Jun 2008 06:24:18 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
People will (and should) have -test in FEATURES anyway, good
self-test suites usually take more than twice the time to build and
run, may have additional dependencies that could take lots of time
strongly inclined to say that for Paludis too...
Getting the build time from 30minutes to an hour or more?
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
. academic paper markup vs
plain text, natural language used to specify syntax while a grammar
notation like EBNF would be better suited, when I asked people why so
few were contributing about this document.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org
bothered to provide details?
- rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml.
- use EBNF when describing a syntax.
- split it and version each functional part.
- define EAPI as an aggregate of those versions in a separate part.
lu
--
Luca Barbato
Gentoo Council Member
Ciaran McCreesh wrote:
On Mon, 09 Jun 2008 10:50:11 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
So how, specifically, is PMS wrongly written, and why hasn't
anyone who thinks so bothered to provide details?
- rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml.
What technical
a non-breaking space between 'see' and the
reference.
Pointless nit.
How does bunch o'neat code deal with our code file containing things
that XML considers to be reserved characters? That code probably has
ampersands and angle brackets in it.
As usual for xml markups.
lu
--
Luca Barbato
Gentoo
makes my eyes bleed somewhat, you can read it in a very
well done PDF.
The pdf renders poorly on xpdf due the fonts latex has, usually I'd
rather have plain text anyway.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev
, discussing the changes with the people in
-dev (NOT THE COUNCIL) or you may retract them.
3. Most wanted changes in future EAPIs
Somebody is thinking the PMS and the EAPI definition as it is are wrong
and should be replaced since they aren't useful for their purpose.
lu
--
Luca Barbato
, I accept.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
301 - 400 of 695 matches
Mail list logo
