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.
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?
Profili
having to fix 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.
flat file to db
lu - thinking of a darker future.
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
y overriding 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 Co
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 o
't think better ways to annoy people?
For that matter, I'm 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
time isn't.
People marking stuff ~ or stable should run the testsuite as a way to
make sure the package is sound. Users shouldn't take this pain.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
has a test (false), nobody will have
src_test dummified.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
suites for EAPI 1, you'd've
found 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 rationa
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 fault." - gcc upstream
--
Luca Barbato
Gentoo Council Member
Gen
more 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.
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
s got 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
No, you 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
--
ge
for them and let people do the automated
test for them.
- having that mandated 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
ople release a package manager that claims 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
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
coupl
e a large
field to cover 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 Membe
iving substance 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
noring the EAPI 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
rtage 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 Gento
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 fr
d party and possibly have a regression/conformance 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.or
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
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
preN 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.gento
f allowing 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 wit
, is how such a scheme would
work for non integer based 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
in mind that even trunk changes enough that you need 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
the CPV vs. atom issue.
Hmm, give me more informations about your concern.
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 me
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, a
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 gue
ssues were 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 p
ternative tests that allow testing for dropped
keywords 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'
of the bleeding edge you
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
ble, I think my proposal nicer and
giving some value for the effort of implementing it, -scm adds a some
work to do with undefined features at best.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
eed to fill a
bugreport.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
has been released)
correct, 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
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
--
ge
user 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
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 num
I have got a feeling, that you didn't 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
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:
No that
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
late and saving 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
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
nm and crew, be it a "beta" tag, an obscure 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
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 f
istro. 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
o long; are we going 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 Membe
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 ge
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
expect any 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
le have a subprofile 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
would 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
Ł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
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
orba/orbit.
gconf is still problematic nonetheless.
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
ntconfig directly.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
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
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
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
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
...
Nothing that couldn't be done using an eclass and a nicer syntax IMHO...
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
ny problems with it.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
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
/var/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
, not the
other way around
- you aren't helping me
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
new files 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
-base 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
erent subthread before
noticing this post:
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 Barbato
Gentoo Counci
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 wrote:
Ciaran McCreesh wrote:
On Fri, 13 Feb 2009 18:20:34 +0100
Luca Barbato wrote:
Live template provide correct ordering since
r such task. I checked with zmedico and PROPERTIES
support conditionals so that is the _bare_ minimum to archive 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 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 sane on
Ciaran McCreesh wrote:
On Fri, 13 Feb 2009 23:35:34 +0100
Luca Barbato 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 lea
I put in my devspace got in.
If there weren't people quite vocal against -scm the council wouldn't
have been involved.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
I hope that is what the various proponents meant with their proposals
and that's clear enough.
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 di
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
tion doesn't make it worth the effort and
disruption it would lead.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
stage sourcing done.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 03:15:03 +0100
Luca Barbato 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 entry fro
ow how things like inherit will affect the environment.
And without knowing 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
t extract the eapi, being it in a fixed place, and then do the parse.
- Extracting such information could have different costs depending on
where to place it.
- I started to check if the proposal about having the fixed position as
the end of the filename is really much more viable than havin
Alistair Bush wrote:
Luca Barbato wrote:
Alistair Bush wrote:
I just don't think those numbers tell us anything and that should be
obvious from anyone who has read GLEP 55[1], we ain't really attempting
to solve a problem that exists within the tree currently (well the bash
issue
all things that have been discussed at length
previously. Please either come up with a legitimate technical
objection, or admit that you've seen the light.
the glep doesn't show any of those nor reference to it, as I said
before, do your homework and probably more people will be happier w
Ciaran McCreesh wrote:
On Tue, 24 Feb 2009 17:04:28 +0100
Luca Barbato wrote:
Ciaran McCreesh wrote:
On Tue, 24 Feb 2009 08:08:23 +0100
Uh, your benchmarks are nonsense.
Provide your nonsensical ones.
You're doubling the number of files that have to be read for an
operation that
101 - 200 of 758 matches
Mail list logo
