[gentoo-dev] macos mess

[gentoo-dev] macos mess

[Michael Sterrett -Mr. Bones.-]

The repoman output generated from the macos keywording is getting out of hand.
Something needs to be done to address this soon:

app-admin/makepasswd/makepasswd-1.10.ebuild: macos ['dev-lang/perl']    app-admin/passook/passook-1.0.0.ebuild: macos ['sys-apps/grep', 'sys-apps/miscfiles', 'dev-lang/perl']
app-admin/passook/passook-1.0.0.ebuild: macos ['sys-apps/grep', 'sys-apps/miscfiles', 'sys-devel/patch', 'dev-lang/perl']
app-editors/nano/nano-1.3.3-r1.ebuild: macos ['sys-devel/patch']
app-emacs/apel/apel-10.6.ebuild: macos ['app-editors/emacs']    app-emacs/flim/flim-1.14.6.ebuild: macos ['app-editors/emacs']    app-emacs/limit/limit-1.14.8_pre20040415.ebuild: macos ['app-editors/emacs']
app-emacs/riece/riece-1.0.1.ebuild: macos ['app-editors/emacs']    app-emacs/semi/semi-1.14.6.ebuild: macos ['app-editors/emacs']    app-emacs/wanderlust/wanderlust-2.10.1-r2.ebuild: macos ['app-editors/emacs', 'sys-devel/patch']
app-emacs/wanderlust/wanderlust-2.10.1-r2.ebuild: macos ['app-editors/emacs']   app-emacs/wanderlust/wanderlust-2.11.30_pre20040618.ebuild: ~macos ['app-editors/emacs']
app-i18n/skk-jisyo/skk-jisyo-200407.ebuild: macos ['app-arch/gzip']    app-portage/gentoolkit-dev/gentoolkit-dev-0.2.0_pre3.ebuild: macos ['>=dev-lang/python-2.0', '>=sys-apps/grep-2.4', '>=sys-apps/portage-2.0.50', '>=dev-lang/perl-5.6']    app-portage/gentoolkit/gentoolkit-0.2.0_pre8.ebuild: macos ['>=dev-lang/python-2.0', '>=sys-apps/grep-2.4', '>=sys-apps/portage-2.0.50', '>=dev-lang/perl-5.6']
app-portage/splat/splat-0.08.ebuild: macos ['dev-lang/perl']
app-text/dos2unix/dos2unix-3.1.ebuild: macos ['sys-devel/patch']
app-text/htmltidy/htmltidy-3.10.29.ebuild: macos ['>=sys-devel/autoconf-2.5', '>=sys-devel/automake-1.5', 'sys-devel/patch']
app-text/migemo/migemo-0.40-r1.ebuild: macos ['dev-lang/ruby', 'app-editors/emacs']    app-text/migemo/migemo-0.40-r1.ebuild: macos ['dev-lang/ruby']
app-text/unix2dos/unix2dos-2.2.ebuild: macos ['sys-devel/patch', 'sys-devel/gcc']    dev-lang/swi-prolog-lite/swi-prolog-lite-5.3.14.ebuild: macos ['sys-apps/sed', 'sys-apps/gawk']    dev-libs/glib/glib-2.4.4.ebuild: ~macos ['sys-devel/libtool']
dev-python/readline/readline-2.3.3.ebuild: macos ['>=dev-lang/python-2.3.3']    dev-ruby/ruby-bsearch/ruby-bsearch-1.5-r1.ebuild: macos ['dev-lang/ruby', 'sys-devel/patch']    dev-ruby/ruby-bsearch/ruby-bsearch-1.5-r1.ebuild: macos ['dev-lang/ruby']
dev-ruby/ruby-romkan/ruby-romkan-0.4-r1.ebuild: macos ['dev-lang/ruby', 'sys-devel/patch']
dev-ruby/ruby-romkan/ruby-romkan-0.4-r1.ebuild: macos ['dev-lang/ruby']
dev-util/dialog/dialog-0.9_beta20031207.ebuild: macos ['>=app-shells/bash-2.04-r3', 'sys-devel/patch']
dev-util/dialog/dialog-0.9_beta20031207.ebuild: macos ['>=app-shells/bash-2.04-r3']
mail-client/mutt/mutt-1.5.6-r2.ebuild: macos ['sys-devel/automake', 'sys-devel/autoconf', 'sys-libs/gdbm', 'sys-devel/patch', '>=dev-libs/openssl-0.9.6']
media-libs/audiofile/audiofile-0.2.6-r1.ebuild: macos ['sys-devel/libtool', 'sys-devel/patch']
media-libs/freetype/freetype-2.1.5-r1.ebuild: macos ['sys-libs/zlib', 'sys-devel/patch']
media-libs/freetype/freetype-2.1.5-r1.ebuild: macos ['sys-libs/zlib']
media-libs/freetype/freetype-2.1.5.ebuild: macos ['sys-libs/zlib', 'sys-devel/patch']
media-libs/freetype/freetype-2.1.5.ebuild: macos ['sys-libs/zlib']
media-libs/libid3tag/libid3tag-0.15.1b.ebuild: macos ['>=sys-libs/zlib-1.1.3']
media-libs/libpng/libpng-1.2.5-r7.ebuild: macos ['sys-libs/zlib', 'sys-devel/patch', 'sys-devel/gcc']
media-libs/libpng/libpng-1.2.5-r7.ebuild: macos ['sys-libs/zlib']
media-sound/esound/esound-0.2.34.ebuild: ~macos ['>=sys-apps/tcp-wrappers-7.6-r2', '>=media-libs/alsa-lib-0.5.10b']
media-sound/esound/esound-0.2.34.ebuild: ~macos ['sys-devel/libtool', '>=sys-apps/tcp-wrappers-7.6-r2', '>=media-libs/alsa-lib-0.5.10b', 'sys-devel/patch']
media-sound/lame/lame-3.96.ebuild: macos ['=x11-libs/gtk+-1.2*', 'sys-devel/patch', 'sys-devel/gcc']
media-sound/lame/lame-3.96.ebuild: macos ['=x11-libs/gtk+-1.2*']
media-sound/madplay/madplay-0.15.2b.ebuild: macos ['media-sound/esound']
net-analyzer/darkstat/darkstat-2.6-r1.ebuild: macos ['>=net-libs/libpcap-0.7.1', 'sys-devel/patch']
net-analyzer/netperf/netperf-2.2.4.ebuild: macos ['>=sys-apps/sed-4']
net-libs/libwww/libwww-5.4.0-r2.ebuild: macos ['>=dev-libs/openssl-0.9.6', 'dev-lang/perl', '>=sys-devel/autoconf-2.13', 'sys-devel/patch', '>=sys-libs/zlib-1.1.4', '>=dev-db/mysql-3.23.26']
net-libs/libwww/libwww-5.4.0-r2.ebuild: macos ['>=sys-libs/zlib-1.1.4', '>=dev-db/mysql-3.23.26', '>=dev-libs/openssl-0.9.6', 'dev-lang/perl']
net-misc/wget/wget-1.9.1-r2.ebuild: macos ['>=dev-libs/openssl-0.9.6b']
net-misc/wget/wget-1.9.1-r2.ebuild: macos ['sys-devel/autoconf', 'sys-devel/patch']
net-www/links/links-2.1_pre15.ebuild: macos ['>=dev-libs/openssl-0.9.6c', '>=media-libs/svgalib-1.4.3', 'sys-libs/gpm', '>=media-libs/tiff-3.5.7', 'sys-libs/zlib', 'sys-darwin/X11', '>=sys-devel/flex-2.5.4a', '>=media-libs/jpeg-6b', 'dev-libs/DirectFB']
net-www/links/links-2.1_pre15.ebuild: macos ['>=dev-libs/openssl-0.9.6c', '>=media-libs/svgalib-1.4.3', 'sys-libs/gpm', '>=media-libs/tiff-3.5.7', 'sys-libs/zlib', 'sys-darwin/X11', 'sys-devel/automake', '>=sys-devel/flex-2.5.4a', '>=media-libs/jpeg-6b', 'dev-libs/DirectFB', 'sys-devel/autoconf', 'sys-devel/gcc']
net-www/lynx/lynx-2.8.5.ebuild: macos ['>=sys-libs/zlib-1.1.3', '>=dev-libs/openssl-0.9.6']
sys-devel/gettext/gettext-0.12.1-r1.ebuild: macos ['sys-devel/patch']
sys-devel/gnuconfig/gnuconfig-20040214.ebuild: macos ['sys-devel/patch']
sys-libs/readline/readline-4.3-r6.ebuild: macos ['>=app-shells/bash-2.05b-r2', 'sys-devel/patch']
sys-libs/readline/readline-4.3-r6.ebuild: macos ['>=app-shells/bash-2.05b-r2']
x11-wm/fluxbox/fluxbox-0.9.9.ebuild: macos ['sys-darwin/X11', '>=sys-devel/autoconf-2.52', 'sys-devel/patch']
x11-wm/fluxbox/fluxbox-0.9.9.ebuild: macos ['sys-darwin/X11']

Michael Sterrett
  -Mr. Bones.-
mr_bones_@gentoo.org

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Pieter Van den Abeele]

Hi,

There are two types of Gentoo MacOS users: There is the user who wants 
to extend his Mac OS X system with packages that didn't came 
pre-installed (like tetex, kde, mysql, prolog, ,... ) Then there's the 
user who wants to use Gentoo to rebuild parts of his Mac OS X operating 
system (a new kernel, python with readline support, ...) or just build 
a Darwin system from scratch without the fancy Apple stuff.

Several devs work on making Gentoo MacOS work for both users. 
Everything happens in parallel.

Why does repoman/linux think the dependency graph for macos is broken? 
Developers that work for users of the first type, keyword packages 
against a virtual base system. The entire base system (all packages 
provided by apple) is injected into the depgraph and locked down by a 
profile. A user cannot upgrade or downgrade Apple provided stuff, 
unless the user really insists on doing so. Repoman on linux complains 
about broken macos depgraph because the macos base system obviously 
isn't injected into the depgraph under linux.

There are some ways to make repoman not complain about macos:


1. make repoman not do macos QA under linux

Since repoman doesn't complain about macos under macos (it must be 
broken or somehow take into account injected packages when doing 
--emptytree), I prefer this option. It's also the least amount of work.


2. make repoman macos aware

This requires new portage features. Adding another file to the 
profiles, I can think of at least 2 portage feature requests that 
require adding another file to the profiles, so this can't be a short 
term solution.
Opened a bug about persistent injected packages. (Also needed to make 
--emptytree work on macos, since --emptytree also removes the injected 
base system).


3. add empty ebuilds keyworded "-* macos" for everything that gets 
injected.

Requires 300 empty ebuilds to be added for each macos profile. This is 
a hack around a portage bug that prevents a package from being purely 
virtual. There needs to be at least an empty ebuild.
The problem with the workaround is that if a linux user uses the 
'ignore keywords' syntax: emerge ./macos.ebuild that will break their 
system.


4. change every ebuild that depends on the macos base system by making 
the base system dependencies conditional.

How many ebuilds depend on 300 ebuilds? How many dependencies need to 
be changed per ebuild? What about base system evolution?


Best regards,

Pieter Van den Abeele




On 24 Jul 2004, at 13:34, Michael Sterrett -Mr. Bones.- wrote:

