Re: [gentoo-dev] RFC: new project gentoo-extreme-security

2007-10-23 Thread Omer Cohen
On 10/22/07, Sune Kloppenborg Jeppesen [EMAIL PROTECTED] wrote:
 On Monday 22 October 2007 06:04:58 Donnie Berkholz wrote:
  On 01:42 Mon 22 Oct , Alexander Gabert wrote:
   this is a request for comments on a new project:
  
   http://www.gentoo.org/proj/en/extreme-security/
 This sounds interesting, though the project page is not very specific.

  I'm curious whether this would be better-placed as a subproject of
  either the security or hardened projects. Why do you think it would be
  better off independent?
 The Security Team as it stands now is mostly reactive and not proactive so I
 don't think it would fit very well as a sub project of security. Hardened is
 another matter.

 --
 Sune Kloppenborg Jeppesen (Jaervosz)
 Gentoo Linux Security Team
 http://security.gentoo.org
 --
 [EMAIL PROTECTED] mailing list



I live the way you put 'friendly' first :)

regarding the past posts about the existing security team, I'm
thinking this project is suposed to build up some suite of
applications and configurations to let the administrator control his
security settings in a more easy way.

imo this does not clash with the security team's purpose; this project
will that the security team's results and make it into a more frieldy
suite

I'd be more than happy to assist in this project, or the main security team.

-- 
Thanks,
Omer Cohen
www.omerc.net
[EMAIL PROTECTED]
-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Last rites: app-emacs/wanderlust-cvs

2007-10-23 Thread Ulrich Mueller
# Ulrich Mueller [EMAIL PROTECTED] (23 Oct 2007)
# Live CVS ebuild, masked for removal in 30 days.
# Use CVS snapshot in app-emacs/wanderlust as replacement.
app-emacs/wanderlust-cvs
-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-freebsd/freebsd-lib: ChangeLog freebsd-lib-6.2-r3.ebuild

2007-10-23 Thread Donnie Berkholz
On 12:02 Tue 23 Oct , Roy Marples (uberlord) wrote:
 1.1  sys-freebsd/freebsd-lib/freebsd-lib-6.2-r3.ebuild
 
 file : 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-freebsd/freebsd-lib/freebsd-lib-6.2-r3.ebuild?rev=1.1view=markup
 plain: 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-freebsd/freebsd-lib/freebsd-lib-6.2-r3.ebuild?rev=1.1content-type=text/plain

 PATCHES=${FILESDIR}/${PN}-bsdxml.patch
   ${FILESDIR}/${PN}-6.0-pmc.patch
   ${FILESDIR}/${PN}-6.0-gccfloat.patch
   ${FILESDIR}/${PN}-6.0-flex-2.5.31.patch
   ${FILESDIR}/${PN}-6.0-binutils-asm.patch
   ${FILESDIR}/${PN}-6.0-ssp.patch
   ${FILESDIR}/${PN}-6.1-csu.patch
   ${FILESDIR}/${PN}-6.2-bluetooth.patch
   ${FILESDIR}/${PN}-6.2-gcc41.patch
   ${FILESDIR}/${PN}-6.2-dl_iterate_phdr.patch
   ${FILESDIR}/${PN}-6.2-as-needed.patch
   ${FILESDIR}/${PN}-6.2-libthr.patch

Would it make this work with space-filled paths to single-quote each 
patch? I tried a quick test, and it looks like it would.

   # Add symlinks (- libthr) for legacy threading libraries, since these 
 are
   # not built by us (they are disabled in FreeBSD-7 anyway).
   dosym libthr.a /usr/lib/libpthread.a
   dosym libthr.so /usr/lib/libpthread.so
   dosym libthr.a /usr/lib/libc_r.a
   dosym libthr.so /usr/lib/libc_r.so
 
   # Add symlink (- libthr) so previously built binaries still work.
   dosym libthr.so.2 /lib/libpthread.so.2
   dosym libthr.so.2 /lib/libc_r.so.6
 
   # Compatibility symlinks to run FreeBSD 5.x binaries (ABI is mostly
   # identical, remove when problems will actually happen)
   dosym /lib/libc.so.6 /usr/lib/libc.so.5
   dosym /lib/libm.so.4 /usr/lib/libm.so.3

FreeBSD doesn't use get_libdir() ?

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-freebsd/freebsd-lib: ChangeLog freebsd-lib-6.2-r3.ebuild

