Re: [gentoo-dev] gentoo's portage

[Damon M. Conway]

>1) documentation:  please ensure the 'build' options
>(/etc/make.conf.build) are explained as to what all the three letter
>acronyms mean and the impact/dependencies of picking them
>
>2)documentation:  the departure from 'normal' system startup scripts
>needs to described.  What will happen when a 'normal' non-gentoo
>application tries to install itself expecting a 'standard' layout?

Yes, we need documentation.  It's probably about time we look at putting a
doco team together.  The 1.0 release is sneaking up on us.

>3) portage:  a great drawback seems that 'constant human effort' is
>required to ensure the portage tree is updated.  I can see this becoming
>an issue for gentoo.  There are many applications released and updated
>that must conform to the portage system to make sure 'the latest and
>greatest' really IS available "as advertised" on the web site :) eg.  I
>needed the latest Matrox drivers and Powerdesk utility which I installed
>manually.  my system's portage is not aware of manual installs I perform
>and I needed the drivers before they could be added to the 'gentoo
>portage' tree.

Please see the 4000 packages in the FreeBSD ports tree.  This method is
tried and true.

>4) portage: sounds powerful - perhaps it can also be used as a means of
>a useful/automated/'user-friendly' 'uninstall' which is sorely lacking
>in the unix world.  I have tried 4+ distributions of Linux and am
>getting a bit tired of telling their respective 'uninstall' that when I
>want to remove a game, I would STILL like to keep gnome on my system.

It does, but it's not very userfriendly at the moment.  To unmerge an app,
do this:

ebuild /var/db/pkg/<category>/<app-ver>/<app-ver>.ebuild unmerge

It will only unmerge that version of that application, and nothing else.

>5) portage: if possible (space requirements, etc), 'generic 386'
>binaries for the base system should be in the portage tree so that
>initial installs/builds can progress faster.  the 'emerge system' on my
>P4 1.4 took a looong time.  Would be better to have as much generic base
>system and then be able to fine tune as desired.

Yes, but right now we are in a pre-release state and doing a full build for
each release would get us nowhere.

>6) portage: organization.  consider reducing the # of categories.
>People can mainly remember 7 +/- 2 items of information.  go into
>/usr/portage and there are a lot of choices which will only increase in
>the future.  Consider:

They don't have to remember them, they are in /usr/portage.  They are also
pretty self explanitory.

>    /usr/portage/base  (anything necessary to get from PC booted to
>minimal command line)
>    /usr/portage/GUI   (user interfaces, windowing systems)
>    /user/portage/development  (development tools, languages)
>
>    etc.    Note that i used 'development' instead of 'dev'.  lets use
>long file names as necessary.
>
>    and don't go too deep:
>
>
>/usr/portage/development/languages/python/libs/3rdparty/UnimportantLib

This is no better than  dev-python/libN.  You have to go no farther than
/usr/portage to get a view of where things are.  Also, you can do an
"emerge <category>/<app>" from anywhere in the filesystem, and portage with
install the latest version of that app with dependencies.  Can you imagine
having to type "emerge
development/languages/python/libs/3rdparty/UnimportantLib" ?

I think the more you play with the system, the more you'll begin to see 
it's logic.  Also, I know that some of us would like to see a search 
feature.  However, that is low on the list for now.  We're in the process 
of shaking bugs out of the system and defining a solid base from which to 
work from.

>So far, gentoo seems to be the distribution I would prefer to use.
>Congratulations on the results you've achieved.

drobbins deserves all the credit.  He's designed and built the only Linux
distro I'll use.

kabau

--
"UNIX was not designed to stop you from doing stupid things, because that
 would also stop you from doing clever things."  --Doug Gwyn