> The repoman output generated from the macos keywording is getting out 
> of hand.
> Something needs to be done to address this soon:
>
> app-admin/makepasswd/makepasswd-1.10.ebuild: macos ['dev-lang/perl']   
>  app-admin/passook/passook-1.0.0.ebuild: macos ['sys-apps/grep', 
> 'sys-apps/miscfiles', 'dev-lang/perl']
> app-admin/passook/passook-1.0.0.ebuild: macos ['sys-apps/grep', 
> 'sys-apps/miscfiles', 'sys-devel/patch', 'dev-lang/perl']
> app-editors/nano/nano-1.3.3-r1.ebuild: macos ['sys-devel/patch']
> app-emacs/apel/apel-10.6.ebuild: macos ['app-editors/emacs']    
> app-emacs/flim/flim-1.14.6.ebuild: macos ['app-editors/emacs']    
> app-emacs/limit/limit-1.14.8_pre20040415.ebuild: macos 
> ['app-editors/emacs']
> app-emacs/riece/riece-1.0.1.ebuild: macos ['app-editors/emacs']    
> app-emacs/semi/semi-1.14.6.ebuild: macos ['app-editors/emacs']    
> app-emacs/wanderlust/wanderlust-2.10.1-r2.ebuild: macos 
> ['app-editors/emacs', 'sys-devel/patch']
> app-emacs/wanderlust/wanderlust-2.10.1-r2.ebuild: macos 
> ['app-editors/emacs']   
> app-emacs/wanderlust/wanderlust-2.11.30_pre20040618.ebuild: ~macos 
> ['app-editors/emacs']
> app-i18n/skk-jisyo/skk-jisyo-200407.ebuild: macos ['app-arch/gzip']    
> app-portage/gentoolkit-dev/gentoolkit-dev-0.2.0_pre3.ebuild: macos 
> ['>=dev-lang/python-2.0', '>=sys-apps/grep-2.4', 
> '>=sys-apps/portage-2.0.50', '>=dev-lang/perl-5.6']    
> app-portage/gentoolkit/gentoolkit-0.2.0_pre8.ebuild: macos 
> ['>=dev-lang/python-2.0', '>=sys-apps/grep-2.4', 
> '>=sys-apps/portage-2.0.50', '>=dev-lang/perl-5.6']
> app-portage/splat/splat-0.08.ebuild: macos ['dev-lang/perl']
> app-text/dos2unix/dos2unix-3.1.ebuild: macos ['sys-devel/patch']
> app-text/htmltidy/htmltidy-3.10.29.ebuild: macos 
> ['>=sys-devel/autoconf-2.5', '>=sys-devel/automake-1.5', 
> 'sys-devel/patch']
> app-text/migemo/migemo-0.40-r1.ebuild: macos ['dev-lang/ruby', 
> 'app-editors/emacs']    app-text/migemo/migemo-0.40-r1.ebuild: macos 
> ['dev-lang/ruby']
> app-text/unix2dos/unix2dos-2.2.ebuild: macos ['sys-devel/patch', 
> 'sys-devel/gcc']    
> dev-lang/swi-prolog-lite/swi-prolog-lite-5.3.14.ebuild: macos 
> ['sys-apps/sed', 'sys-apps/gawk']    dev-libs/glib/glib-2.4.4.ebuild: 
> ~macos ['sys-devel/libtool']
> dev-python/readline/readline-2.3.3.ebuild: macos 
> ['>=dev-lang/python-2.3.3']    
> dev-ruby/ruby-bsearch/ruby-bsearch-1.5-r1.ebuild: macos 
> ['dev-lang/ruby', 'sys-devel/patch']    
> dev-ruby/ruby-bsearch/ruby-bsearch-1.5-r1.ebuild: macos 
> ['dev-lang/ruby']
> dev-ruby/ruby-romkan/ruby-romkan-0.4-r1.ebuild: macos 
> ['dev-lang/ruby', 'sys-devel/patch']
> dev-ruby/ruby-romkan/ruby-romkan-0.4-r1.ebuild: macos ['dev-lang/ruby']
> dev-util/dialog/dialog-0.9_beta20031207.ebuild: macos 
> ['>=app-shells/bash-2.04-r3', 'sys-devel/patch']
> dev-util/dialog/dialog-0.9_beta20031207.ebuild: macos 
> ['>=app-shells/bash-2.04-r3']
> mail-client/mutt/mutt-1.5.6-r2.ebuild: macos ['sys-devel/automake', 
> 'sys-devel/autoconf', 'sys-libs/gdbm', 'sys-devel/patch', 
> '>=dev-libs/openssl-0.9.6']
> media-libs/audiofile/audiofile-0.2.6-r1.ebuild: macos 
> ['sys-devel/libtool', 'sys-devel/patch']
> media-libs/freetype/freetype-2.1.5-r1.ebuild: macos ['sys-libs/zlib', 
> 'sys-devel/patch']
> media-libs/freetype/freetype-2.1.5-r1.ebuild: macos ['sys-libs/zlib']
> media-libs/freetype/freetype-2.1.5.ebuild: macos ['sys-libs/zlib', 
> 'sys-devel/patch']
> media-libs/freetype/freetype-2.1.5.ebuild: macos ['sys-libs/zlib']
> media-libs/libid3tag/libid3tag-0.15.1b.ebuild: macos 
> ['>=sys-libs/zlib-1.1.3']
> media-libs/libpng/libpng-1.2.5-r7.ebuild: macos ['sys-libs/zlib', 
> 'sys-devel/patch', 'sys-devel/gcc']
> media-libs/libpng/libpng-1.2.5-r7.ebuild: macos ['sys-libs/zlib']
> media-sound/esound/esound-0.2.34.ebuild: ~macos 
> ['>=sys-apps/tcp-wrappers-7.6-r2', '>=media-libs/alsa-lib-0.5.10b']
> media-sound/esound/esound-0.2.34.ebuild: ~macos ['sys-devel/libtool', 
> '>=sys-apps/tcp-wrappers-7.6-r2', '>=media-libs/alsa-lib-0.5.10b', 
> 'sys-devel/patch']
> media-sound/lame/lame-3.96.ebuild: macos ['=x11-libs/gtk+-1.2*', 
> 'sys-devel/patch', 'sys-devel/gcc']
> media-sound/lame/lame-3.96.ebuild: macos ['=x11-libs/gtk+-1.2*']
> media-sound/madplay/madplay-0.15.2b.ebuild: macos 
> ['media-sound/esound']
> net-analyzer/darkstat/darkstat-2.6-r1.ebuild: macos 
> ['>=net-libs/libpcap-0.7.1', 'sys-devel/patch']
> net-analyzer/netperf/netperf-2.2.4.ebuild: macos ['>=sys-apps/sed-4']
> net-libs/libwww/libwww-5.4.0-r2.ebuild: macos 
> ['>=dev-libs/openssl-0.9.6', 'dev-lang/perl', 
> '>=sys-devel/autoconf-2.13', 'sys-devel/patch', 
> '>=sys-libs/zlib-1.1.4', '>=dev-db/mysql-3.23.26']
> net-libs/libwww/libwww-5.4.0-r2.ebuild: macos 
> ['>=sys-libs/zlib-1.1.4', '>=dev-db/mysql-3.23.26', 
> '>=dev-libs/openssl-0.9.6', 'dev-lang/perl']
> net-misc/wget/wget-1.9.1-r2.ebuild: macos ['>=dev-libs/openssl-0.9.6b']
> net-misc/wget/wget-1.9.1-r2.ebuild: macos ['sys-devel/autoconf', 
> 'sys-devel/patch']
> net-www/links/links-2.1_pre15.ebuild: macos 
> ['>=dev-libs/openssl-0.9.6c', '>=media-libs/svgalib-1.4.3', 
> 'sys-libs/gpm', '>=media-libs/tiff-3.5.7', 'sys-libs/zlib', 
> 'sys-darwin/X11', '>=sys-devel/flex-2.5.4a', '>=media-libs/jpeg-6b', 
> 'dev-libs/DirectFB']
> net-www/links/links-2.1_pre15.ebuild: macos 
> ['>=dev-libs/openssl-0.9.6c', '>=media-libs/svgalib-1.4.3', 
> 'sys-libs/gpm', '>=media-libs/tiff-3.5.7', 'sys-libs/zlib', 
> 'sys-darwin/X11', 'sys-devel/automake', '>=sys-devel/flex-2.5.4a', 
> '>=media-libs/jpeg-6b', 'dev-libs/DirectFB', 'sys-devel/autoconf', 
> 'sys-devel/gcc']
> net-www/lynx/lynx-2.8.5.ebuild: macos ['>=sys-libs/zlib-1.1.3', 
> '>=dev-libs/openssl-0.9.6']
> sys-devel/gettext/gettext-0.12.1-r1.ebuild: macos ['sys-devel/patch']
> sys-devel/gnuconfig/gnuconfig-20040214.ebuild: macos 
> ['sys-devel/patch']
> sys-libs/readline/readline-4.3-r6.ebuild: macos 
> ['>=app-shells/bash-2.05b-r2', 'sys-devel/patch']
> sys-libs/readline/readline-4.3-r6.ebuild: macos 
> ['>=app-shells/bash-2.05b-r2']
> x11-wm/fluxbox/fluxbox-0.9.9.ebuild: macos ['sys-darwin/X11', 
> '>=sys-devel/autoconf-2.52', 'sys-devel/patch']
> x11-wm/fluxbox/fluxbox-0.9.9.ebuild: macos ['sys-darwin/X11']
>
> Michael Sterrett
>   -Mr. Bones.-
> mr_bones_@gentoo.org
>
> --
> gentoo-dev@gentoo.org mailing list
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Mike Frysinger]

On Saturday 24 July 2004 12:54 pm, Pieter Van den Abeele wrote:
> There are some ways to make repoman not complain about macos:

everything you described seems like a big old hack

why not update your profile to point all your 'virtual packages' at a real 
virtual package ... it  can be done with adding all your 300+ hacked entries 
to the virtuals file ... that should fix all the errors
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Travis Tilley]

repoman is currently a broken piece of shit and will probably remain so until 
after the pre14 release. #gentoo-dev is quite familiar with my complaining, 
and i cant seem to get repoman to work at all without some patching...

now if repoman successfully completes on macos but not anywhere else, i 
suggest the problem is probably similar to one i had and repoman is using 
mr_bones's current profile for macos when it shouldnt.

i would HIGHLY suggest everyone stop debating about how to make repoman handle 
macos and first try this patch: 
http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/bin/repoman?r1=1.69&r2=1.70&root=gentoo-src
if that doesnt help the situation any, feel free to ignore me and continue 
debating. :) however, that patch gets rid of a lot of the false positives i 
get on amd64... between that and one or two other patches, repoman is 
actually usable. go figure. maybe after pre14 i can stop complaining. ^_^

-- 

Travis Tilley <lv@gentoo.org>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Pieter Van den Abeele]

On 24 Jul 2004, at 18:59, Mike Frysinger wrote:

> On Saturday 24 July 2004 12:54 pm, Pieter Van den Abeele wrote:
>> There are some ways to make repoman not complain about macos:
>
> everything you described seems like a big old hack
>
> why not update your profile to point all your 'virtual packages' at a 
> real
> virtual package ... it  can be done with adding all your 300+ hacked 
> entries
> to the virtuals file ... that should fix all the errors

I didn't do that because that doesn't work.

Try adding

app-shells/bash	sys-libs/libsystem

to your profile virtuals, then try to emerge bash.

Best regards,

Pieter Van den Abeele


> -mike
>
> --
> gentoo-dev@gentoo.org mailing list
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Mike Frysinger]

On Saturday 24 July 2004 02:36 pm, Pieter Van den Abeele wrote:
> I didn't do that because that doesn't work.

i was refering to fixing repoman errors, and it does work for that

you already talked about how you hack around injecting the virtual packages, i 
dont really care about that
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Pieter Van den Abeele]

On 24 Jul 2004, at 20:36, Pieter Van den Abeele wrote:

>
> On 24 Jul 2004, at 18:59, Mike Frysinger wrote:
>
>> On Saturday 24 July 2004 12:54 pm, Pieter Van den Abeele wrote:
>>> There are some ways to make repoman not complain about macos:
>>
>> everything you described seems like a big old hack
>>
>> why not update your profile to point all your 'virtual packages' at a 
>> real
>> virtual package ... it  can be done with adding all your 300+ hacked 
>> entries
>> to the virtuals file ... that should fix all the errors
>
> I didn't do that because that doesn't work.
>
> Try adding
>
> app-shells/bash	sys-libs/libsystem
>
> to your profile virtuals, then try to emerge bash.

Also, how do versions come into play?

obviously emerge fakeA-1.0 would be realized by real-1.0 and fakeB-2.0 
would be realized by real-2.0. I don't think portage allows to specify 
some form of version-relation between a virtual and its realization, 
right? Like, libsystem-7.1 provides bash-3, xfree-435 , .... In portage 
.51_pre13, can the same package provides, multiple virtuals, each with 
an appropriate version.

Pieter




> Best regards,
>
> Pieter Van den Abeele


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Mike Frysinger]

On Saturday 24 July 2004 03:24 pm, Pieter Van den Abeele wrote:
> Also, how do versions come into play?

i'm not proposing a solution to people using macos, like i said, i dont care 
about that

