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 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
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.
Let me explain for example:
for a bit of time we had make -> gmake al
On Sat, 2005-07-09 at 14:46 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Saturday 09 July 2005 14:41, Martin Schlemmer wrote:
> > Sure thing - YOU then go through the tree and change all instances of
> > 'make' ...
> Seems like the point is not taken.. I'm not saying to replace all of them
> *now*
On Saturday 09 July 2005 14:41, Martin Schlemmer wrote:
> Sure thing - YOU then go through the tree and change all instances of
> 'make' ...
Seems like the point is not taken.. I'm not saying to replace all of them
*now* but just when we'll keyword stuff.
--
Diego "Flameeyes" Pettenò
Gentoo Deve
On Sat, 2005-07-09 at 14:08 +0200, Diego 'Flameeyes' Pettenò 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 it will expan
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 w
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 it will expand if this gets in as 'policy' or whatever), and
> hope to guess right when t
On Sat, 2005-07-09 at 13:45 +0200, Diego 'Flameeyes' Pettenò wrote:
> 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 installe
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 sys
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
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 sta
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 explicit about its dependency.
And this let me think: we'll be able soone
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 cr
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 Monday 04 July 2005 09:18, Brian D. Harring wrote:
> 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/foam
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, BDE
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 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
mach
On Thursday 07 July 2005 21:44, Kito wrote:
> This is what I've been doing with the experimental Darwin stages as
> nearly every basesystem package has circular deps...
Same with G/FBSD.
--
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Ge
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
them
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
Descript
On Wed, 2005-07-06 at 12:08 -0500, Brian D. Harring wrote:
> >
> > > Some of us think we can't start now, others think we can. I was under the
> > > impression from ferringb that we could.
> > >
> >
> > BDEPEND should be fine to start now depending on faith.
> Not after having it rolled into th
Clarification, mixture of the emails I haven't responded to addressed
here (further, sorry for the delay, didn't think the thread would go
any further while I was offline for birthdays/4th of july stuff)...
On Wed, Jul 06, 2005 at 04:39:14AM +0200, Martin Schlemmer wrote:
> On Tue, 2005-07-05 at
On Tue, 2005-07-05 at 20:59 -0500, Brian Jackson wrote:
> Martin Schlemmer wrote:
>
> >>
> >>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,
Martin Schlemmer wrote:
>>
>>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 thi
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 leav
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 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 require a sui
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
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
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
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-
>
>
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 s
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 an
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 fail
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 dep
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 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?
> > > 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 cl
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 w
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 hav
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
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 LD_PRELO
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
> Something like 600 ebuilds in the tree state a
> dependency on gcc- we have 19000 ebuilds. Not all require
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
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 w
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 peo
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) Mergin
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
50 matches
Mail list logo
