[gentoo-osx] [PREFIX] Renaming of ${DEST}

[gentoo-osx] [PREFIX] Renaming of ${DEST}

[Kito]

Howdy,

	I forgot to mention this at the meeting. I found a few packages (not  
in portage currently thankfully) that have namespace collisions with  
the ${DEST} var. My thought is to change it to ${DD}, as in 'DESTDIR'.

Thoughts? Better idea for a name?

Say the word and I'll make the change in the next snapshot and  
cleanup the ebuild repo.

--Kito




-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] [PREFIX] Renaming of ${DEST}

[Grobian]

On 19-03-2006 16:13:19 -0600, Kito wrote:
> Howdy,
> 
> 	I forgot to mention this at the meeting. I found a few packages (not in 
> portage currently thankfully) that have namespace collisions with the ${DEST} 
> var. My thought is to change it to ${DD}, as in 'DESTDIR'.
> 
> Thoughts? Better idea for a name?

The only thing that comes to my mind as alternative is "${EDEST}".
Might be slightly more self-explanatory.  I don't care much about which
of the two it will become, as long as the change is done atomic ;)


-- 
Fabian Groffen
Gentoo for Mac OS X Project
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-alt] Re: [gentoo-osx] [PREFIX] Renaming of ${DEST}

[Grobian]

On a related note:
What about using ${EPREFIX} instead of ${PREFIX}?  ${PREFIX} at least
clashes with the toolchain-funcs eclass, and might as well be used by
other packages.

Does it make sense to anyone?


On 20-03-2006 09:19:03 +0100, Grobian wrote:
> On 19-03-2006 16:13:19 -0600, Kito wrote:
> > Howdy,
> > 
> > 	I forgot to mention this at the meeting. I found a few packages (not in 
> > portage currently thankfully) that have namespace collisions with the ${DEST} 
> > var. My thought is to change it to ${DD}, as in 'DESTDIR'.
> > 
> > Thoughts? Better idea for a name?
> 
> The only thing that comes to my mind as alternative is "${EDEST}".
> Might be slightly more self-explanatory.  I don't care much about which
> of the two it will become, as long as the change is done atomic ;)
> 
> 

-- 
Fabian Groffen
Gentoo for Mac OS X Project
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-alt] Re: [gentoo-osx] [PREFIX] Renaming of ${DEST}

[Michael Haubenwallner]

Hi,

related to renaming things:

Have there been any more thoughts or even implementations to [1]
about having a function to query the prefix of a required package ?

My first goal are not the interdomain-deps, but to have a portage-
feature to install each non-system-package into a separate subdir within
the same portage-domain.

[1] http://thread.gmane.org/gmane.linux.gentoo.macosx/809

-- haubi

On Wed, 2006-03-22 at 12:47 +0100, Grobian wrote:
> On a related note:
> What about using ${EPREFIX} instead of ${PREFIX}?  ${PREFIX} at least
> clashes with the toolchain-funcs eclass, and might as well be used by
> other packages.
> 
> Does it make sense to anyone?
> 
> 
> On 20-03-2006 09:19:03 +0100, Grobian wrote:
> > On 19-03-2006 16:13:19 -0600, Kito wrote:
> > > Howdy,
> > > 
> > > 	I forgot to mention this at the meeting. I found a few packages (not in 
> > > portage currently thankfully) that have namespace collisions with the ${DEST} 
> > > var. My thought is to change it to ${DD}, as in 'DESTDIR'.
> > > 
> > > Thoughts? Better idea for a name?
> > 
> > The only thing that comes to my mind as alternative is "${EDEST}".
> > Might be slightly more self-explanatory.  I don't care much about which
> > of the two it will become, as long as the change is done atomic ;)
> > 
> > 
> 
> -- 
> Fabian Groffen
> Gentoo for Mac OS X Project

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-alt] Re: [gentoo-osx] [PREFIX] Renaming of ${DEST}

[Kito]

On Mar 22, 2006, at 9:30 AM, Michael Haubenwallner wrote:

> Hi,
>
> related to renaming things:
>
> Have there been any more thoughts or even implementations to [1]
> about having a function to query the prefix of a required package ?