i was giving a solution to the repoman crap that the macos KEYWORD has left in 
the tree
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Pieter Van den Abeele]

I've appended the packages.build file contents to the virtuals file 
content in the macos repoman profile (10.3).
Please let me know if repoman still complains.

Pieter

On 24 Jul 2004, at 21:30, Mike Frysinger wrote:

> On Saturday 24 July 2004 03:24 pm, Pieter Van den Abeele wrote:
>> Also, how do versions come into play?
>
> i'm not proposing a solution to people using macos, like i said, i 
> dont care
> about that
>
> i was giving a solution to the repoman crap that the macos KEYWORD has 
> left in
> the tree
> -mike
>
> --
> gentoo-dev@gentoo.org mailing list
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Pieter Van den Abeele]

Hi,

I've changed my mind. I'm not going to change the virtual file 
semantics in the MacOS profiles to get repoman to stop complaining. 
Instead I wrote a small (4 lines) patch for repoman which does the 
folowing:

When repoman detects a macos-specific unsatisfied dependency it will 
check the packages.build file, which on macos specifies the packages 
that are injected as base system. (Packages.build normally specifies 
what is in a stage1.) If the dependency is mentioned in that file, the 
dependency is considered satisfied.

I wasn't able to test the file because I couldn't get repoman to 
complain about macos on any of my linux systems in the first place. 
(sparc64, x86 and ppc, standard portage .51_pre13). Not sure why, but 
it ain't kosher. (My machines are on the net, feel free to ask for an 
account and investigate) Lv got his portage to complain about macos 
after patching it with the patch mentioned earlier in this thread.

http://www.metadistribution.org/gentoo/macos-support.patch for the 
untested patch, I hope it illustrates the idea.

Best regards,

Pieter Van den Abeele


On 24 Jul 2004, at 21:58, Pieter Van den Abeele wrote:

> I've appended the packages.build file contents to the virtuals file 
> content in the macos repoman profile (10.3).
> Please let me know if repoman still complains.
>
> Pieter
>
> On 24 Jul 2004, at 21:30, Mike Frysinger wrote:
>
>> On Saturday 24 July 2004 03:24 pm, Pieter Van den Abeele wrote:
>>> Also, how do versions come into play?
>>
>> i'm not proposing a solution to people using macos, like i said, i 
>> dont care
>> about that
>>
>> i was giving a solution to the repoman crap that the macos KEYWORD 
>> has left in
>> the tree
>> -mike
>>
>> --
>> gentoo-dev@gentoo.org mailing list
>>
>
>
> --
> gentoo-dev@gentoo.org mailing list
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Mike Frysinger]

On Saturday 24 July 2004 07:31 pm, Pieter Van den Abeele wrote:
> I've changed my mind. I'm not going to change the virtual file
> semantics in the MacOS profiles to get repoman to stop complaining.
> Instead I wrote a small (4 lines) patch for repoman which does the
> folowing:
>
> When repoman detects a macos-specific unsatisfied dependency it will
> check the packages.build file

that's a pretty ugly hack

are you suggesting we do this with every new random arch we add that isnt a 
standard linux port ?  seems like an unintuitive workaround

why not push something a little more intelligent ... perhaps a new file for 
portage to utilize in cases like this ... the profile has a special file 
where you can define packages that are assumed to be satisified
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Pieter Van den Abeele]

On 25 Jul 2004, at 01:56, Mike Frysinger wrote:

> are you suggesting we do this with every new random arch we add that 
> isnt a
> standard linux port ?

no

>  seems like an unintuitive workaround

it's so far the most clean and simplest solution to a problem, that can 
be removed when portage gets support for the featured integrated.
I've opened a bug a while ago and described it as 'persistent injected 
packages'.

> why not push something a little more intelligent ... perhaps a new 
> file for
> portage to utilize in cases like this ... the profile has a special 
> file
> where you can define packages that are assumed to be satisified

I won't push, I'll code.

Best regards,

Pieter Van den Abeele

> -mike
>
> --
> gentoo-dev@gentoo.org mailing list
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Joshua Brindle]

Here's a better idea..

How about we remove this macos junk from the tree and you can give your 
users an overlay tarball?
also sys-darwin and app-macos,  I never saw these categories come across 
the list for approval (though I might have missed it since I don't care 
about macos at all). Were these approved? If not they should be removed 
asap, I can't see any justification for making new categories for these 
programs (but as I already said I'd prefer this stuff not be in portage 
at all).

Joshua Brindle


Pieter Van den Abeele wrote:

> Hi,
>
> There are two types of Gentoo MacOS users: There is the user who wants 
> to extend his Mac OS X system with packages that didn't came 
> pre-installed (like tetex, kde, mysql, prolog, ,... ) Then there's the 
> user who wants to use Gentoo to rebuild parts of his Mac OS X 
> operating system (a new kernel, python with readline support, ...) or 
> just build a Darwin system from scratch without the fancy Apple stuff.
>
> Several devs work on making Gentoo MacOS work for both users. 
> Everything happens in parallel.
>
> Why does repoman/linux think the dependency graph for macos is broken? 
> Developers that work for users of the first type, keyword packages 
> against a virtual base system. The entire base system (all packages 
> provided by apple) is injected into the depgraph and locked down by a 
> profile. A user cannot upgrade or downgrade Apple provided stuff, 
> unless the user really insists on doing so. Repoman on linux complains 
> about broken macos depgraph because the macos base system obviously 
> isn't injected into the depgraph under linux.
>
> There are some ways to make repoman not complain about macos:
>
>
> 1. make repoman not do macos QA under linux
>
> Since repoman doesn't complain about macos under macos (it must be 
> broken or somehow take into account injected packages when doing 
> --emptytree), I prefer this option. It's also the least amount of work.
>
>
> 2. make repoman macos aware
>
> This requires new portage features. Adding another file to the 
> profiles, I can think of at least 2 portage feature requests that 
> require adding another file to the profiles, so this can't be a short 
> term solution.
> Opened a bug about persistent injected packages. (Also needed to make 
> --emptytree work on macos, since --emptytree also removes the injected 
> base system).
>
>
> 3. add empty ebuilds keyworded "-* macos" for everything that gets 
> injected.
>
> Requires 300 empty ebuilds to be added for each macos profile. This is 
> a hack around a portage bug that prevents a package from being purely 
> virtual. There needs to be at least an empty ebuild.
> The problem with the workaround is that if a linux user uses the 
> 'ignore keywords' syntax: emerge ./macos.ebuild that will break their 
> system.
>
>
> 4. change every ebuild that depends on the macos base system by making 
> the base system dependencies conditional.
>
> How many ebuilds depend on 300 ebuilds? How many dependencies need to 
> be changed per ebuild? What about base system evolution?
>
>
> Best regards,
>
> Pieter Van den Abeele
>
>
>
>
> On 24 Jul 2004, at 13:34, Michael Sterrett -Mr. Bones.- wrote:
>
>> The repoman output generated from the macos keywording is getting out 
>> of hand.
>> Something needs to be done to address this soon:
>>
>> app-admin/makepasswd/makepasswd-1.10.ebuild: macos 
>> ['dev-lang/perl']    app-admin/passook/passook-1.0.0.ebuild: macos 
>> ['sys-apps/grep', 'sys-apps/miscfiles', 'dev-lang/perl']
>> app-admin/passook/passook-1.0.0.ebuild: macos ['sys-apps/grep', 
>> 'sys-apps/miscfiles', 'sys-devel/patch', 'dev-lang/perl']
>> app-editors/nano/nano-1.3.3-r1.ebuild: macos ['sys-devel/patch']
>> app-emacs/apel/apel-10.6.ebuild: macos ['app-editors/emacs']    
>> app-emacs/flim/flim-1.14.6.ebuild: macos ['app-editors/emacs']    
>> app-emacs/limit/limit-1.14.8_pre20040415.ebuild: macos 
>> ['app-editors/emacs']
>> app-emacs/riece/riece-1.0.1.ebuild: macos ['app-editors/emacs']    
>> app-emacs/semi/semi-1.14.6.ebuild: macos ['app-editors/emacs']    
>> app-emacs/wanderlust/wanderlust-2.10.1-r2.ebuild: macos 
>> ['app-editors/emacs', 'sys-devel/patch']
>> app-emacs/wanderlust/wanderlust-2.10.1-r2.ebuild: macos 
>> ['app-editors/emacs']   
>> app-emacs/wanderlust/wanderlust-2.11.30_pre20040618.ebuild: ~macos 
>> ['app-editors/emacs']
>> app-i18n/skk-jisyo/skk-jisyo-200407.ebuild: macos 
>> ['app-arch/gzip']    
>> app-portage/gentoolkit-dev/gentoolkit-dev-0.2.0_pre3.ebuild: macos 
>> ['>=dev-lang/python-2.0', '>=sys-apps/grep-2.4', 
>> '>=sys-apps/portage-2.0.50', '>=dev-lang/perl-5.6']    
>> app-portage/gentoolkit/gentoolkit-0.2.0_pre8.ebuild: macos 
>> ['>=dev-lang/python-2.0', '>=sys-apps/grep-2.4', 
>> '>=sys-apps/portage-2.0.50', '>=dev-lang/perl-5.6']
>> app-portage/splat/splat-0.08.ebuild: macos ['dev-lang/perl']
>> app-text/dos2unix/dos2unix-3.1.ebuild: macos ['sys-devel/patch']
>> app-text/htmltidy/htmltidy-3.10.29.ebuild: macos 
>> ['>=sys-devel/autoconf-2.5', '>=sys-devel/automake-1.5', 
>> 'sys-devel/patch']
>> app-text/migemo/migemo-0.40-r1.ebuild: macos ['dev-lang/ruby', 
>> 'app-editors/emacs']    app-text/migemo/migemo-0.40-r1.ebuild: macos 
>> ['dev-lang/ruby']
>> app-text/unix2dos/unix2dos-2.2.ebuild: macos ['sys-devel/patch', 
>> 'sys-devel/gcc']    
>> dev-lang/swi-prolog-lite/swi-prolog-lite-5.3.14.ebuild: macos 
>> ['sys-apps/sed', 'sys-apps/gawk']    dev-libs/glib/glib-2.4.4.ebuild: 
>> ~macos ['sys-devel/libtool']
>> dev-python/readline/readline-2.3.3.ebuild: macos 
>> ['>=dev-lang/python-2.3.3']    
>> dev-ruby/ruby-bsearch/ruby-bsearch-1.5-r1.ebuild: macos 
>> ['dev-lang/ruby', 'sys-devel/patch']    
>> dev-ruby/ruby-bsearch/ruby-bsearch-1.5-r1.ebuild: macos 
>> ['dev-lang/ruby']
>> dev-ruby/ruby-romkan/ruby-romkan-0.4-r1.ebuild: macos 
>> ['dev-lang/ruby', 'sys-devel/patch']
>> dev-ruby/ruby-romkan/ruby-romkan-0.4-r1.ebuild: macos ['dev-lang/ruby']
>> dev-util/dialog/dialog-0.9_beta20031207.ebuild: macos 
>> ['>=app-shells/bash-2.04-r3', 'sys-devel/patch']
>> dev-util/dialog/dialog-0.9_beta20031207.ebuild: macos 
>> ['>=app-shells/bash-2.04-r3']
>> mail-client/mutt/mutt-1.5.6-r2.ebuild: macos ['sys-devel/automake', 
>> 'sys-devel/autoconf', 'sys-libs/gdbm', 'sys-devel/patch', 
>> '>=dev-libs/openssl-0.9.6']
>> media-libs/audiofile/audiofile-0.2.6-r1.ebuild: macos 
>> ['sys-devel/libtool', 'sys-devel/patch']
>> media-libs/freetype/freetype-2.1.5-r1.ebuild: macos ['sys-libs/zlib', 
>> 'sys-devel/patch']
>> media-libs/freetype/freetype-2.1.5-r1.ebuild: macos ['sys-libs/zlib']
>> media-libs/freetype/freetype-2.1.5.ebuild: macos ['sys-libs/zlib', 
>> 'sys-devel/patch']
>> media-libs/freetype/freetype-2.1.5.ebuild: macos ['sys-libs/zlib']
>> media-libs/libid3tag/libid3tag-0.15.1b.ebuild: macos 
>> ['>=sys-libs/zlib-1.1.3']
>> media-libs/libpng/libpng-1.2.5-r7.ebuild: macos ['sys-libs/zlib', 
>> 'sys-devel/patch', 'sys-devel/gcc']
>> media-libs/libpng/libpng-1.2.5-r7.ebuild: macos ['sys-libs/zlib']
>> media-sound/esound/esound-0.2.34.ebuild: ~macos 
>> ['>=sys-apps/tcp-wrappers-7.6-r2', '>=media-libs/alsa-lib-0.5.10b']
>> media-sound/esound/esound-0.2.34.ebuild: ~macos ['sys-devel/libtool', 
>> '>=sys-apps/tcp-wrappers-7.6-r2', '>=media-libs/alsa-lib-0.5.10b', 
>> 'sys-devel/patch']
>> media-sound/lame/lame-3.96.ebuild: macos ['=x11-libs/gtk+-1.2*', 
>> 'sys-devel/patch', 'sys-devel/gcc']
>> media-sound/lame/lame-3.96.ebuild: macos ['=x11-libs/gtk+-1.2*']
>> media-sound/madplay/madplay-0.15.2b.ebuild: macos ['media-sound/esound']
>> net-analyzer/darkstat/darkstat-2.6-r1.ebuild: macos 
>> ['>=net-libs/libpcap-0.7.1', 'sys-devel/patch']
>> net-analyzer/netperf/netperf-2.2.4.ebuild: macos ['>=sys-apps/sed-4']
>> net-libs/libwww/libwww-5.4.0-r2.ebuild: macos 
>> ['>=dev-libs/openssl-0.9.6', 'dev-lang/perl', 
>> '>=sys-devel/autoconf-2.13', 'sys-devel/patch', 
>> '>=sys-libs/zlib-1.1.4', '>=dev-db/mysql-3.23.26']
>> net-libs/libwww/libwww-5.4.0-r2.ebuild: macos 
>> ['>=sys-libs/zlib-1.1.4', '>=dev-db/mysql-3.23.26', 
>> '>=dev-libs/openssl-0.9.6', 'dev-lang/perl']
>> net-misc/wget/wget-1.9.1-r2.ebuild: macos ['>=dev-libs/openssl-0.9.6b']
>> net-misc/wget/wget-1.9.1-r2.ebuild: macos ['sys-devel/autoconf', 
>> 'sys-devel/patch']
>> net-www/links/links-2.1_pre15.ebuild: macos 
>> ['>=dev-libs/openssl-0.9.6c', '>=media-libs/svgalib-1.4.3', 
>> 'sys-libs/gpm', '>=media-libs/tiff-3.5.7', 'sys-libs/zlib', 
>> 'sys-darwin/X11', '>=sys-devel/flex-2.5.4a', '>=media-libs/jpeg-6b', 
>> 'dev-libs/DirectFB']
>> net-www/links/links-2.1_pre15.ebuild: macos 
>> ['>=dev-libs/openssl-0.9.6c', '>=media-libs/svgalib-1.4.3', 
>> 'sys-libs/gpm', '>=media-libs/tiff-3.5.7', 'sys-libs/zlib', 
>> 'sys-darwin/X11', 'sys-devel/automake', '>=sys-devel/flex-2.5.4a', 
>> '>=media-libs/jpeg-6b', 'dev-libs/DirectFB', 'sys-devel/autoconf', 
>> 'sys-devel/gcc']
>> net-www/lynx/lynx-2.8.5.ebuild: macos ['>=sys-libs/zlib-1.1.3', 
>> '>=dev-libs/openssl-0.9.6']
>> sys-devel/gettext/gettext-0.12.1-r1.ebuild: macos ['sys-devel/patch']
>> sys-devel/gnuconfig/gnuconfig-20040214.ebuild: macos ['sys-devel/patch']
>> sys-libs/readline/readline-4.3-r6.ebuild: macos 
>> ['>=app-shells/bash-2.05b-r2', 'sys-devel/patch']
>> sys-libs/readline/readline-4.3-r6.ebuild: macos 
>> ['>=app-shells/bash-2.05b-r2']
>> x11-wm/fluxbox/fluxbox-0.9.9.ebuild: macos ['sys-darwin/X11', 
>> '>=sys-devel/autoconf-2.52', 'sys-devel/patch']
>> x11-wm/fluxbox/fluxbox-0.9.9.ebuild: macos ['sys-darwin/X11']
>>
>> Michael Sterrett
>>   -Mr. Bones.-
>> mr_bones_@gentoo.org
>>
>> -- 
>> gentoo-dev@gentoo.org mailing list
>>
>
>
> -- 
> gentoo-dev@gentoo.org mailing list
>
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Mike Frysinger]