2007-10-23 Thread Roy Marples

On Tue, 2007-10-23 at 10:24 -0700, Donnie Berkholz wrote:
 On 12:02 Tue 23 Oct , Roy Marples (uberlord) wrote:
  1.1  sys-freebsd/freebsd-lib/freebsd-lib-6.2-r3.ebuild
  
  file : 
  http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-freebsd/freebsd-lib/freebsd-lib-6.2-r3.ebuild?rev=1.1view=markup
  plain: 
  http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-freebsd/freebsd-lib/freebsd-lib-6.2-r3.ebuild?rev=1.1content-type=text/plain
 
  PATCHES=${FILESDIR}/${PN}-bsdxml.patch
  ${FILESDIR}/${PN}-6.0-pmc.patch
  ${FILESDIR}/${PN}-6.0-gccfloat.patch
  ${FILESDIR}/${PN}-6.0-flex-2.5.31.patch
  ${FILESDIR}/${PN}-6.0-binutils-asm.patch
  ${FILESDIR}/${PN}-6.0-ssp.patch
  ${FILESDIR}/${PN}-6.1-csu.patch
  ${FILESDIR}/${PN}-6.2-bluetooth.patch
  ${FILESDIR}/${PN}-6.2-gcc41.patch
  ${FILESDIR}/${PN}-6.2-dl_iterate_phdr.patch
  ${FILESDIR}/${PN}-6.2-as-needed.patch
  ${FILESDIR}/${PN}-6.2-libthr.patch
 
 Would it make this work with space-filled paths to single-quote each 
 patch? I tried a quick test, and it looks like it would.

Probably. I should fix that.

 FreeBSD doesn't use get_libdir() ?

FreeBSD has no concept of multilib as yet.

Thanks

Roy

-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Last rites: dev-java/jdbc2-stdext

2007-10-23 Thread Petteri Räty
# Petteri Räty [EMAIL PROTECTED] (23 Oct 2007)
# These classes are included in the JDK since 1.4
# Will be moved to Java overlays after a month
dev-java/jdbc2-stdext



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-plugins/compiz-fusion-plugins-main: compiz-fusion-plugins-main-0.6.0.ebuild metadata.xml ChangeLog Manifest

2007-10-23 Thread Petteri Räty
Hanno Boeck (hanno) kirjoitti:
 hanno   07/10/23 22:33:31
 
 S=${WORKDIR}/${P}

This is the default.

 
 src_compile() {
   econf `use_enable jpeg` || die econf failed
   emake || die make failed
 }

I think it's more common to use the $() syntax for use_enable.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-plugins/compiz-fusion-plugins-main: compiz-fusion-plugins-main-0.6.0.ebuild metadata.xml ChangeLog Manifest

2007-10-23 Thread Hanno Böck
Am Mittwoch 24 Oktober 2007 schrieb Petteri Räty:
 Hanno Boeck (hanno) kirjoitti:
  hanno   07/10/23 22:33:31
 
  S=${WORKDIR}/${P}

 This is the default.

  src_compile() {
  econf `use_enable jpeg` || die econf failed
  emake || die make failed
  }

 I think it's more common to use the $() syntax for use_enable.

I'll do it later today.

