[gentoo-dev] portage-1.5_pre7

[gentoo-dev] portage-1.5_pre7

[drobbins]

Hi all,

I just committed sys-apps/portage-1.5_pre7, a brand new *test* 
version of Portage with recursive merging capability.

Here's how to install it.  First, update your /usr/portage tree.
Then, do the following:

# cd /etc
# rm make.conf.eg
# rm make.defaults.eg
(if they exist, that is)

# cd /usr/portage/sys-apps/portage
# ebuild portage-1.5_pre7.ebuild merge

# cd /etc
# ln -s /usr/portage/profiles/default make.profile

The _beta_ recursive merging capability can be used as follows.

# emerge --pretend foo-1.0.ebuild

This will show you the ebuilds that will be merged to install this
particular ebuild.  Build deps will be listed first, then runtime
deps.  There may be duplicates in the runtime deps list; this is 
normal.  The package in question won't be installed twice, since 
this dependency will be satisfied by the time emerge gets to the
runtime deps.  To do the "real" install:

# emerge foo-1.0.ebuild

:)))

I'm currently using emerge on cvs.gentoo.org, with success.
It will also work (not with full profile support yet) if you do
this:

# export ROOT=/mnt/gentoo
# emerge foo-1.0.ebuild

All build dependencies will be installed to "/" and all runtime
dependencies will be installed to "/mnt/gentoo" :)))

Enjoy,

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] portage-1.5_pre7

[Pete Gavin]

A few comments...

When I merged in the spython package, it gave me a warning that
sys-devel/spython is required. I merged dev-lang/python in, and
unmerged spython, and just symlinked /usr/bin/python to spython, and
everything seems to be working perfectly. I've been thinking, since
the python and spython packages have alot of overlap, we could either
make python and spython mutually exclusive (or make dev-lang/python an
"upgrade" to spython), or we could make spython search in
/usr/lib/spython2.0 as opposed to /usr/lib/python2.0. This would
create a lot of identical files on the filesystem, but that way, at
least if you merged in the dev-lang/python, and then unmerged it, you
wouldn't remove all the files in sys-devel/python. In fact, I think
the latter would be a great solution. That way, you can have the
statically linked spython and regular python installed simultaneously
w/o having any overlap (which is a big pet peeve of mine), and not
have problems created by merging/unmerging dev-lang/python. I can try
and hack the spython package to get this to work, if you want.

Pete

Re: [gentoo-dev] portage-1.5_pre7

[Achim Gottinger]

Pete Gavin wrote:
> 
> A few comments...
> 
> When I merged in the spython package, it gave me a warning that
> sys-devel/spython is required. I merged dev-lang/python in, and
> unmerged spython, and just symlinked /usr/bin/python to spython, and
> everything seems to be working perfectly. I've been thinking, since
> the python and spython packages have alot of overlap, we could either
> make python and spython mutually exclusive (or make dev-lang/python an
> "upgrade" to spython), or we could make spython search in
> /usr/lib/spython2.0 as opposed to /usr/lib/python2.0. This would
> create a lot of identical files on the filesystem, but that way, at
> least if you merged in the dev-lang/python, and then unmerged it, you
> wouldn't remove all the files in sys-devel/python. In fact, I think
> the latter would be a great solution. That way, you can have the
> statically linked spython and regular python installed simultaneously
> w/o having any overlap (which is a big pet peeve of mine), and not
> have problems created by merging/unmerging dev-lang/python. I can try
> and hack the spython package to get this to work, if you want.
> 

Hmm, it looks like our packages and python itself allways install the
complete
/usr/lib/python2.0 stuff no matter if I for example disable tcl/tk
support.
So we could do the following. The /usr/lib/python2.0 stuff comes only
with spython
The /usr/lib/python2.0/config stuff that is required for linking against
python comes
only with python. This whould resolve all overlappings and you are
allways sure you link with the
correct python config.

achim~

> Pete
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://www.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] portage-1.5_pre7

[drobbins]

On Fri, Mar 02, 2001 at 01:52:11AM +0100, Achim Gottinger wrote:

> Hmm, it looks like our packages and python itself allways install the
> complete /usr/lib/python2.0 stuff no matter if I for example disable tcl/tk
> support.  So we could do the following. The /usr/lib/python2.0 stuff comes
> only with spython The /usr/lib/python2.0/config stuff that is required for
> linking against python comes only with python. This whould resolve all
> overlappings and you are allways sure you link with the correct python
> config.

Well, if the /usr/lib/python2.0 from spython really is sufficient, then I
think this solution will work.

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] portage-1.5_pre7

[Philippe Namias]

Hi all,

Just for telling that i just emerge during all the weekend and nearly install 
all the package using emerge. So far with no problem.

