On Thu, Oct 20, 2005 at 10:56:57PM -0400, Mike Frysinger wrote:
On Thursday 20 October 2005 10:49 pm, Dan Meltzer wrote:
Why single out this one? ones system will not break irreperbly
without a cxx compiler, it'll just cause a another recompile to get it
to work after breakage if the
Petteri Räty wrote:
Every once in a while I see people wanting to use nosomething use flags.
Why don't we have a package.use like we already have a package.mask
file? This would make it possible for developers to turn on use flags by
default in a way that would not cruft the base profiles for
Marius Mauch wrote:
Petteri Räty wrote:
Every once in a while I see people wanting to use nosomething use flags.
Why don't we have a package.use like we already have a package.mask
file? This would make it possible for developers to turn on use flags by
default in a way that would not cruft
Dave Nebinger posted [EMAIL PROTECTED],
excerpted below, on Thu, 20 Oct 2005 22:19:13 -0400:
i still dont see how this addresses the nocxx / USE=-*
noFOO is used because FOO is on by default, and noFOO turns it off.
AutoUSE is the same way, package bar is included in the buildplan and to
On Fri, 21 Oct 2005 04:37:16 -0700 Duncan [EMAIL PROTECTED] wrote:
| Also consider the case of media-libs/libsdl. It uses novideo,
| noaudio, and nojoystick, for the simple reason that for the vast
| majority of folks who'd have reason to merge the package, turning OFF
| that functionality makes
Petteri Räty wrote:
Marius Mauch wrote:
Gentoo being about choice the new package.use should come before
anything user set. I do not see any problem with this if it works in the
same way as package.mask already works. Please, enlighten me.
Because package.use is implemented in a very
On Fri, 2005-10-21 at 17:49 +0300, Marius Mauch wrote:
Petteri Räty wrote:
Marius Mauch wrote:
Gentoo being about choice the new package.use should come before
anything user set. I do not see any problem with this if it works in the
same way as package.mask already works. Please,
On Friday 21 October 2005 04:56, Mike Frysinger wrote:
On Thursday 20 October 2005 10:49 pm, Dan Meltzer wrote:
Why single out this one? ones system will not break irreperbly
without a cxx compiler, it'll just cause a another recompile to get it
to work after breakage if the person is
Duncan wrote:
Put another way... It is said over and over again that USE flags cover
OPTIONAL functionality. Few would consider video/audio/joystick support
in a library with a primary use of supporting games as optional. Rather,
the option would be to /not/ have support compiled in, and
On Friday 21 October 2005 02:44 am, Harald van Dijk wrote:
On Thu, Oct 20, 2005 at 10:56:57PM -0400, Mike Frysinger wrote:
On Thursday 20 October 2005 10:49 pm, Dan Meltzer wrote:
Why single out this one? ones system will not break irreperbly
without a cxx compiler, it'll just cause a
On Friday 21 October 2005 05:56 am, Marius Mauch wrote:
Petteri Räty wrote:
Every once in a while I see people wanting to use nosomething use flags.
Why don't we have a package.use like we already have a package.mask
file? This would make it possible for developers to turn on use flags by
On Friday 21 October 2005 01:23 pm, Michiel de Bruijne wrote:
On Friday 21 October 2005 04:56, Mike Frysinger wrote:
On Thursday 20 October 2005 10:49 pm, Dan Meltzer wrote:
Why single out this one? ones system will not break irreperbly
without a cxx compiler, it'll just cause a another
Now, that I've got your attention. IMHO above should NOT fail - most of
the software in portage is already using ${HOST}-gcc instead and gcc
symlink is just a convenience.
But it does. In packages I will never suspect being nasty (qt, lynx) and
ones I would, but they shouldn't (fuse)
What is so
On Friday 21 October 2005 11:12 pm, Tomasz Mloduchowski wrote:
I got sick of filling 3 almost identical bug reports
please stop doing this
we are already playing with doing this in the wrapper itself so that
compilation is transparent
i'd wager to say the majority of packages in portage run
Jason Stubbs wrote:
After thinking about it, incremental feature creep does seem like the best
way to go at this late stage in 2.0's life. The problem is how to guage what
is and what is not more trouble than worth. Perhaps adhering to the kernel's
rule of Separate each logical change into its
On Friday 21 October 2005 19:06, Marius Mauch wrote:
Jason Stubbs wrote:
After thinking about it, incremental feature creep does seem like the
best way to go at this late stage in 2.0's life. The problem is how to
guage what is and what is not more trouble than worth. Perhaps adhering
to
On Saturday 22 October 2005 10:08, Brian Harring wrote:
On Sat, Oct 22, 2005 at 12:14:40AM +0900, Jason Stubbs wrote:
On Friday 21 October 2005 19:06, Marius Mauch wrote:
Jason Stubbs wrote:
After thinking about it, incremental feature creep does seem like
the best way to go at this
On Sat, Oct 22, 2005 at 12:13:42PM +0900, Jason Stubbs wrote:
Something like:
* Add base class(es) for new cache framework
* Add cache backend for XYZ database
* Switch portdbapi to the new framework
* Remove old framework
eclass_cache.py chunking (portage.py removal)
cache replacement (base
18 matches
Mail list logo
