Stephen Hahn writes:
> * S h i v <[EMAIL PROTECTED]> [2007-11-15 03:01]:
> > If a distro needs to remove unneeded parts, they need to essentially
> > maintain their own ON tree.
>
> This point is distinct: a hypothetical distro's desire to
> amortize its own costs for customization across the
On Nov 15, 2007 8:46 AM, Stephen Hahn <[EMAIL PROTECTED]> wrote:
> * S h i v <[EMAIL PROTECTED]> [2007-11-15 03:01]:
> > If a distro needs to remove unneeded parts, they need to essentially
> > maintain their own ON tree.
>
> This point is distinct: a hypothetical distro's desire to
> amortize
* S h i v <[EMAIL PROTECTED]> [2007-11-15 03:01]:
> If a distro needs to remove unneeded parts, they need to essentially
> maintain their own ON tree.
This point is distinct: a hypothetical distro's desire to
amortize its own costs for customization across the participants in
a consolidatio
On Nov 14, 2007 3:50 AM, James Carlson <[EMAIL PROTECTED]> wrote:
> Richard Lowe writes:
> > Stephen Hahn <[EMAIL PROTECTED]> writes:
> > > 2. It's always possible to take stuff *out* of ON. Alan B and I
> > > would be happy to help someone trying to move/upgrade Perl in
> > > SFW,
> > That doesn't mean coreutils in SFW. I suppose it *could* be done that
> > way, with a bit of help, but the underlying point is that much of what
> > is in ON doesn't much belong there, as it has no real tie to
> > consolidation, and could just as effectively be built atop.
>
> It could
James Carlson <[EMAIL PROTECTED]> writes:
> Richard Lowe writes:
>> Stephen Hahn <[EMAIL PROTECTED]> writes:
>> > 2. It's always possible to take stuff *out* of ON. Alan B and I
>> > would be happy to help someone trying to move/upgrade Perl in
>> > SFW, which could result in one o
Richard Lowe writes:
> Stephen Hahn <[EMAIL PROTECTED]> writes:
> > 2. It's always possible to take stuff *out* of ON. Alan B and I
> > would be happy to help someone trying to move/upgrade Perl in
> > SFW, which could result in one or both Perl versions in ON being
> > delete
Stephen Hahn <[EMAIL PROTECTED]> writes:
> Darren and James raise good questions. I'll add two other points:
>
> 1. There's an effort to speed ON build performance going on already.
> Search for mail messages from Alexander Kolbasov (akolb). You may
> wish to see what issues the
Darren and James raise good questions. I'll add two other points:
1. There's an effort to speed ON build performance going on already.
Search for mail messages from Alexander Kolbasov (akolb). You may
wish to see what issues they've encountered with Makefile
manipulation
S h i v wrote:
> The current ON is one monolithic piece. The Makefile structure does
> not provide any mechanism to customize (add/remove) items at build
> time. Either the entire stuff is in, or entire stuff is out.
>
> I would like to ask if there would be any interest in refactoring the
> curre
S h i v writes:
> I would like to ask if there would be any interest in refactoring the
> current build mechanism to allow for discovering what all options are
> available and to configure the same. Something on the lines of
> menuconfig of linux kernel. This I believe allows for people to
Ick.
W
The current ON is one monolithic piece. The Makefile structure does
not provide any mechanism to customize (add/remove) items at build
time. Either the entire stuff is in, or entire stuff is out.
I would like to ask if there would be any interest in refactoring the
current build mechanism to allow
12 matches
Mail list logo