On Saturday 24 July 2004 04:54 pm, Joshua Brindle wrote:
> How about we remove this macos junk from the tree and you can give your
> users an overlay tarball?

because the idea is to get it merged cleanly with the main tree

> also sys-darwin and app-macos,  I never saw these categories come across
> the list for approval (though I might have missed it since I don't care
> about macos at all). Were these approved? If not they should be removed
> asap, I can't see any justification for making new categories for these
> programs (but as I already said I'd prefer this stuff not be in portage
> at all).

no one asked but then again the dirs look empty to me so there isnt anything 
to discuss ...

lets keep the flames down shall we
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Pieter Van den Abeele]

On 24 Jul 2004, at 22:54, Joshua Brindle wrote:

> also sys-darwin and app-macos,  I never saw these categories come 
> across the list for approval (though I might have missed it since I 
> don't care about macos at all). Were these approved? If not they 
> should be removed asap, I can't see any justification for making new 
> categories for these programs (but as I already said I'd prefer this 
> stuff not be in portage at all).

We discussed the proposal on the ml and in the first roadmap meeting, 
which was announced on core. The empty directories were created well in 
advance (with .keep files explaining the reasoning behind them in the 
cvs log) to allow developers to react and make suggestions about it.

The reasoning behind both:

- app-macos contains apps that do not depend on anything but a regular 
mac os x system. A good example of such an app is the GPL'ed OS X 
Desktop Manager which implements virtual desktops on OS X. 
http://wsmanager.sourceforge.net/index.php  Most of the time these 
packages are Mac OS X only, open source and don't fit any other 
category. Ebuilds for the popular Mac OS X Tiger widgets, (Tiny 
applications like a calculator, a stock ticker, ...) Mac OS X icon 
sets, ... Maybe also our own (probably cocoa) portage GUI, but that 
would fit app-portage. (of course open for discussion) Things like 
popular Mac OS X only IM clients can of course be fitted in net-im etc.

- sys-darwin contains ebuilds for software that is very very darwin 
(mostly kerneldriver) specific. I was thinking of things like (just a 
quick cut/paste):

sys-darwin/IOADBFamily-2
sys-darwin/IOATABlockStorage-130.3.1
sys-darwin/IOATAFamily-155.3.1
sys-darwin/IOATAPIProtocolTransport-130.0.2
sys-darwin/IOAudioFamily-140.2.9
sys-darwin/IOCDStorageFamily-25
sys-darwin/IODVDStorageFamily-14
sys-darwin/IOFWDVComponents-153.4.1
sys-darwin/IOFireWireAVC-152.4.1
sys-darwin/IOFireWireFamily-170.4.0
sys-darwin/IOFireWireIP-120.4.0
sys-darwin/IOFireWireSBP2-151.4.0
sys-darwin/IOFireWireSerialBusProtocolTransport-130.2.7
sys-darwin/IOGraphics-123
sys-darwin/IOHIDFamily-86
sys-darwin/IOKitTools-38
sys-darwin/IOKitUser-174
sys-darwin/IONetworkingFamily-15
sys-darwin/IOPCCardFamily-38
sys-darwin/IOPCIFamily-21
sys-darwin/IOSCSIArchitectureModelFamily-130.3.8
sys-darwin/IOSCSIParallelFamily-130.3.1
sys-darwin/IOSerialFamily-20
sys-darwin/IOStorageFamily-44.1
sys-darwin/IOUSBFamily-205.3.5
sys-darwin/IOUSBMassStorageClass-130.2.1
sys-darwin/KeyLargoATA-110.3.1

Anyway, this stuff is obviously open for discussion, just like 
everything else I did/do/am going to do.

I created both empty directories a week or two ago, because I figured 
if somebody didn't like them he would bring them up on the ml and have 
them renamed to something even better if needed. At the time I thought 
they were kosher. Nothing to have nightmares about. (I hope) 
Suggestions welcome of course.

Best regards,

Pieter Van den Abeele





> Joshua Brindle
>
>
> Pieter Van den Abeele wrote:
>
>> Hi,
>>
>> There are two types of Gentoo MacOS users: There is the user who 
>> wants to extend his Mac OS X system with packages that didn't came 
>> pre-installed (like tetex, kde, mysql, prolog, ,... ) Then there's 
>> the user who wants to use Gentoo to rebuild parts of his Mac OS X 
>> operating system (a new kernel, python with readline support, ...) or 
>> just build a Darwin system from scratch without the fancy Apple 
>> stuff.
>>
>> Several devs work on making Gentoo MacOS work for both users. 
>> Everything happens in parallel.
>>
>> Why does repoman/linux think the dependency graph for macos is 
>> broken? Developers that work for users of the first type, keyword 
>> packages against a virtual base system. The entire base system (all 
>> packages provided by apple) is injected into the depgraph and locked 
>> down by a profile. A user cannot upgrade or downgrade Apple provided 
>> stuff, unless the user really insists on doing so. Repoman on linux 
>> complains about broken macos depgraph because the macos base system 
>> obviously isn't injected into the depgraph under linux.
>>
>> There are some ways to make repoman not complain about macos:
>>
>>
>> 1. make repoman not do macos QA under linux
>>
>> Since repoman doesn't complain about macos under macos (it must be 
>> broken or somehow take into account injected packages when doing 
>> --emptytree), I prefer this option. It's also the least amount of 
>> work.
>>
>>
>> 2. make repoman macos aware
>>
>> This requires new portage features. Adding another file to the 
>> profiles, I can think of at least 2 portage feature requests that 
>> require adding another file to the profiles, so this can't be a short 
>> term solution.
>> Opened a bug about persistent injected packages. (Also needed to make 
>> --emptytree work on macos, since --emptytree also removes the 
>> injected base system).
>>
>>
>> 3. add empty ebuilds keyworded "-* macos" for everything that gets 
>> injected.
>>
>> Requires 300 empty ebuilds to be added for each macos profile. This 
>> is a hack around a portage bug that prevents a package from being 
>> purely virtual. There needs to be at least an empty ebuild.
>> The problem with the workaround is that if a linux user uses the 
>> 'ignore keywords' syntax: emerge ./macos.ebuild that will break their 
>> system.
>>
>>
>> 4. change every ebuild that depends on the macos base system by 
>> making the base system dependencies conditional.
>>
>> How many ebuilds depend on 300 ebuilds? How many dependencies need to 
>> be changed per ebuild? What about base system evolution?
>>
>>
>> Best regards,
>>
>> Pieter Van den Abeele
>>
>>
>>
>>
>> On 24 Jul 2004, at 13:34, Michael Sterrett -Mr. Bones.- wrote:
>>
>>> The repoman output generated from the macos keywording is getting 
>>> out of hand.
>>> Something needs to be done to address this soon:
>>>
>>> app-admin/makepasswd/makepasswd-1.10.ebuild: macos ['dev-lang/perl'] 
>>>    app-admin/passook/passook-1.0.0.ebuild: macos ['sys-apps/grep', 
>>> 'sys-apps/miscfiles', 'dev-lang/perl']
>>> app-admin/passook/passook-1.0.0.ebuild: macos ['sys-apps/grep', 
>>> 'sys-apps/miscfiles', 'sys-devel/patch', 'dev-lang/perl']
>>> app-editors/nano/nano-1.3.3-r1.ebuild: macos ['sys-devel/patch']
>>> app-emacs/apel/apel-10.6.ebuild: macos ['app-editors/emacs']    
>>> app-emacs/flim/flim-1.14.6.ebuild: macos ['app-editors/emacs']    
>>> app-emacs/limit/limit-1.14.8_pre20040415.ebuild: macos 
>>> ['app-editors/emacs']
>>> app-emacs/riece/riece-1.0.1.ebuild: macos ['app-editors/emacs']    
>>> app-emacs/semi/semi-1.14.6.ebuild: macos ['app-editors/emacs']    
>>> app-emacs/wanderlust/wanderlust-2.10.1-r2.ebuild: macos 
>>> ['app-editors/emacs', 'sys-devel/patch']
>>> app-emacs/wanderlust/wanderlust-2.10.1-r2.ebuild: macos 
>>> ['app-editors/emacs']   
>>> app-emacs/wanderlust/wanderlust-2.11.30_pre20040618.ebuild: ~macos 
>>> ['app-editors/emacs']
>>> app-i18n/skk-jisyo/skk-jisyo-200407.ebuild: macos ['app-arch/gzip']  
>>>   app-portage/gentoolkit-dev/gentoolkit-dev-0.2.0_pre3.ebuild: macos 
>>> ['>=dev-lang/python-2.0', '>=sys-apps/grep-2.4', 
>>> '>=sys-apps/portage-2.0.50', '>=dev-lang/perl-5.6']    
>>> app-portage/gentoolkit/gentoolkit-0.2.0_pre8.ebuild: macos 
>>> ['>=dev-lang/python-2.0', '>=sys-apps/grep-2.4', 
>>> '>=sys-apps/portage-2.0.50', '>=dev-lang/perl-5.6']
>>> app-portage/splat/splat-0.08.ebuild: macos ['dev-lang/perl']
>>> app-text/dos2unix/dos2unix-3.1.ebuild: macos ['sys-devel/patch']
>>> app-text/htmltidy/htmltidy-3.10.29.ebuild: macos 
>>> ['>=sys-devel/autoconf-2.5', '>=sys-devel/automake-1.5', 
>>> 'sys-devel/patch']
>>> app-text/migemo/migemo-0.40-r1.ebuild: macos ['dev-lang/ruby', 
>>> 'app-editors/emacs']    app-text/migemo/migemo-0.40-r1.ebuild: macos 
>>> ['dev-lang/ruby']
>>> app-text/unix2dos/unix2dos-2.2.ebuild: macos ['sys-devel/patch', 
>>> 'sys-devel/gcc']    
>>> dev-lang/swi-prolog-lite/swi-prolog-lite-5.3.14.ebuild: macos 
>>> ['sys-apps/sed', 'sys-apps/gawk']    
>>> dev-libs/glib/glib-2.4.4.ebuild: ~macos ['sys-devel/libtool']
>>> dev-python/readline/readline-2.3.3.ebuild: macos 
>>> ['>=dev-lang/python-2.3.3']    
>>> dev-ruby/ruby-bsearch/ruby-bsearch-1.5-r1.ebuild: macos 
>>> ['dev-lang/ruby', 'sys-devel/patch']    
>>> dev-ruby/ruby-bsearch/ruby-bsearch-1.5-r1.ebuild: macos 
>>> ['dev-lang/ruby']
>>> dev-ruby/ruby-romkan/ruby-romkan-0.4-r1.ebuild: macos 
>>> ['dev-lang/ruby', 'sys-devel/patch']
>>> dev-ruby/ruby-romkan/ruby-romkan-0.4-r1.ebuild: macos 
>>> ['dev-lang/ruby']
>>> dev-util/dialog/dialog-0.9_beta20031207.ebuild: macos 
>>> ['>=app-shells/bash-2.04-r3', 'sys-devel/patch']
>>> dev-util/dialog/dialog-0.9_beta20031207.ebuild: macos 
>>> ['>=app-shells/bash-2.04-r3']
>>> mail-client/mutt/mutt-1.5.6-r2.ebuild: macos ['sys-devel/automake', 
>>> 'sys-devel/autoconf', 'sys-libs/gdbm', 'sys-devel/patch', 
>>> '>=dev-libs/openssl-0.9.6']
>>> media-libs/audiofile/audiofile-0.2.6-r1.ebuild: macos 
>>> ['sys-devel/libtool', 'sys-devel/patch']
>>> media-libs/freetype/freetype-2.1.5-r1.ebuild: macos 
>>> ['sys-libs/zlib', 'sys-devel/patch']
>>> media-libs/freetype/freetype-2.1.5-r1.ebuild: macos ['sys-libs/zlib']
>>> media-libs/freetype/freetype-2.1.5.ebuild: macos ['sys-libs/zlib', 
>>> 'sys-devel/patch']
>>> media-libs/freetype/freetype-2.1.5.ebuild: macos ['sys-libs/zlib']
>>> media-libs/libid3tag/libid3tag-0.15.1b.ebuild: macos 
>>> ['>=sys-libs/zlib-1.1.3']
>>> media-libs/libpng/libpng-1.2.5-r7.ebuild: macos ['sys-libs/zlib', 
>>> 'sys-devel/patch', 'sys-devel/gcc']
>>> media-libs/libpng/libpng-1.2.5-r7.ebuild: macos ['sys-libs/zlib']
>>> media-sound/esound/esound-0.2.34.ebuild: ~macos 
>>> ['>=sys-apps/tcp-wrappers-7.6-r2', '>=media-libs/alsa-lib-0.5.10b']
>>> media-sound/esound/esound-0.2.34.ebuild: ~macos 
>>> ['sys-devel/libtool', '>=sys-apps/tcp-wrappers-7.6-r2', 
>>> '>=media-libs/alsa-lib-0.5.10b', 'sys-devel/patch']
>>> media-sound/lame/lame-3.96.ebuild: macos ['=x11-libs/gtk+-1.2*', 
>>> 'sys-devel/patch', 'sys-devel/gcc']
>>> media-sound/lame/lame-3.96.ebuild: macos ['=x11-libs/gtk+-1.2*']
>>> media-sound/madplay/madplay-0.15.2b.ebuild: macos 
>>> ['media-sound/esound']
>>> net-analyzer/darkstat/darkstat-2.6-r1.ebuild: macos 
>>> ['>=net-libs/libpcap-0.7.1', 'sys-devel/patch']
>>> net-analyzer/netperf/netperf-2.2.4.ebuild: macos ['>=sys-apps/sed-4']
>>> net-libs/libwww/libwww-5.4.0-r2.ebuild: macos 
>>> ['>=dev-libs/openssl-0.9.6', 'dev-lang/perl', 
>>> '>=sys-devel/autoconf-2.13', 'sys-devel/patch', 
>>> '>=sys-libs/zlib-1.1.4', '>=dev-db/mysql-3.23.26']
>>> net-libs/libwww/libwww-5.4.0-r2.ebuild: macos 
>>> ['>=sys-libs/zlib-1.1.4', '>=dev-db/mysql-3.23.26', 
>>> '>=dev-libs/openssl-0.9.6', 'dev-lang/perl']
>>> net-misc/wget/wget-1.9.1-r2.ebuild: macos 
>>> ['>=dev-libs/openssl-0.9.6b']
>>> net-misc/wget/wget-1.9.1-r2.ebuild: macos ['sys-devel/autoconf', 
>>> 'sys-devel/patch']
>>> net-www/links/links-2.1_pre15.ebuild: macos 
>>> ['>=dev-libs/openssl-0.9.6c', '>=media-libs/svgalib-1.4.3', 
>>> 'sys-libs/gpm', '>=media-libs/tiff-3.5.7', 'sys-libs/zlib', 
>>> 'sys-darwin/X11', '>=sys-devel/flex-2.5.4a', '>=media-libs/jpeg-6b', 
>>> 'dev-libs/DirectFB']
>>> net-www/links/links-2.1_pre15.ebuild: macos 
>>> ['>=dev-libs/openssl-0.9.6c', '>=media-libs/svgalib-1.4.3', 
>>> 'sys-libs/gpm', '>=media-libs/tiff-3.5.7', 'sys-libs/zlib', 
>>> 'sys-darwin/X11', 'sys-devel/automake', '>=sys-devel/flex-2.5.4a', 
>>> '>=media-libs/jpeg-6b', 'dev-libs/DirectFB', 'sys-devel/autoconf', 
>>> 'sys-devel/gcc']
>>> net-www/lynx/lynx-2.8.5.ebuild: macos ['>=sys-libs/zlib-1.1.3', 
>>> '>=dev-libs/openssl-0.9.6']
>>> sys-devel/gettext/gettext-0.12.1-r1.ebuild: macos ['sys-devel/patch']
>>> sys-devel/gnuconfig/gnuconfig-20040214.ebuild: macos 
>>> ['sys-devel/patch']
>>> sys-libs/readline/readline-4.3-r6.ebuild: macos 
>>> ['>=app-shells/bash-2.05b-r2', 'sys-devel/patch']
>>> sys-libs/readline/readline-4.3-r6.ebuild: macos 
>>> ['>=app-shells/bash-2.05b-r2']
>>> x11-wm/fluxbox/fluxbox-0.9.9.ebuild: macos ['sys-darwin/X11', 
>>> '>=sys-devel/autoconf-2.52', 'sys-devel/patch']
>>> x11-wm/fluxbox/fluxbox-0.9.9.ebuild: macos ['sys-darwin/X11']
>>>
>>> Michael Sterrett
>>>   -Mr. Bones.-
>>> mr_bones_@gentoo.org
>>>
>>> -- 
>>> gentoo-dev@gentoo.org mailing list
>>>
>>
>>
>> -- 
>> gentoo-dev@gentoo.org mailing list
>>
>>
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Mike Frysinger]