They seem to be good candidates for new repoman checks, as we probably have 
tons of them in the tree.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber: [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/compiz-bcop: metadata.xml Manifest compiz-bcop-0.6.0.ebuild ChangeLog

2007-10-23 Thread Donnie Berkholz
On 22:28 Tue 23 Oct , Hanno Boeck (hanno) wrote:
 1.1  x11-libs/compiz-bcop/compiz-bcop-0.6.0.ebuild
 
 file : 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-libs/compiz-bcop/compiz-bcop-0.6.0.ebuild?rev=1.1view=markup
 plain: 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-libs/compiz-bcop/compiz-bcop-0.6.0.ebuild?rev=1.1content-type=text/plain

 S=${WORKDIR}/${P}
 
 src_compile() {
   econf || die econf failed
   emake || die make failed
 }

Both S and src_compile() are the defaults, and this is not the only 
compiz ebuild committed today where that is the case.

Thanks,
Donnie
-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Last Rites - Oct 14th - 21st, 2007

2007-10-23 Thread Ryan Hill
Attached are the packages that have been scheduled for removal this week.
Sorry bout the wait.


-- 
  fonts / wxWindows / gcc-porting / treecleaners
  EFFD 380E 047A 4B51 D2BD  C64F 8AA8 8346 F9A4 0662 (0xF9A40662)
x11-misc/xcut  Krzysiek Pawlik [EMAIL PROTECTED]15 Nov 
2007
dev-util/portatosourceview Markus Ullmann [EMAIL PROTECTED]20 Nov 
2007
dev-php4/adodb-ext Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/creoleChristian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/eaccelerator  Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/ffmpeg-phpChristian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/jargonChristian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/jpgraph   Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/pecl-apc  Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/pecl-crackChristian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/pecl-fileinfo Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/pecl-http Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/pecl-id3  Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/pecl-imagick  Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/pecl-json Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/pecl-mailparseChristian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/pecl-memcache Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/pecl-pdflib   Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/pecl-ps   Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/pecl-radius   Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/pecl-sqlite   Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/pecl-tidy Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/pecl-translit Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/pecl-yaz  Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/pecl-zip  Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/phpdbgChristian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/php-java-bridge   Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/phpunit   Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/suhosin   Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/syck-php-bindings Christian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/xcacheChristian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/xdebugChristian Hoffmann [EMAIL PROTECTED]   Jan 2008
dev-php4/ZendOptimizer Christian Hoffmann [EMAIL PROTECTED]   Jan 2008

table

 tr
 thPackage:/th
 thRemoval date:/th
 thContact:/th
 /tr

tr
 tiuri link=http://packages.gentoo.org/packages/?category=x11-misc;name=xcut;x11-misc/xcut/uri/ti
 ti15 Nov 2007/ti
 timail link=[EMAIL PROTECTED]Krzysiek Pawlik/mail/ti
 /tr

tr
 tiuri link=http://packages.gentoo.org/packages/?category=dev-util;name=portatosourceview;dev-util/portatosourceview/uri/ti
 ti20 Nov 2007/ti
 timail link=[EMAIL PROTECTED]Markus Ullmann/mail/ti
 /tr

tr
 tiuri link=http://packages.gentoo.org/packages/?category=dev-php4;name=adodb-ext;dev-php4/adodb-ext/uri/ti
 tiJan 2008/ti
 timail link=[EMAIL PROTECTED]Christian Hoffmann/mail/ti
 /tr

tr
 tiuri link=http://packages.gentoo.org/packages/?category=dev-php4;name=creole;dev-php4/creole/uri/ti
 tiJan 2008/ti
 timail link=[EMAIL PROTECTED]Christian Hoffmann/mail/ti
 /tr

tr
 tiuri link=http://packages.gentoo.org/packages/?category=dev-php4;name=eaccelerator;dev-php4/eaccelerator/uri/ti
 tiJan 2008/ti
 timail link=[EMAIL PROTECTED]Christian Hoffmann/mail/ti
 /tr

tr
 tiuri link=http://packages.gentoo.org/packages/?category=dev-php4;name=ffmpeg-php;dev-php4/ffmpeg-php/uri/ti
 tiJan 2008/ti
 timail link=[EMAIL PROTECTED]Christian Hoffmann/mail/ti
 /tr

tr
 tiuri link=http://packages.gentoo.org/packages/?category=dev-php4;name=jargon;dev-php4/jargon/uri/ti
 tiJan 2008/ti
 timail link=[EMAIL PROTECTED]Christian Hoffmann/mail/ti
 /tr

tr
 tiuri link=http://packages.gentoo.org/packages/?category=dev-php4;name=jpgraph;dev-php4/jpgraph/uri/ti
 tiJan 2008/ti
 timail link=[EMAIL PROTECTED]Christian Hoffmann/mail/ti
 /tr

tr
 tiuri link=http://packages.gentoo.org/packages/?category=dev-php4;name=pecl-apc;dev-php4/pecl-apc/uri/ti
 tiJan 2008/ti
 timail link=[EMAIL PROTECTED]Christian Hoffmann/mail/ti
 /tr

tr
 tiuri link=http://packages.gentoo.org/packages/?category=dev-php4;name=pecl-crack;dev-php4/pecl-crack/uri/ti
 tiJan 2008/ti
 timail link=[EMAIL PROTECTED]Christian Hoffmann/mail/ti
 /tr

tr
 tiuri link=http://packages.gentoo.org/packages/?category=dev-php4;name=pecl-fileinfo;dev-php4/pecl-fileinfo/uri/ti
 tiJan 2008/ti
 timail link=[EMAIL PROTECTED]Christian Hoffmann/mail/ti
 /tr


Re: [gentoo-portage-dev] Re: About system and world

2007-10-23 Thread Marius Mauch
On Mon, 22 Oct 2007 21:29:02 -0700
Zac Medico [EMAIL PROTECTED] wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Ryan Hill wrote:
  Zac Medico wrote:
  implement greedy atoms for the world set. I've been pondering the
  idea of making world non-greedy for slots by default [1], since you
  can add slot atoms to the world file to pull in any specific
  slot(s) that you want.
  
  That would rock.  Portage always insisting on pulling in the highest
  SLOT whether needed or not is one of my biggest pet-peeves.
 
 Well, you can already use SLOT atoms in your world file if you don't
 want the highest available. Packages that pull in =foo are a
 different story though. I suppose we can add something like a
 - --upgrade=minimal option that prevents pulling in new slots if they
 aren't required.

Don't restrict it to SLOTs though. minimal implies that only upgrades
required to satisfy the depgraph are performed. The described
behavior should be another value, e.g. no-slot-change.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-portage-dev] About system and world