Thoughts for sure, no implementation yet though. My fear is this  
would bring in many of the problems of interdomain stuff if we did it  
'right'. i.e. repo-ids, etc. But perhaps I'm making it more complex  
than need be, some extra data stored in the vdb and a simple lookup  
tool could 'just work'. I think along with just being able to find  
the filesystem location of a package, we might as well go all the way  
and basically do an internal pkgconfig clone. This would allow stuff  
like:

	DEPEND="<my-dependency-2"

	econf-or-src_compile() {
	    .../configure \
  	       --prefix=$(eprefix) \
	        --with-my-dependency=$(eprefix "<my-dependency-2")

	    append-flags $(eprefix --cflags "<my-dependency-2")
	    append-ldflags $(eprifix --libs "<my-dependency-2")
	}

Maybe...

>
> My first goal are not the interdomain-deps, but to have a portage-
> feature to install each non-system-package into a separate subdir  
> within
> the same portage-domain.

Some of this would definitely overlap with some of the features Dirk  
has asked for, i.e. merging a package to a selfcontained dir for  
public distribution, self-contained OS X frameworks, etc.

Its a good idea, IMHO, but will be awhile  before I personally will  
start hacking on it. Others are welcome to give it a go =)

>
> [1] http://thread.gmane.org/gmane.linux.gentoo.macosx/809
>
> -- haubi
>
> On Wed, 2006-03-22 at 12:47 +0100, Grobian wrote:
>> On a related note:
>> What about using ${EPREFIX} instead of ${PREFIX}?  ${PREFIX} at least
>> clashes with the toolchain-funcs eclass, and might as well be used by
>> other packages.
>>
>> Does it make sense to anyone?
>>
>>
>> On 20-03-2006 09:19:03 +0100, Grobian wrote:
>>> On 19-03-2006 16:13:19 -0600, Kito wrote:
>>>> Howdy,
>>>>
>>>> 	I forgot to mention this at the meeting. I found a few packages  
>>>> (not in
>>>> portage currently thankfully) that have namespace collisions  
>>>> with the ${DEST}
>>>> var. My thought is to change it to ${DD}, as in 'DESTDIR'.
>>>>
>>>> Thoughts? Better idea for a name?
>>>
>>> The only thing that comes to my mind as alternative is "${EDEST}".
>>> Might be slightly more self-explanatory.  I don't care much about  
>>> which
>>> of the two it will become, as long as the change is done atomic ;)
>>>
>>>
>>
>> -- 
>> Fabian Groffen
>> Gentoo for Mac OS X Project
>
> -- 
> gentoo-osx@gentoo.org mailing list
>

--Kito




-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-alt] Re: [gentoo-osx] [PREFIX] Renaming of ${DEST}

[Kito]

On Mar 22, 2006, at 5:47 AM, Grobian wrote:

> On a related note:
> What about using ${EPREFIX} instead of ${PREFIX}?  ${PREFIX} at least
> clashes with the toolchain-funcs eclass, and might as well be used by
> other packages.
>
> Does it make sense to anyone?

Yeap, I was thinking about this too. It should be done. Maybe we can  
tackle both of these this weekend.

--Kito




-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-alt] Re: [gentoo-osx] [PREFIX] Renaming of ${DEST}

[Grobian]

On 22-03-2006 11:03:09 -0600, Kito wrote:
> On Mar 22, 2006, at 5:47 AM, Grobian wrote:
> >What about using ${EPREFIX} instead of ${PREFIX}?  ${PREFIX} at least

> Yeap, I was thinking about this too. It should be done. Maybe we can tackle 
> both of these this weekend.

You should at least tackle both at once, IMO ;)
I can help with changing ebuilds/eclasses, as I'm currently in a fight
with binutils, gcc and glibc anyway.


-- 
Fabian Groffen
Gentoo for Mac OS X Project
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-alt] Re: [gentoo-osx] [PREFIX] Renaming of ${DEST}

[Kito]

On Mar 22, 2006, at 11:07 AM, Grobian wrote:

> On 22-03-2006 11:03:09 -0600, Kito wrote:
>> On Mar 22, 2006, at 5:47 AM, Grobian wrote:
>>> What about using ${EPREFIX} instead of ${PREFIX}?  ${PREFIX} at  
>>> least
>
>> Yeap, I was thinking about this too. It should be done. Maybe we  
>> can tackle
>> both of these this weekend.
>
> You should at least tackle both at once, IMO ;)