On Saturday 24 July 2004 07:18 pm, Pieter Van den Abeele wrote:
> We discussed the proposal on the ml and in the first roadmap meeting,
> which was announced on core. The empty directories were created well in
> advance (with .keep files explaining the reasoning behind them in the
> cvs log) to allow developers to react and make suggestions about it.

putting the .keep files in there is pointless, there's no point in making sure 
empty directories show up
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Pieter Van den Abeele]

Unless you want them to be visible well in advance for discussion to 
take place.
I doubt much of stuff in the other categories is going to depend on 
them, so they can be renamed at any time.

Pieter

On 25 Jul 2004, at 01:30, Mike Frysinger wrote:

> On Saturday 24 July 2004 07:18 pm, Pieter Van den Abeele wrote:
>> We discussed the proposal on the ml and in the first roadmap meeting,
>> which was announced on core. The empty directories were created well 
>> in
>> advance (with .keep files explaining the reasoning behind them in the
>> cvs log) to allow developers to react and make suggestions about it.
>
> putting the .keep files in there is pointless, there's no point in 
> making sure
> empty directories show up
> -mike
>
> --
> gentoo-dev@gentoo.org mailing list
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 840 bytes --]

On Sun, 25 Jul 2004 01:51:38 +0200 Pieter Van den Abeele
<pvdabeel@gentoo.org> wrote:
| Unless you want them to be visible well in advance for discussion to 
| take place.
| I doubt much of stuff in the other categories is going to depend on 
| them, so they can be renamed at any time.

What's wrong with posting to -dev saying "I intend to create the
following categories, what do people think?"? No need to create them in
advance that way, which is especially helpful given how bad cvs is at
handling directories... Adding the directories and the categories entry
without discussing it gives the impression that it's already set in
stone and no longer an item up for discussion.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] macos mess

[Pieter Van den Abeele]

On 25 Jul 2004, at 01:58, Ciaran McCreesh wrote:

> On Sun, 25 Jul 2004 01:51:38 +0200 Pieter Van den Abeele
> <pvdabeel@gentoo.org> wrote:
> | Unless you want them to be visible well in advance for discussion to
> | take place.
> | I doubt much of stuff in the other categories is going to depend on
> | them, so they can be renamed at any time.
>
> What's wrong with posting to -dev saying "I intend to create the
> following categories, what do people think?"? No need to create them in
> advance that way, which is especially helpful given how bad cvs is at
> handling directories... Adding the directories and the categories entry
> without discussing it gives the impression that it's already set in
> stone and no longer an item up for discussion.

Ok , wrong impression.

Afaik I haven't seen any argumentation yet that both directories should 
be renamed, removed, or whatever, so I'm still assuming it's ok to have 
them, since I have showed there will be a need for both soon.

Best regards,

Pieter Van den Abeele

> -- 
> Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
> Mail            : ciaranm at gentoo.org
> Web             : http://dev.gentoo.org/~ciaranm
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Pieter Van den Abeele]

Hi,

An example of an ebuild that could fit the app-macos category. I  
downloaded this from the net.

Best regards,

Pieter Van den Abeele


# Copyright 2004 Rich Wareham
# Distributed under the terms of the GNU General Public License v2