2007-10-23 Thread Marius Mauch
On Sun, 21 Oct 2007 15:12:31 +0200
Marius Mauch [EMAIL PROTECTED] wrote:

 Well, the primary goal is to make all sets behave in a consistent way.
 And some sets have the explicit purpose to rebuild stuff, so making
 sets selective by default also has issues.
 The proposed change would also make sets behave in the same way as
 packages which is IMO another benefit.

This actually has more consequences: selective is a global setting,
you can't enable it just for some arguments. Therefore if packages and
sets are treated differently it requires that they can't be mixed on
the commandline (and if we'd make the setting configurable for each set
then only one set can be used at any time). And right now I can't think
of another reason why that restriction would be necessary.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-portage-dev] Re: About system and world

2007-10-23 Thread Thomas de Grenier de Latour
On 2007/10/23, Marius Mauch [EMAIL PROTECTED] wrote:

 On Mon, 22 Oct 2007 21:29:02 -0700
 Zac Medico [EMAIL PROTECTED] wrote:
 
  Well, you can already use SLOT atoms in your world file if you don't
  want the highest available. Packages that pull in =foo are a
  different story though. I suppose we can add something like a
  - --upgrade=minimal option that prevents pulling in new slots if
  they aren't required.
 
 Don't restrict it to SLOTs though. minimal implies that only
 upgrades required to satisfy the depgraph are performed. 

Couldn't this minimal behavior just be triggered by lack of the
--upgrade option (emerge -D set)?

Actually, the current --upgrade behavior (with or without --deep)
is a bit weird imho, i would prefer something like this (with foo 
being either a set or an atom):

 * emerge foo: do the minimum upgrades or new installs required to
get foo satisfied.  Only its direct deps are checked (and direct
deps of the unsatisfied ones, etc.), with the minimal heuristic
(upgrade them only if stricly required).

 * emerge -u foo: do all required new installs and possible upgrades
of foo.  Only its direct deps are checked (and direct deps of the
unsatisfied ones, etc.), with the minimal heuristic (upgrade them only
if strictly needed).

 * emerge -D foo: do the minimal upgrades or new installs required to
get foo satisfied.  Also, check all of its direct and indirect deps,
with the minimal heuristic (upgrade only if strictly needed).

 * emerge -uD foo: do all required new installs and possible upgrades
of foo.  Also, all its direct and indirect deps are checked, and
upgraded where possible.


For those who wonder, and if i'm not mistaken, current behaviors of
this four combinations, expressed in those words, are:

 * emerge foo: do all required new installs and possible upgrades
of foo.  Only its direct deps are checked (and direct deps of the
unsatisfied ones, etc.), with the minimal heuristic (upgrade them 
only if strictly needed).  
  = same as my emerge -u foo

 * emerge -u foo: do all required new installs and possible upgrades
of foo and its direct deps.  Also, check all of their direct and
indirect deps, with the minimal heuristic (upgrade them only if
strictly needed).
  = i don't see usefulness of this special case.  Whether some code is