But i have a few question :

Why after merging a packages we leave data in /tmp/portage/package_name ?

Is it normal that i can do emerge packgae_name as many time that i want ?

For example if i run it twice emerge on gtk-xemacs i run into trouble telling 
me xemacs can't find the root for data, lib. The only that i found to restore 
gtk-xemacs is to erase the directory  /var/db/packages/apps-editor/gtk-xemacs 
and also /tmp/portage/gtk-xemacs? Any idea?

Thanks
Philippe Namias


On Thursday 01 March 2001 23:03, you wrote:
> Hi all,
>
> I just committed sys-apps/portage-1.5_pre7, a brand new *test*
> version of Portage with recursive merging capability.
>
> Here's how to install it.  First, update your /usr/portage tree.
> Then, do the following:
>
> # cd /etc
> # rm make.conf.eg
> # rm make.defaults.eg
> (if they exist, that is)
>
> # cd /usr/portage/sys-apps/portage
> # ebuild portage-1.5_pre7.ebuild merge
>
> # cd /etc
> # ln -s /usr/portage/profiles/default make.profile
>
> The _beta_ recursive merging capability can be used as follows.
>
> # emerge --pretend foo-1.0.ebuild
>
> This will show you the ebuilds that will be merged to install this
> particular ebuild.  Build deps will be listed first, then runtime
> deps.  There may be duplicates in the runtime deps list; this is
> normal.  The package in question won't be installed twice, since
> this dependency will be satisfied by the time emerge gets to the
> runtime deps.  To do the "real" install:
>
> # emerge foo-1.0.ebuild
>
> :)))
>
> I'm currently using emerge on cvs.gentoo.org, with success.
> It will also work (not with full profile support yet) if you do
> this:
>
> # export ROOT=/mnt/gentoo
> # emerge foo-1.0.ebuild
>
> All build dependencies will be installed to "/" and all runtime
> dependencies will be installed to "/mnt/gentoo" :)))
>
> Enjoy,

Re: [gentoo-dev] portage-1.5_pre7

[drobbins]

On Mon, Mar 05, 2001 at 11:30:31AM +0100, Philippe Namias wrote:
> Hi all,
> 
> Just for telling that i just emerge during all the weekend and nearly install 
> all the package using emerge. So far with no problem.

Wonderful. :)

> But i have a few question :
> 
> Why after merging a packages we leave data in /tmp/portage/package_name ?

Right now, Portage works this way because it's been used by developers who
may need to look in /tmp/portage later to track down build problems.  Soon,
we'll have an "auto-cleanup" Portage option that will be on by default.

> Is it normal that i can do emerge packgae_name as many time that i want ?

For now, yes.  At some point soon, this will change. (When we add MULTIPLE
version management features)

> For example if i run it twice emerge on gtk-xemacs i run into trouble telling
> me xemacs can't find the root for data, lib. The only that i found to restore
> gtk-xemacs is to erase the directory  /var/db/packages/apps-editor/gtk-xemacs
> and also /tmp/portage/gtk-xemacs? Any idea?

Yes, I have an idea.  There was a bug in an earlier version of Portage where
the new files didn't get "touched" (so their mtimes were updated).  For many
packages, this caused the auto-unmerge to remove way too many things.  It's
been fixed now, so you may want to check to see if you're using the latest
version of ebuild.  Be careful, because Achim is having trouble with the most
recent version on CVS.  I'm working on an even more dramatically different
version right now on our server, and I'll commit it once I make sure that it's
working well.

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.			

[gentoo-dev] portage-1.5_pre7

[BoehmeSilvio]

Hi,

first of all: Gentoo is a great Linux distribution !!!

But now my question:

I have merged the *test* version of the new portage system.

Now, on each call to the portage-system ( pkgmerge... ) i receive:

"!!! Error: SYSPROFILEDIR/SYSPROFILE secify a non-existent profile"

Can someone help ?

Thanks

Silvio Boehme

Re: [gentoo-dev] portage-1.5_pre7

[drobbins]

On Fri, Mar 16, 2001 at 06:16:05PM +0100, BoehmeSilvio wrote:

> first of all: Gentoo is a great Linux distribution !!!

We think so too, thanks :)

> But now my question:
> 
> I have merged the *test* version of the new portage system.
> Now, on each call to the portage-system ( pkgmerge... ) i receive:
> "!!! Error: SYSPROFILEDIR/SYSPROFILE secify a non-existent profile"
> Can someone help ?

Yes, this is due to our beta system profile code.  For pre7, create a 
symlink from /etc/make.profile -> /usr/portage/profiles/default.
Then, move /etc/make.defaults to /etc/make.globals.

See if that helps.  We should have a better test version in a day or
two...

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.