# This is a pretty rough e-build. It does just enough and is pretty  
ugly. You'll need Xcode.

DESCRIPTION="A Virtual Desktop manager for OS X"
SRC_URI="http://belnet.dl.sourceforge.net/sourceforge/wsmanager/${PN} 
-0.5.2-rc2.src.tar.gz"
HOMEPAGE="http://wsmanager.sourceforge.net/"

LICENSE="GPL-2"
SLOT="0"
KEYWORDS="macos"
IUSE=""

src_compile() {
   cd ${WORKDIR}/${PN}
   xcodebuild -target "Desktop Manager" -buildstyle Deployment
}

src_install() {
   cd ${WORKDIR}/${PN}
   mkdir ${D}/Applications/
   cp -Rp "build/Desktop Manager.app" "${D}/Applications/Desktop  
Manager.app"
}


On 25 Jul 2004, at 01:51, Pieter Van den Abeele wrote:

> Unless you want them to be visible well in advance for discussion to  
> take place.
> I doubt much of stuff in the other categories is going to depend on  
> them, so they can be renamed at any time.
>
> Pieter
>
> On 25 Jul 2004, at 01:30, Mike Frysinger wrote:
>
>> On Saturday 24 July 2004 07:18 pm, Pieter Van den Abeele wrote:
>>> We discussed the proposal on the ml and in the first roadmap meeting,
>>> which was announced on core. The empty directories were created well  
>>> in
>>> advance (with .keep files explaining the reasoning behind them in the
>>> cvs log) to allow developers to react and make suggestions about it.
>>
>> putting the .keep files in there is pointless, there's no point in  
>> making sure
>> empty directories show up
>> -mike
>>
>> --
>> gentoo-dev@gentoo.org mailing list
>>
>
>
> --
> gentoo-dev@gentoo.org mailing list
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Donnie Berkholz]

Pieter Van den Abeele said:
> The reasoning behind both:
>
> - app-macos contains apps that do not depend on anything but a regular
> mac os x system. A good example of such an app is the GPL'ed OS X
> Desktop Manager which implements virtual desktops on OS X.
> http://wsmanager.sourceforge.net/index.php  Most of the time these
> packages are Mac OS X only, open source and don't fit any other
> category.

I have a tough time believing there are any applications with functions
written in languages that cannot be functionally or linguistically
classified. The architecture/OS on which a program runs shouldn't be a
basis for a category.

> - sys-darwin contains ebuilds for software that is very very darwin
> (mostly kerneldriver) specific. I was thinking of things like (just a
> quick cut/paste):

Same point as above.

> I created both empty directories a week or two ago, because I figured
> if somebody didn't like them he would bring them up on the ml and have
> them renamed to something even better if needed. At the time I thought
> they were kosher. Nothing to have nightmares about. (I hope)
> Suggestions welcome of course.

I'm glad to hear it's open for discussion, but in the future, could you do
the discussion before rather than after the action? We shouldn't be
expected to go wandering around, looking for new directories, code or
whatever.

Thanks,
Donnie



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Jason Stubbs]

On Sunday 25 July 2004 09:34, Donnie Berkholz wrote:
> I'm glad to hear it's open for discussion, but in the future, could you do
> the discussion before rather than after the action? We shouldn't be
> expected to go wandering around, looking for new directories, code or
> whatever.

+1

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Alastair Tse]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 24 Jul 2004, at 20:34, Donnie Berkholz wrote:

> Pieter Van den Abeele said:
>> The reasoning behind both:
>>
>> - app-macos contains apps that do not depend on anything but a regular
>> mac os x system. A good example of such an app is the GPL'ed OS X
>> Desktop Manager which implements virtual desktops on OS X.
>> http://wsmanager.sourceforge.net/index.php  Most of the time these
>> packages are Mac OS X only, open source and don't fit any other
>> category.
>
> I have a tough time believing there are any applications with functions
> written in languages that cannot be functionally or linguistically
> classified. The architecture/OS on which a program runs shouldn't be a
> basis for a category.

I would say that there will always be apps that don't fit into the 
packaging system. Pieter raised one example where it is a window 
manager (in some sense) but not X11, so it wouldn't fit in x11-wm or 
any x11-* categories. I'm sure there will be others, and I'm not 
particularly keen that we should put them in app-misc just because 
that's the catchall. I think a app-macos is a good compromise in this 
scenario.

But there are definitely many other macosx open source apps that would 
fit under the Gentoo Portage structure, like colloquy would fit in 
net-irc, adium would fit in net-im, class-dump would fit in dev-util, 
etc.

>
>> - sys-darwin contains ebuilds for software that is very very darwin
>> (mostly kerneldriver) specific. I was thinking of things like (just a
>> quick cut/paste):
>
> Same point as above.

Do we have a sys-drivers or something equivalent? I would argue that 
this is needed because the sheer amount of drivers available. We don't 
want to start polluting sys-kernels with darwin drivers, do we?

HOWEVER, I agree that it is premature to setup a category where there 
are no plans to even merge these drivers into portage for the next 
month or so.

Cheers,
- --
Alastair 'liquidx' Tse
  >> Gentoo Developer (Python/GNOME/CJK/PDA/Bluetooth)
  >> http://www.liquidx.net/ | http://dev.gentoo.org/~liquidx/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBA9dhOM4cezkHFPYRApcfAKCeLqt0qq53eY3H3Ad7t2JM+HA7GACfV245
180AEUSUivRVO6+DuKUr9AU=
=gNqg
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

On Sun, 2004-07-25 at 11:53, Alastair Tse wrote:
> Do we have a sys-drivers or something equivalent? I would argue that 
> this is needed because the sheer amount of drivers available. We don't 
> want to start polluting sys-kernels with darwin drivers, do we?
> 
> HOWEVER, I agree that it is premature to setup a category where there 
> are no plans to even merge these drivers into portage for the next 
> month or so.

I've been talking about something like this for a while. My idea,
however, is more like drivers-${TYPE}, where TYPE is video, net or
whatever else.
-- 
Donnie Berkholz
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: New drivers category in portage (Was [gentoo-dev] macos mess)

[Daniel Ostrow]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I wholeheartedly agree, we need driers to be separated out, esp. now
since we are going to be supporting multiple kernel types (obsd, mach,
linux, etc.) and I second spyderous' suggestion of drivers-${TYPE}.

- -Dan

Donnie Berkholz wrote:
| On Sun, 2004-07-25 at 11:53, Alastair Tse wrote:
|
|>Do we have a sys-drivers or something equivalent? I would argue that
|>this is needed because the sheer amount of drivers available. We don't
|>want to start polluting sys-kernels with darwin drivers, do we?
|>
|>HOWEVER, I agree that it is premature to setup a category where there
|>are no plans to even merge these drivers into portage for the next
|>month or so.
|
|
| I've been talking about something like this for a while. My idea,
| however, is more like drivers-${TYPE}, where TYPE is video, net or
| whatever else.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBBEtLsb0gXCN8LgURAu9gAKCE/DEwK+PFIEpqfEG0qDSe7qat8ACg6sgJ
SUyzjskG0bgbLH+BZfEBlZk=
=MpPD
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: New drivers category in portage (Was [gentoo-dev] macos mess)

[Gavin]

> linux, etc.) and I second spyderous' suggestion of drivers-${TYPE}.

I'm currently using RSYNC_EXCLUDEFROM in /etc/make.conf with a hand-edited list of patterns describing files that are irrelevant to my platform/config/needs/etc., to almost cut in half the number of files sync'd by 'emerge sync'.

If we're adding another dimension of things that are irrelevant to my platform, is there a better way of avoiding the wasted bandwidth incurred by emerge sync'ing without resorting to a manually maintained list referenced by RSYNC_EXCLUDEFROM?

If every ebuild had "type/kind/purpose/etc." classifications, then I could define combinations of classifications with different update (emerge sync) priorities/frequencies, vastly reducing both bandwidth consumption and my time required to maintain this bandwidth reduction system for emerge sync's.  Obviously, such a system needs "smarts" to know what which ebuilds must be fetched, regardless of classification priorities (e.g. depends on which packages are already emerged and their current/new dependencies).

BTW, I joined this list recently, and I haven't been tracking portage development, so I probably 
missed something relevant.  If the ideas above are old hat, just press 'delete' ..

Cheers,
Gavin

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: New drivers category in portage (Was [gentoo-dev] macos mess)

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

On Sun, 2004-07-25 at 17:38, Gavin wrote:
> If we're adding another dimension of things that are irrelevant to my platform,

I'm not addressing the rest of your email. But we're not talking about
adding another dimension, merely expanding an existing one (categories)
and moving some packages in other categories to a potentially more
appropriate location.
-- 
Donnie Berkholz
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: New drivers category in portage (Was[gentoo-dev] macos mess)

[Gavin]

Ok, if I define /usr/portage/<categories> as a set of categorized ebuilds for various software "packages", then I can define "dimensions" as abstract groupings of existing Gentoo portage "<categories>".  Using this terminology, for the purposes of my prior suggestion/question regarding filtering out the "bloat" (unnecessary bandwidth consumed) during an "emerge sync", I further define the following as descriptions of candidate "dimensions":

o TYPE, as in "drivers-${TYPE}"
o "<categories>"
o requires X
o requires KDE
o requires Gnome
o requires "platform"
o requires a specific type of kernel (e.g. linux, freebsd, openbsd), or subtype (e.g. linux/mm)
.
.
o many other possibilities

I'm primarily interested in using Gentoo as a server platform.  Large portions of the portage tree might be irrelevant to those with various specialized purposes.  My hypothesis centers around the idea that "<categories>" form an inadequate set of "dimensions" by which users might utilize as criteria for exclusion during "emerge sync".  Furthermore, as more "<categories>" and ebuilds are added, the manual effort required to update a RSYNC_EXCLUDEFROM list rises along with the bandwidth consumed.

Cheers,
Gavin

----- Original Message ----- 
From: "Donnie Berkholz" <spyderous@gentoo.org>
To: <gentoo-dev@lists.gentoo.org>
Sent: Sunday, July 25, 2004 6:57 PM
Subject: Re: [gentoo-dev] Re: New drivers category in portage (Was[gentoo-dev] macos mess)

On Sun, 2004-07-25 at 17:38, Gavin wrote:
> If we're adding another dimension of things that are irrelevant to my platform,

I'm not addressing the rest of your email. But we're not talking about
adding another dimension, merely expanding an existing one (categories)
and moving some packages in other categories to a potentially more
appropriate location.
-- 
Donnie Berkholz
Gentoo Linux


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Jason Stubbs]

On Sunday 25 July 2004 01:54, Pieter Van den Abeele wrote:
> There are two types of Gentoo MacOS users: There is the user who wants
> to extend his Mac OS X system with packages that didn't came
> pre-installed (like tetex, kde, mysql, prolog, ,... ) Then there's the
> user who wants to use Gentoo to rebuild parts of his Mac OS X operating
> system (a new kernel, python with readline support, ...) or just build
> a Darwin system from scratch without the fancy Apple stuff.
>
> Several devs work on making Gentoo MacOS work for both users.
> Everything happens in parallel.

The real problem is that nobody (if I am like everybody else) has heard about 
this stuff except those that are following the macos movement. If you had 
announced your plan to inject everything in MacOS and keyword ebuilds on the 
assumption that those packages are available, many people could have told you 
that the issues that are happening currently would occur. More importantly, 
solutions would have been able to be created before the current issues became 
issues.

> Why does repoman/linux think the dependency graph for macos is broken?

Because it is.

> Developers that work for users of the first type, keyword packages
> against a virtual base system. The entire base system (all packages
> provided by apple) is injected into the depgraph and locked down by a
> profile. A user cannot upgrade or downgrade Apple provided stuff,
> unless the user really insists on doing so. Repoman on linux complains
> about broken macos depgraph because the macos base system obviously
> isn't injected into the depgraph under linux.

So then you are trying to use one keyword to describe both a situation where 
all base packages are available and one where they aren't?

> There are some ways to make repoman not complain about macos:

> 1. make repoman not do macos QA under linux

Ignore the issues? Not likely...

> Since repoman doesn't complain about macos under macos (it must be
> broken or somehow take into account injected packages when doing
> --emptytree), I prefer this option. It's also the least amount of work.

Does it complain when the patch Travis mentioned is in place?

> 2. make repoman macos aware