direct or indirect dep is often subject to some maintainer's choices,
and may vary with time (for instance, an internal lib of a big package
being splitted out as a separate dep of this package).

 * emerge -D foo and emerge -uD foo : do all required new installs
and possible upgrades of foo.  Also, all its direct and indirect deps
are checked, and upgraded where possible.
 = same as my emerge -uD foo.  But waste of one of the four options
combinations.


-- 
TGL.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-portage-dev] Re: About system and world

2007-10-23 Thread Marius Mauch
On Tue, 23 Oct 2007 21:11:48 +0200
Thomas de Grenier de Latour [EMAIL PROTECTED] wrote:

 On 2007/10/23, Marius Mauch [EMAIL PROTECTED] wrote:
 
  On Mon, 22 Oct 2007 21:29:02 -0700
  Zac Medico [EMAIL PROTECTED] wrote:
  
   Well, you can already use SLOT atoms in your world file if you
   don't want the highest available. Packages that pull in =foo are
   a different story though. I suppose we can add something like a
   - --upgrade=minimal option that prevents pulling in new slots if
   they aren't required.
  
  Don't restrict it to SLOTs though. minimal implies that only
  upgrades required to satisfy the depgraph are performed. 
 
 Couldn't this minimal behavior just be triggered by lack of the
 --upgrade option (emerge -D set)?

--upgrade != the current --update (at least that's what I assumed)

 Actually, the current --upgrade behavior (with or without --deep)
 is a bit weird imho, i would prefer something like this (with foo 
 being either a set or an atom):

Yes, --update has a history of being a mess of random behavior.
Personally I'd drop it completely, or alias it to --noreplace.

  * emerge foo: do the minimum upgrades or new installs required to
 get foo satisfied.  Only its direct deps are checked (and direct
 deps of the unsatisfied ones, etc.), with the minimal heuristic
 (upgrade them only if stricly required).
 
  * emerge -u foo: do all required new installs and possible upgrades
 of foo.  Only its direct deps are checked (and direct deps of the
 unsatisfied ones, etc.), with the minimal heuristic (upgrade them
 only if strictly needed).
 
  * emerge -D foo: do the minimal upgrades or new installs required
 to get foo satisfied.  Also, check all of its direct and indirect
 deps, with the minimal heuristic (upgrade only if strictly needed).
 
  * emerge -uD foo: do all required new installs and possible
 upgrades of foo.  Also, all its direct and indirect deps are checked,
 and upgraded where possible.
 
Maybe --upgrade as name was an unfortunate choice, --resolver might be
better. What I'd like ideally (as a user) is to replace --update,
--deep, --noreplace and --emptytree with the following options:

--resolver={minimal,noslotchange,leastchange,default}
minimal: select the lowest possible version
noslotchange: like default, but try to avoid slotchanges
leastchange: select the version with the smallest version delta
compared to the installed version, otherwise like default
default: current behavior

--rebuild={never,always,changeduse,newuse,changeddeps,selected}
never: never rebuild packages
always: always rebuild packages (like current --emtpytree)
changeduse: rebuild packages if $USE has changed
newuse: rebuild packages if $USE or $IUSE has changed
changeddeps: rebuild packages if any of its direct dependencies were
updated
selected: rebuild the selected arguments (root nodes)

--deplevel=n
check n level of dependencies for updates (with -1 == infinite)
of course all dependencies have to be satisfied, this controls only
what deps should be checked for optional updates

current defaults would be --resolver=default --rebuild=selected
--deplevel=0

--update would be --rebuild=never --deplevel=1
--deep would be --deplevel=-1
--emptytree would be --rebuild=always --deplevel=-1

But that's just me dreaming of a better world, where we don't have
to deal with legacies ;)

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-portage-dev] Re: About system and world

2007-10-23 Thread Marius Mauch
On Wed, 24 Oct 2007 00:03:47 +0200
Thomas de Grenier de Latour [EMAIL PROTECTED] wrote:

 Bah, you're introducing a new options set, and have (i think) ways to
 emulate all of the old ones with them, so what is stopping you?  You
 would just have to forbid mixes of old style and new style on the same
 command line.

Mainly the work required to implement it ;) And I'd rather finish
dynoparse first so it can be used here.
Oh, and ideally the mentioned values wouldn't be hardcoded lists, but
come from a pluggable resolver system, but that probably counts as
overengineering.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature