[gentoo-dev] Using stow inside portage

[gentoo-dev] Using stow inside portage

[Chris Frey]

Hello friendly developers,

I looked briefly at the emerge build scripts, and it seems to me that it
would be fairly easy to incorporate the usage of stow inside the
portage system.

econf() would need to be changed to read the --prefix directory from
a portage-stow configuration file, and tack on the name of the package
with version.

install and uninstall would need to be changed to call stow and stow -D
if stow was in the USE flags.

This would allow people to maintain different versions of the same
application on their systems at the same time.  Just stow/unstow at will
to switch.

I'm sure there are ebuilds that don't rely completely on econf() and
friends, and these would be harder to update.  Is there anything else
I'm missing?

Thanks,
- Chris


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Using stow inside portage

[Mike Frysinger]

On Sunday 18 July 2004 02:23 am, Chris Frey wrote:
> I'm sure there are ebuilds that don't rely completely on econf() and
> friends, and these would be harder to update.  Is there anything else
> I'm missing?

why bloat econf ?
an eclass sounds better ... `stow-eclass` ...

then again i know nothing of stow except for what i've read in your e-mail :)
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Using stow inside portage

[Andrew Ross]

On Sun, 2004-07-18 at 16:23, Chris Frey wrote:
> I looked briefly at the emerge build scripts, and it seems to me that it
> would be fairly easy to incorporate the usage of stow inside the
> portage system.

Are you talking about this (http://www.gnu.org/software/stow/stow.html)?

> econf() would need to be changed to read the --prefix directory from
> a portage-stow configuration file, and tack on the name of the package
> with version.
> 
> install and uninstall would need to be changed to call stow and stow -D
> if stow was in the USE flags.

I agree with vapier that an eclass would be the best way to implement
stow support. However, optional eclass inheritence makes DEPEND and IUSE
dynamic, which, IIRC, is currently a big no-no.

> This would allow people to maintain different versions of the same
> application on their systems at the same time.  Just stow/unstow at will
> to switch.

Isn't that the purpose of SLOTs?

Cheers

Andrew



--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Using stow inside portage

[Chris Frey]

On Sun, Jul 18, 2004 at 05:14:14PM +1000, Andrew Ross wrote:
> Are you talking about this (http://www.gnu.org/software/stow/stow.html)?

Yep, exactly.

> I agree with vapier that an eclass would be the best way to implement
> stow support. However, optional eclass inheritence makes DEPEND and IUSE
> dynamic, which, IIRC, is currently a big no-no.

Ok, haven't heard of an eclass, so will have to read up.

> > This would allow people to maintain different versions of the same
> > application on their systems at the same time.  Just stow/unstow at will
> > to switch.
> 
> Isn't that the purpose of SLOTs?

Yes, and that's how some of the gcc's are done.  Unfortunately, slots seem
to require developer resources to make work, and therefore aren't done
on a consistent basis.  I.e. not all of the gcc's are slot-enabled, let
alone KDE or Gnome or mozilla, etc.

I figured this would be an architecture variable, and would require much
less developer effort, and be pretty much system-wide.

Thanks for the reply!
- Chris


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Using stow inside portage

[foser]

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

On Sun, 2004-07-18 at 10:50 -0400, Chris Frey wrote:
> > Isn't that the purpose of SLOTs?
> 
> Yes, and that's how some of the gcc's are done.  Unfortunately, slots seem
> to require developer resources to make work, and therefore aren't done
> on a consistent basis.  I.e. not all of the gcc's are slot-enabled, let
> alone KDE or Gnome or mozilla, etc.

Well, that's not really the purpose, SLOTs were meant to install
packages that are _upstream_ parallel installable. Afaik SLOTting in
Gentoo is consistent with most upstream releases.

You can redefine SLOT to do stow like stuff (afaik KDE in Gentoo does
this with different qt minor versions (?) & gcc), but I'm actually not a
big fan of that sort of constructions that do not comply with upstream
intent for no-good reasons : it's just great to have every mozilla
release on your system at the same time, but it serves no purpose (to
get back to your example). Adding global support for this will probably
lead to weird problems concerning libversion mismatching etc. .

- foser

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

[gentoo-dev] Re: Using stow inside portage

[Chris Frey]

On Sun, Jul 18, 2004 at 08:22:36PM +0200, foser wrote:
> You can redefine SLOT to do stow like stuff (afaik KDE in Gentoo does
> this with different qt minor versions (?) & gcc), but I'm actually not a
> big fan of that sort of constructions that do not comply with upstream
> intent for no-good reasons : it's just great to have every mozilla
> release on your system at the same time, but it serves no purpose (to
> get back to your example). Adding global support for this will probably
> lead to weird problems concerning libversion mismatching etc. .

It does serve a purpose.  It allows for painless testing of bleeding edge
software without completely giving up your current setup.

Library versions already have a versioning system and can coexist, so I
didn't envision stow being used much for pure libraries.  Stuff like
running XFree86 and xorg would be nice, though.

- Chris


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Using stow inside portage

[Martin Schlemmer]

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

On Sun, 2004-07-18 at 20:22, foser wrote:
> On Sun, 2004-07-18 at 10:50 -0400, Chris Frey wrote:
> > > Isn't that the purpose of SLOTs?
> > 
> > Yes, and that's how some of the gcc's are done.  Unfortunately, slots seem
> > to require developer resources to make work, and therefore aren't done
> > on a consistent basis.  I.e. not all of the gcc's are slot-enabled, let
> > alone KDE or Gnome or mozilla, etc.
> 
> Well, that's not really the purpose, SLOTs were meant to install
> packages that are _upstream_ parallel installable. Afaik SLOTting in
> Gentoo is consistent with most upstream releases.
> 

Yes, but I will define it more as a way to support new releases
that breaks binary compatibility.  This definition should envelope
kde, gnome, gcc, etc ...  Note that for things like kde and gcc for
instance (gnome does it properly - or more so) it is not 100%
supported upstream.

-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



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