s/make repoman macos aware/include support in ALL of portage/

> This requires new portage features. Adding another file to the
> profiles, I can think of at least 2 portage feature requests that
> require adding another file to the profiles, so this can't be a short
> term solution.

Why wasn't this suggested months ago? A feature such as this (which isn't hard 
to implement btw) could allow you to not inject everything and be able 
satisfy repoman as well. It would also be useful in separating your two types 
of macos users into separate profiles.

> Opened a bug about persistent injected packages. (Also needed to make
> --emptytree work on macos, since --emptytree also removes the injected
> base system).

This is not a bug.

> 3. add empty ebuilds keyworded "-* macos" for everything that gets
> injected.
>
> Requires 300 empty ebuilds to be added for each macos profile. This is
> a hack around a portage bug that prevents a package from being purely
> virtual.

"Portage bug"? I see it as a feature that's not available yet as no one has 
ever required it or asked for it.

> There needs to be at least an empty ebuild. The problem with the workaround 
> is that if a linux user uses the 'ignore keywords' syntax: 
> emerge ./macos.ebuild that will break their system. 

I don't think we have ever prevented users from intentionally doing something 
blatently unsupported.

> 4. change every ebuild that depends on the macos base system by making
> the base system dependencies conditional.
>
> How many ebuilds depend on 300 ebuilds? How many dependencies need to
> be changed per ebuild? What about base system evolution?

If you want to use portage as it is now with macos, these #3 and #4 are your 
*only* options without throwing QA out of the window.

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Pieter Van den Abeele]

On 25 Jul 2004, at 03:26, Jason Stubbs wrote:

> The real problem is that nobody (if I am like everybody else) has 
> heard about
> this stuff except those that are following the macos movement. If you 
> had
> announced your plan to inject everything in MacOS and keyword ebuilds 
> on the
> assumption that those packages are available, many people could have 
> told you
> that the issues that are happening currently would occur. More 
> importantly,
> solutions would have been able to be created before the current issues 
> became
> issues.

The MacOS project was announced one year ago. One single portage 
feature that still isn't implemented held the project up for that long. 
It's a relatively simple feature compared to the other requirements I 
have for a next generation portage. What MacOS is doing right now is 
moving forward and identifying all MacOS related issues, creating bug 
reports for them and we try to do our best finding both long term and 
short term solutions. We can't afford to be put on hold for another 
year, unfortunately.

>> Why does repoman/linux think the dependency graph for macos is broken.
>
> Because it is.

By design.

> So then you are trying to use one keyword to describe both a situation 
> where
> all base packages are available and one where they aren't?

darwin keyword + darwin profiles -> from scratch approach, 
bootstrapping, livecds, nothing which depends on xcode
macos keyword + macos profiles -> repository of mac OS X compatible 
apps, supports forced overwrites, supports prefixed installs, no 
bootstrapping

anything that is darwin compatible is macos compatible, but not the 
other way around.

>> Since repoman doesn't complain about macos under macos (it must be
>> broken or somehow take into account injected packages when doing
>> --emptytree), I prefer this option. It's also the least amount of 
>> work.
>
> Does it complain when the patch Travis mentioned is in place?

I'll try.

I must say that repoman doesn't work out of the box on any of my 
computers. You're free to try it yourself, I was quite surprised to see 
repoman being happy about macos keywords on my x86, ppc and sparc 
machines. All running latest portage development release .51_pre13.

>> 2. make repoman macos aware
>
> s/make repoman macos aware/include support in ALL of portage/

That's the plan. There will be code, no worry. But until there's code, 
we use the cleanest possible short-term solution for various issues.

>> This requires new portage features. Adding another file to the
>> profiles, I can think of at least 2 portage feature requests that
>> require adding another file to the profiles, so this can't be a short
>> term solution.
>
> Why wasn't this suggested months ago? A feature such as this (which 
> isn't hard
> to implement btw) could allow you to not inject everything and be able
> satisfy repoman as well. It would also be useful in separating your 
> two types
> of macos users into separate profiles.

When I openened the bug about persistent packages, somebody masked it 
as a DUP for a bug numbered somewhere between 11000 - 12000 (we're at 
54000 right now). I'm assuming similar feature requests have been 
waiting for some time.

Best regards,

Pieter Van den Abeele


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Jason Stubbs]

On Sunday 25 July 2004 11:22, Pieter Van den Abeele wrote:
> On 25 Jul 2004, at 03:26, Jason Stubbs wrote:
> > The real problem is that nobody (if I am like everybody else) has
> > heard about this stuff except those that are following the macos movement. 
> > If you had announced your plan to inject everything in MacOS and keyword 
> > ebuilds on the assumption that those packages are available, many people 
> > could have told you that the issues that are happening currently would 
> > occur. More importantly, solutions would have been able to be created 
> > before the current issues became issues.     
>
> The MacOS project was announced one year ago. One single portage
> feature that still isn't implemented held the project up for that long.

Bug #? If there is in fact a bug, it's not marked as a blocker or even as 
being critical.

> It's a relatively simple feature compared to the other requirements I
> have for a next generation portage.

So you're planning to fork the project?

> What MacOS is doing right now is moving forward and identifying all MacOS 
> related issues, creating bug reports for them and we try to do our best 
> finding both long term and short term solutions. We can't afford to be put  
> on hold for another year, unfortunately.   

I've been an official developer for just over five months, and have been 
working on portage and hanging out in #gentoo-portage and on the 
gentoo-portage-dev list for about nine months yet I haven't heard any 
discussion whatsoever about what is required to support portage on macos. 
THAT is what has held it up for a year.

> >> Why does repoman/linux think the dependency graph for macos is broken.
> >
> > Because it is.
>
> By design.

As I said above, no reason had been shown to change the design.

> > So then you are trying to use one keyword to describe both a situation
> > where all base packages are available and one where they aren't?
>
> darwin keyword + darwin profiles -> from scratch approach,
> bootstrapping, livecds, nothing which depends on xcode
> macos keyword + macos profiles -> repository of mac OS X compatible
> apps, supports forced overwrites, supports prefixed installs, no
> bootstrapping
>
> anything that is darwin compatible is macos compatible, but not the
> other way around.

That seems fine.

> >> Since repoman doesn't complain about macos under macos (it must be
> >> broken or somehow take into account injected packages when doing
> >> --emptytree), I prefer this option. It's also the least amount of
> >> work.
> >
> > Does it complain when the patch Travis mentioned is in place?
>
> I'll try.
>
> I must say that repoman doesn't work out of the box on any of my
> computers. You're free to try it yourself, I was quite surprised to see
> repoman being happy about macos keywords on my x86, ppc and sparc
> machines. All running latest portage development release .51_pre13.

Yes, repoman is quite buggy. That is no reason to use it as a scapegoat.

> >> 2. make repoman macos aware
> >
> > s/make repoman macos aware/include support in ALL of portage/
>
> That's the plan. There will be code, no worry. But until there's code,
> we use the cleanest possible short-term solution for various issues.

Again, by forking?

> >> This requires new portage features. Adding another file to the
> >> profiles, I can think of at least 2 portage feature requests that
> >> require adding another file to the profiles, so this can't be a short
> >> term solution.
> >
> > Why wasn't this suggested months ago? A feature such as this (which
> > isn't hard to implement btw) could allow you to not inject everything and 
> > be able satisfy repoman as well. It would also be useful in separating 
> > your two types of macos users into separate profiles.  
>
> When I openened the bug about persistent packages, somebody masked it
> as a DUP for a bug numbered somewhere between 11000 - 12000 (we're at
> 54000 right now). I'm assuming similar feature requests have been
> waiting for some time.

Please give bug numbers. I want the facts first-hand.

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Pieter Van den Abeele]

On 25 Jul 2004, at 04:50, Jason Stubbs wrote:

> On Sunday 25 July 2004 11:22, Pieter Van den Abeele wrote:
>> On 25 Jul 2004, at 03:26, Jason Stubbs wrote:
>>> The real problem is that nobody (if I am like everybody else) has
>>> heard about this stuff except those that are following the macos 
>>> movement.
>>> If you had announced your plan to inject everything in MacOS and 
>>> keyword
>>> ebuilds on the assumption that those packages are available, many 
>>> people
>>> could have told you that the issues that are happening currently 
>>> would
>>> occur. More importantly, solutions would have been able to be created
>>> before the current issues became issues.
>>
>> The MacOS project was announced one year ago. One single portage
>> feature that still isn't implemented held the project up for that 
>> long.
>
> Bug #? If there is in fact a bug, it's not marked as a blocker or even 
> as
> being critical.

It's a glep. The pathspec glep. 
http://www.gentoo.org/proj/en/gentoo-alt/macos-1.xml

I can forward all email I have about to you if you like. Might be 
interesting to read it and get a better idea about it.

>> It's a relatively simple feature compared to the other requirements I
>> have for a next generation portage.
>
> So you're planning to fork the project?

No I'm not. An experimental prototype yes.
Anyway, keep tuned.

>> What MacOS is doing right now is moving forward and identifying all 
>> MacOS
>> related issues, creating bug reports for them and we try to do our 
>> best
>> finding both long term and short term solutions. We can't afford to 
>> be put
>> on hold for another year, unfortunately.
>
> I've been an official developer for just over five months, and have 
> been
> working on portage and hanging out in #gentoo-portage and on the
> gentoo-portage-dev list for about nine months yet I haven't heard any
> discussion whatsoever about what is required to support portage on 
> macos.
> THAT is what has held it up for a year.

Oh well, macos is here now. Let's start doing things now. Whether or 
not you heard about it before is not really relevant anymore. Most of 
the stuff is happening now.
I've been wanting to throw that pathspec thing away and start all over 
again, cause I wrote a comment on it anyway. (I wasn't really 
flattering about  the ugly code at the bottom of the glep. I dislike 
nested ifs.).

> Yes, repoman is quite buggy. That is no reason to use it as a 
> scapegoat.

I've written a patch for it. I think others have been more verbose 
about repoman in this thread. Have nothing against it.

>>>> 2. make repoman macos aware
>>>
>>> s/make repoman macos aware/include support in ALL of portage/
>>
>> That's the plan. There will be code, no worry. But until there's code,
>> we use the cleanest possible short-term solution for various issues.
>
> Again, by forking?

no. We do currently maintain a small patchset to make portage work 
under osx. We are working on making that patchset clean and will submit 
it to you guys in different reviewed bits and pieces.

of course my prototype is osx compatible, but that shouldn't be a 
surprise I think (I hope).

>> When I openened the bug about persistent packages, somebody masked it
>> as a DUP for a bug numbered somewhere between 11000 - 12000 (we're at
>> 54000 right now). I'm assuming similar feature requests have been
>> waiting for some time.
>
> Please give bug numbers. I want the facts first-hand.

My bug was marked as a dup for 
http://bugs.gentoo.org/show_bug.cgi?id=11697

Best regards,

Pieter Van den Abeele

> Regards,
> Jason Stubbs
>
> --
> gentoo-dev@gentoo.org mailing list


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Jason Stubbs]

On Sunday 25 July 2004 12:38, Pieter Van den Abeele wrote:
> It's a glep. The pathspec glep.
> http://www.gentoo.org/proj/en/gentoo-alt/macos-1.xml

"It covers all known relevant areas except cross-platform dependency coherency 
issues." These are the issues that are happening now due to jumping the gun.

> I can forward all email I have about to you if you like. Might be
> interesting to read it and get a better idea about it.

No, thanks. Just get the implementation details of the aforementioned glep 
completed, get the glep approved and I give you my word that it'll be 
imlemented.

> >> It's a relatively simple feature compared to the other requirements I
> >> have for a next generation portage.
> >
> > So you're planning to fork the project?
>
> No I'm not. An experimental prototype yes.
> Anyway, keep tuned.

"Next generation portage" implies throwing away the current portage. If it's 
an experimentatl prototype to help with the current portage, do you have a 
roadmap on how it is to be integrated? How about a list of features? I can 
guarantee you that I am personally working on some of them and so we have 
needless duplication of effort. If your work is truly intended to benefit the 
current portage, why is it so closed?

