On Tuesday 05 July 2005 18:39, Martin Schlemmer wrote:
On another note .. how do you guys plan to handle this BDEPEND .. just
for x-compile, or global? If global, any ideas how to solve the
circular issues ???
Global. There's no real difference between building a package for the local
On Saturday 02 July 2005 02:49, Mike Frysinger wrote:
On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
Currently, we pretty much leave out the big dogs of build depends from
ebuilds- basically we rely on the profile to require a suitable
toolchain. Couple of issues with this
On Thursday 07 July 2005 02:08, Brian D. Harring wrote:
Basically, I was attempting to get feedback on issues where this
wouldn't be quiet enough, an example of which is ncurses.
(my understanding of this, thanks to flameeyes for clueing me in)
ncurses built/installed in chost==ctarget,
On Tuesday 05 July 2005 19:48, Martin Schlemmer wrote:
This is all well and dandy, but try to add coreutils as a dependency of
itself, or gcc of itself, or sed ... or grep ... etc, and then try to do
a stage1 install (probably stage2/3 as well, but I never do those, so
rather wont comment).
On Saturday 09 July 2005 11:28, Jason Stubbs wrote:
I didn't read this in the thread. How does this work?
ncurses needs to run a given binary (that I don't remember now, sorry), during
the compilation stage. The build system try to build it bug if $CC !=
$BUILD_CC (literally) it considers it
On Sat, 2005-07-09 at 18:28 +0900, Jason Stubbs wrote:
On Tuesday 05 July 2005 19:48, Martin Schlemmer wrote:
This is all well and dandy, but try to add coreutils as a dependency of
itself, or gcc of itself, or sed ... or grep ... etc, and then try to do
a stage1 install (probably stage2/3
On Sat, 2005-07-09 at 11:47 +0200, Diego 'Flameeyes' Pettenò wrote:
On Saturday 09 July 2005 11:28, Jason Stubbs wrote:
However, if an ebuild chooses to run make directly for some unknown reason
or use some specific tool to unpack an unsupported file format, the package
should really be
On Saturday 09 July 2005 12:20, Martin Schlemmer wrote:
I still this this is a bsd issue, so some or other solution which do not
include having gmake (and then later lots of other symlinks/whatever)
should be installed system wide for only a very small portion of our
user segment on all
On Sat, 9 Jul 2005 14:08:24 +0200
Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:
On Saturday 09 July 2005 14:01, Martin Schlemmer wrote:
And this is exactly what one of the issue for me is. Now devs on
the linux sides, need to learn bsd make peculiarities as well (to
start with, but
On Sat, 2005-07-09 at 15:11 +0200, Diego 'Flameeyes' Pettenò wrote:
On Saturday 09 July 2005 15:05, Martin Schlemmer wrote:
Ditto - point being, is that if you want the agony of per-ebuild hacks,
be my guest, but do not expect the rest to hold your hand.
It's not a matter of per-ebuild hack.
I'll even top post this one :P Take it back to the thread flameeyes
started about this originally pretty please, with sugar on top.
On Jul 9, 2005, at 9:10 AM, Martin Schlemmer wrote:
On Sat, 2005-07-09 at 15:11 +0200, Diego 'Flameeyes' Pettenò wrote:
On Saturday 09 July 2005 15:05, Martin
On Tuesday 05 July 2005 02:39, Martin Schlemmer wrote:
Also as already asked, what about the chicken egg issue ... (think tar
needing tar, or gzip needing gzip to unpack)?
The stages could come primed with the data that the packages on them are
already installed.
pgpyh0WySyPe7.pgp
On Jul 7, 2005, at 6:56 AM, John Myers wrote:
On Tuesday 05 July 2005 02:39, Martin Schlemmer wrote:
Also as already asked, what about the chicken egg issue ... (think
tar
needing tar, or gzip needing gzip to unpack)?
The stages could come primed with the data that the packages on
On Fri, 2005-07-01 at 13:42 -0500, Brian D. Harring wrote:
On Fri, Jul 01, 2005 at 02:30:12PM -0400, Mike Frysinger wrote:
On Friday 01 July 2005 02:11 pm, Brian D. Harring wrote:
Meanwhile, back to the you want us to add what?, our dependency
graph *is* incomplete.
so what ? i dont
Martin Schlemmer wrote:
On Fri, 2005-07-01 at 15:59 -0700, Drake Wyrm wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
Currently, we pretty much leave out the big dogs of build depends from
ebuilds- basically we rely on the profile to
On Tue, 2005-07-05 at 18:17 -0500, Brian Jackson wrote:
Martin Schlemmer wrote:
On Fri, 2005-07-01 at 15:59 -0700, Drake Wyrm wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
Currently, we pretty much leave out the big dogs of
Martin Schlemmer wrote:
snip
Big picture here:
* BDEPEND does nothing now, so don't worry about it if you don't want to
* in the future it will make other things possible
* give the man problems you see with the proposal, not just tell him that
portage doesn't handle it right now... I think out
On Fri, Jul 01, 2005 at 08:16:46PM -0500, Kito wrote:
Accurate deps should be a goal for the tree, a long term one
obviously...
Picking at the words (not you), but long term == it gets ignored
till someone starts screaming/foaming at the mouth.
If BDEPEND were added, it's extra data that
Hola.
Quick statement of terminology-
x-compile == cross compiling, building arm crap on an x86, building up
a x-compile target in a subdirectory of / (fex)
Currently, we pretty much leave out the big dogs of build depends from
ebuilds- basically we rely on the profile to require a suitable
On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
Currently, we pretty much leave out the big dogs of build depends from
ebuilds- basically we rely on the profile to require a suitable
toolchain. Couple of issues with this though-
1) Deps aren't complete for an ebuild.
2) Merging a
On Friday 01 July 2005 18:25, Brian D. Harring wrote:
So... why don't we add a new DEPEND, BDEPEND (build depends), that
holds atoms of what is required to actually build the package,
literally, what executes on the box to build that package.
Ok trying to get this a bit more clean to tech
On Friday 01 July 2005 19:49, Mike Frysinger wrote:
so what you're proposing is that we add binutils/gcc/glibc to every package
that compiles something, make to every package that uses make,
sed/grep/bash/coreutils to every package which runs configure, and
tar/gzip/bzip2 to every package
On Fri, Jul 01, 2005 at 01:49:19PM -0400, Mike Frysinger wrote:
On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
Currently, we pretty much leave out the big dogs of build depends from
ebuilds- basically we rely on the profile to require a suitable
toolchain. Couple of issues with
If the point is to make dependencies complete, isn't there a way to
build in some support for detecting it into some tool or other?
If we have a program that can create an environment and detect which
programs are run within the environment (maybe sandbox can do this,
maybe something with
On Friday 01 July 2005 20:11, Brian D. Harring wrote:
Regarding the require whatever is used to uncompress the source,
hadn't thought about it, but that _should_ be specified imo. That's
also being a bit anal, but frankly, if the resolver can handle it, why
shouldn't we specify the full deps?
On Fri, Jul 01, 2005 at 02:30:12PM -0400, Mike Frysinger wrote:
On Friday 01 July 2005 02:11 pm, Brian D. Harring wrote:
Meanwhile, back to the you want us to add what?, our dependency
graph *is* incomplete.
so what ? i dont see it being a bug
I do. :)
We do a lot of work to have deps
On Fri, Jul 01, 2005 at 08:35:36PM +0200, Maurice van der Pot wrote:
If the point is to make dependencies complete, isn't there a way to
build in some support for detecting it into some tool or other?
If we have a program that can create an environment and detect which
programs are run
Full dependency information hasn't be viable due to resolver issues,
which will be fixed.
so why dont you come back once you have something that is supposed to work
?
you're proposing we start generating a ton of circular dependencies which
we
arent even close to handling
On Friday 01 July 2005 20:42, Brian D. Harring wrote:
Err... missing the point, and proving my point. Current portage
_will_ fail because it's an unstated dependency. Why shouldn't
portage be provided the deps it needs so it can figure out what is
needed to get to what the user requested?
On Fri, Jul 01, 2005 at 01:45:20PM -0500, Brian D. Harring wrote:
Not tenuable
What you're effectivelly suggesting is that portage stomp ahead and,
hit a failure, try and figure out what atom would fix the failure,
retry, wash rinse repeat.
No, I'm not talking about that. I'm talking
On Fri, Jul 01, 2005 at 08:53:18PM +0200, Diego 'Flameeyes' Pettenò wrote:
On Friday 01 July 2005 20:42, Brian D. Harring wrote:
Err... missing the point, and proving my point. Current portage
_will_ fail because it's an unstated dependency. Why shouldn't
portage be provided the deps it
On Fri, Jul 01, 2005 at 08:56:45PM +0200, Maurice van der Pot wrote:
On Fri, Jul 01, 2005 at 01:45:20PM -0500, Brian D. Harring wrote:
Not tenuable
What you're effectivelly suggesting is that portage stomp ahead and,
hit a failure, try and figure out what atom would fix the failure,
On Fri, Jul 01, 2005 at 02:12:07PM -0500, Brian D. Harring wrote:
Best solution in my opinion for such a tool is abuse of binpkgs +
chroot for testing, but that's beyond portage's focus, should be an
external tool.
This is why I was only talking about build dependencies.
A tool to do
On Friday 01 July 2005 20:53, Diego 'Flameeyes' Pettenò wrote:
On Friday 01 July 2005 20:42, Brian D. Harring wrote:
Err... missing the point, and proving my point. Current portage
_will_ fail because it's an unstated dependency. Why shouldn't
portage be provided the deps it needs so it
Mike Frysinger [EMAIL PROTECTED] wrote:
On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
Currently, we pretty much leave out the big dogs of build depends from
ebuilds- basically we rely on the profile to require a suitable
toolchain. Couple of issues with this though-
so what
On Jul 1, 2005, at 5:59 PM, Drake Wyrm wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
Currently, we pretty much leave out the big dogs of build depends
from
ebuilds- basically we rely on the profile to require a suitable
toolchain.
36 matches
Mail list logo