FINE! I'll start checking in the portage changes to svn. That being  
said, in case any of you are in the habit of running the svn version,  
it'll be broken for a bit.

> I can help with changing ebuilds/eclasses, as I'm currently in a fight
> with binutils, gcc and glibc anyway.

Ok, why don't you keep all your changes local and we'll try to  
coordinate a big atomic commit this weekend perhaps?

--Kito




-- 
gentoo-osx@gentoo.org mailing list

[gentoo-osx] [PREFIX] Freeze of the prefixed portage tree

[Grobian]

On 22-03-2006 11:26:24 -0600, Kito wrote:
> FINE! I'll start checking in the portage changes to svn. That being said, in 
> case any of you are in the habit of running the svn version, it'll be broken 
> for a bit.
> 
> >I can help with changing ebuilds/eclasses, as I'm currently in a fight
> >with binutils, gcc and glibc anyway.
> 
> Ok, why don't you keep all your changes local and we'll try to
> coordinate a big atomic commit this weekend perhaps?

Ok, this is an official warning to all people using the prefixed portage
tree:

!!! The tree is from now on FROZEN !!!

Please DO NOT commit to the prefixed portage tree to allow those that
develop on prefixed portage to change the tree and test whether it works
as expected.

Kito will coordinate this process and he will decide when the tree gets
unfrozen again.  For all questions, urgent matters, etc. contact kito.


-- 
Fabian Groffen
Gentoo for Mac OS X Project
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] [PREFIX] Freeze of the prefixed portage tree

[Kito]

On Mar 22, 2006, at 12:03 PM, Grobian wrote:

> On 22-03-2006 11:26:24 -0600, Kito wrote:
>> FINE! I'll start checking in the portage changes to svn. That  
>> being said, in
>> case any of you are in the habit of running the svn version, it'll  
>> be broken
>> for a bit.
>>
>>> I can help with changing ebuilds/eclasses, as I'm currently in a  
>>> fight
>>> with binutils, gcc and glibc anyway.

Ok, I've done what 'looked' right in svn, but I haven't touched  
binutils-config yet.

>>
>> Ok, why don't you keep all your changes local and we'll try to
>> coordinate a big atomic commit this weekend perhaps?
>
> Ok, this is an official warning to all people using the prefixed  
> portage
> tree:
>
> !!! The tree is from now on FROZEN !!!

!!! The tree is from now on UNFROZEN !!!

woot.

>
> Please DO NOT commit to the prefixed portage tree to allow those that
> develop on prefixed portage to change the tree and test whether it  
> works
> as expected.

Ok, its ready for testing now. A few notes:
	

	• the --with-rootuid option to configure has been removed, just use  
--with-rootuser
	• If you have an existing prefix install, you will have to upgrade  
portage manually from the tarball[1]. See the wiki[2] for quick  
pseudo-instructions.
	• If you have the hack in bashrc to append PREFIX to ROOT, take it  
out. ROOT should behave correctly now.
	• The portage ebuild will respect the following envvars:
		--with-user=${PORTAGE_USER:-portage} \
         	--with-group=${PORTAGE_GROUP:-portage} \
         	--with-rootuser=${PORTAGE_INST_USER:-root} \
        	 	--with-wheelgid=${PORTAGE_INST_GID:-0} \
         	--with-offset-prefix=${EPREFIX}
	• ${EDEST} is the package build image dir, without the appended prefix
	• ${EPREFIX} is the 'offset-prefix' i.e. /opt/gentoo, /Library/Gentoo
	• ${ROOT} in ebuilds should handle ${EPREFIX} transparently
	• The current portage snapshot is using the experimental Manifest2  
format.
>
> Kito will coordinate this process and he will decide when the tree  
> gets
> unfrozen again.  For all questions, urgent matters, etc. contact kito.

That was enough for me. For all further breakage, consult Fabian :p

--Kito

[1] http://dev.gentoo.org/~kito/distfiles/portage-prefix-latest.tar.bz2
[2] http://gentoo-wiki.com/Portage-prefix




-- 
gentoo-osx@gentoo.org mailing list