> >> What MacOS is doing right now is moving forward and identifying all
> >> MacOS related issues, creating bug reports for them and we try to do our
> >> best finding both long term and short term solutions. We can't afford to
> >> be put on hold for another year, unfortunately.
> >
> > I've been an official developer for just over five months, and have
> > been working on portage and hanging out in #gentoo-portage and on the
> > gentoo-portage-dev list for about nine months yet I haven't heard any
> > discussion whatsoever about what is required to support portage on
> > macos. THAT is what has held it up for a year.
>
> Oh well, macos is here now. Let's start doing things now. Whether or
> not you heard about it before is not really relevant anymore. Most of
> the stuff is happening now.

It is completely relevant. Without any advance warning, you have succeeded at 
tripling the pressure on myself and other members of the portage team to get 
things done "now". If you had have spoken up to the relevant projects about 
possible impact, we all could have prepared for it before this "now" ever 
happened.

I don't know why I (or anybody else) should have to clean up after you, but 
I'll get to work on throwing --inject away completely and replacing it with 
an profile addition (which will be user extendable) that will allow the 
ignoring of certain packages during dep resolution.

> I've been wanting to throw that pathspec thing away and start all over
> again, cause I wrote a comment on it anyway. (I wasn't really
> flattering about  the ugly code at the bottom of the glep. I dislike
> nested ifs.).

This is a QA nightmare. You have this release out there that none of the 
supporting projects were ready for and it sounds like you aren't even sure 
about how to support it yourself. A "deal with it as it happens" approach is 
simply not going to cut it.

> > Yes, repoman is quite buggy. That is no reason to use it as a
> > scapegoat.
>
> I've written a patch for it. I think others have been more verbose
> about repoman in this thread. Have nothing against it.

I can guarantee that patch wont be included. To borrow Nick's words, "I really 
dislike special cases."

> >>>> 2. make repoman macos aware
> >>>
> >>> s/make repoman macos aware/include support in ALL of portage/
> >>
> >> That's the plan. There will be code, no worry. But until there's code,
> >> we use the cleanest possible short-term solution for various issues.
> >
> > Again, by forking?
>
> no. We do currently maintain a small patchset to make portage work
> under osx. We are working on making that patchset clean and will submit
> it to you guys in different reviewed bits and pieces.

This, too, should have been done before any release was made.

> >> When I openened the bug about persistent packages, somebody masked it
> >> as a DUP for a bug numbered somewhere between 11000 - 12000 (we're at
> >> 54000 right now). I'm assuming similar feature requests have been
> >> waiting for some time.
> >
> > Please give bug numbers. I want the facts first-hand.
>
> My bug was marked as a dup for
> http://bugs.gentoo.org/show_bug.cgi?id=11697

I can't check it now as bugs is down, but I hope that the profile addition I 
mentioned above will solve it.

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Mike Frysinger]

On Sunday 25 July 2004 12:42 am, Jason Stubbs wrote:
> > I can forward all email I have about to you if you like. Might be
> > interesting to read it and get a better idea about it.
>
> No, thanks. Just get the implementation details of the aforementioned glep
> completed, get the glep approved and I give you my word that it'll be
> imlemented.

i dont see any GLEP
GLEPs are filed through glep.gentoo.org and approved at the manager meeting
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Pieter Van den Abeele]

On 25 Jul 2004, at 07:40, Mike Frysinger wrote:

> On Sunday 25 July 2004 12:42 am, Jason Stubbs wrote:
>>> I can forward all email I have about to you if you like. Might be
>>> interesting to read it and get a better idea about it.
>>
>> No, thanks. Just get the implementation details of the aforementioned 
>> glep
>> completed, get the glep approved and I give you my word that it'll be
>> imlemented.
>
> i dont see any GLEP
> GLEPs are filed through glep.gentoo.org and approved at the manager 
> meeting

I didn't write this glep, and also wasn't the one following up on it. 
Maybe it's still in draft?
I do recall a discussion with the portage team a few months ago about 
them not knowing anything about this glep.
Best to ask drobbins or g2boojum.

Best regards,

Pieter Van den Abeele


> -mike
>
> --
> gentoo-dev@gentoo.org mailing list
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Jason Stubbs]

On Sunday 25 July 2004 13:42, Jason Stubbs wrote:
> I'll get to work on throwing --inject away completely and replacing it with
> an profile addition (which will be user extendable) that will allow the
> ignoring of certain packages during dep resolution.

Done. The file package.provided can be added to profiles and should contain a 
cat/pkg-ver for each package that is maintained outside of portage. Repoman 
will transparently use the file and not complain about missing deps. Users 
can also create and add to /etc/portage/package.provided for anything that 
would normally be injected.

Similarities to --inject:
* The package will be installed if specified on the command line or in either
  system or world.

Differences to --inject:
* /var/db/pkg is not touched
* --emptytree will not try to pull the package in
* Possible upgrades will be ignored on --deep if the "provided" package can
  satisfy all dependencies.
* The dependencies for the package will be ignored on either --deep or
  --emptytree.

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Jason Stubbs]

On Sunday 25 July 2004 17:25, Jason Stubbs wrote:
> Users can also create and add to /etc/portage/package.provided for anything 
> that would normally be injected. 

Make that /etc/portage/profile/package.provided.

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Pieter Van den Abeele]

Thnxs. Is the fix in cvs? I'd like to make a cvs snapshot and have our 
devs test.

Best regards,

Pieter Van den Abeele

On 25 Jul 2004, at 10:25, Jason Stubbs wrote:

> On Sunday 25 July 2004 13:42, Jason Stubbs wrote:
>> I'll get to work on throwing --inject away completely and replacing 
>> it with
>> an profile addition (which will be user extendable) that will allow 
>> the
>> ignoring of certain packages during dep resolution.
>
> Done. The file package.provided can be added to profiles and should 
> contain a
> cat/pkg-ver for each package that is maintained outside of portage. 
> Repoman
> will transparently use the file and not complain about missing deps. 
> Users
> can also create and add to /etc/portage/package.provided for anything 
> that
> would normally be injected.
>
> Similarities to --inject:
> * The package will be installed if specified on the command line or in 
> either
>   system or world.
>
> Differences to --inject:
> * /var/db/pkg is not touched
> * --emptytree will not try to pull the package in
> * Possible upgrades will be ignored on --deep if the "provided" 
> package can
>   satisfy all dependencies.
> * The dependencies for the package will be ignored on either --deep or
>   --emptytree.
>
> Regards,
> Jason Stubbs
>
> --
> gentoo-dev@gentoo.org mailing list
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Pieter Van den Abeele]

Hi,

I think this mail is more about portage-ng than portage, so I'll 
explain why we have that project, how I see the project, and what to 
expect from it.

I've nothing against portage or any other package manager out there. 
One thing that does make portage different from other package managers 
is that it's still under development. Features are added on a per case 
basis.
Portage-ng is an experiment in the sense that we didn't take portage 
and added a few features. We Looked at all the requirements, made a 
design and coded something that basically does what portage is required 
to do, only different.
I'm not going to explain all the differences etc yet, the idea is to 
publish the code, a paper and allow people (not necessarily only 
gentoo) reuse the idea, code, or the entire product. It does solve some 
problems that are currently difficult to solve in portage.

Best regards,

Pieter Van den Abeele




On 25 Jul 2004, at 06:42, Jason Stubbs wrote:

> On Sunday 25 July 2004 12:38, Pieter Van den Abeele wrote:
>> It's a glep. The pathspec glep.
>> http://www.gentoo.org/proj/en/gentoo-alt/macos-1.xml
>
> "It covers all known relevant areas except cross-platform dependency 
> coherency
> issues." These are the issues that are happening now due to jumping 
> the gun.
>
>> I can forward all email I have about to you if you like. Might be
>> interesting to read it and get a better idea about it.
>
> No, thanks. Just get the implementation details of the aforementioned 
> glep
> completed, get the glep approved and I give you my word that it'll be
> imlemented.
>
>>>> It's a relatively simple feature compared to the other requirements 
>>>> I
>>>> have for a next generation portage.
>>>
>>> So you're planning to fork the project?
>>
>> No I'm not. An experimental prototype yes.
>> Anyway, keep tuned.
>
> "Next generation portage" implies throwing away the current portage. 
> If it's
> an experimentatl prototype to help with the current portage, do you 
> have a
> roadmap on how it is to be integrated? How about a list of features? I 
> can
> guarantee you that I am personally working on some of them and so we 
> have
> needless duplication of effort. If your work is truly intended to 
> benefit the
> current portage, why is it so closed?
>
>>>> What MacOS is doing right now is moving forward and identifying all
>>>> MacOS related issues, creating bug reports for them and we try to 
>>>> do our
>>>> best finding both long term and short term solutions. We can't 
>>>> afford to
>>>> be put on hold for another year, unfortunately.
>>>
>>> I've been an official developer for just over five months, and have
>>> been working on portage and hanging out in #gentoo-portage and on the
>>> gentoo-portage-dev list for about nine months yet I haven't heard any
>>> discussion whatsoever about what is required to support portage on
>>> macos. THAT is what has held it up for a year.
>>
>> Oh well, macos is here now. Let's start doing things now. Whether or
>> not you heard about it before is not really relevant anymore. Most of
>> the stuff is happening now.
>
> It is completely relevant. Without any advance warning, you have 
> succeeded at
> tripling the pressure on myself and other members of the portage team 
> to get
> things done "now". If you had have spoken up to the relevant projects 
> about
> possible impact, we all could have prepared for it before this "now" 
> ever
> happened.
>
> I don't know why I (or anybody else) should have to clean up after 
> you, but
> I'll get to work on throwing --inject away completely and replacing it 
> with
> an profile addition (which will be user extendable) that will allow the
> ignoring of certain packages during dep resolution.
>
>> I've been wanting to throw that pathspec thing away and start all over
>> again, cause I wrote a comment on it anyway. (I wasn't really
>> flattering about  the ugly code at the bottom of the glep. I dislike
>> nested ifs.).
>
> This is a QA nightmare. You have this release out there that none of 
> the
> supporting projects were ready for and it sounds like you aren't even 
> sure
> about how to support it yourself. A "deal with it as it happens" 
> approach is
> simply not going to cut it.
>
>>> Yes, repoman is quite buggy. That is no reason to use it as a
>>> scapegoat.
>>
>> I've written a patch for it. I think others have been more verbose
>> about repoman in this thread. Have nothing against it.
>
> I can guarantee that patch wont be included. To borrow Nick's words, 
> "I really
> dislike special cases."
>
>>>>>> 2. make repoman macos aware
>>>>>
>>>>> s/make repoman macos aware/include support in ALL of portage/
>>>>
>>>> That's the plan. There will be code, no worry. But until there's 
>>>> code,
>>>> we use the cleanest possible short-term solution for various issues.
>>>
>>> Again, by forking?
>>
>> no. We do currently maintain a small patchset to make portage work
>> under osx. We are working on making that patchset clean and will 
>> submit
>> it to you guys in different reviewed bits and pieces.
>
> This, too, should have been done before any release was made.
>
>>>> When I openened the bug about persistent packages, somebody masked 
>>>> it
>>>> as a DUP for a bug numbered somewhere between 11000 - 12000 (we're 
>>>> at
>>>> 54000 right now). I'm assuming similar feature requests have been
>>>> waiting for some time.
>>>
>>> Please give bug numbers. I want the facts first-hand.
>>
>> My bug was marked as a dup for
>> http://bugs.gentoo.org/show_bug.cgi?id=11697
>
> I can't check it now as bugs is down, but I hope that the profile 
> addition I
> mentioned above will solve it.
>
> Regards,
> Jason Stubbs
>
> --
> gentoo-dev@gentoo.org mailing list


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Jason Stubbs]

On Sunday 25 July 2004 20:30, Pieter Van den Abeele wrote:

<SNIP "my portage is better than yours" sales pitch>

You said nothing that eases any of my concerns. Why is it closed? You 
mentioned "we" a few times - who is this "we"? But, honestly, I don't care 
any more. The chance is once it does become open, it'll be found to be full 
of bugs as per the norm.

One question.. If you are capable of writing a super portage that does all 
that portage does and more, why couldn't you fix one little bug that held up 
your beloved macos release for over a year that was fixable in less than one 
hour?

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] macos mess

[Jason Stubbs]

Okay..

For the benefit of all others, I'm happy to announce that Pieter and I are 
currently having a pleasant chat on IRC that has eased my fears on the 
portage front.

On the macos front, I really think things could have gone a lot smoother but 
hopefully package.provided will clear up the main issues for everybody and we 
can move on. ;)

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list