Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Castfs usage

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Treeve Jelbert <treeve AT scarlet.be>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Castfs usage
  • Date: Fri, 27 Nov 2009 09:05:40 +0100

On Thursday 26 November 2009 20:00:02 Thomas Orgis wrote:
> Am Thu, 26 Nov 2009 13:25:59 +0100 (CET)
>
> schrieb Andraž 'ruskie' Levstik <ruskie AT codemages.net>:
> > I still see some people not using castfs. I'd like to know why? And I'd
> > like to RFC if people think it would be good to make this a required
> > dependency now.
>
> My thoughts about castfs:
>
> 1. It's a good idea, basically. In fact, intercepting the install
> routines of spells in a reliable way like that is a prerequisite to be
> taken serious for a source distro, IMHO.
>
> 2. I wonder what it's state is... I have the fear that it's
> bitrotting... dmlb2000 isn't around, is he?
>
> 3. It should do more. We really need combined castfs, one fs overlay
> that casting of multiple spells takes place in. Merging of the changes
> in the castfs to the system at the user's leisure, minimizing possible
> downtime because some stuff needs to be updated together. Also, are we
> serious with dispelling kdelibs before casting kdelibs? That's serious


the reason for dispelling things like qt4 and kdelibs is that the configure
stage sometimes finds and uses existing libraries. Then, during the install
phase, they have disappeared and the spell spends a lot of time rebuilding
things, or sometimes fails completely..

I have tried to remove this behaviour, but it usally failed.

However, this gives me an idea:
I could try to remove the KDE libraries from LDPATH, before casting kdelibs.
That might work.

> breakage and downtime while building large chunks of software. Dispels
> should happen in the castfs only, not affecting the real system,
> generally, and especially in such a case where a dispel is done before
> a cast suceeds. Similar (and even worse considering build times) would
> be the situation with gcc update, leaving g++ and gfortran broken for
> some time, but that is managed with the merged gcc spell nowadays.
>
> 4. I would like to have time to help improving it (along with fixing
> the user account stuff of SMGL), but I dont. There are other projects
> in the queue.
>
> 5. I would be OK with offering choice between castfs for file tracking
> or no file tracking at all. The latter option is still needed to
> bootstrap SMGL on some syste that may lack support for castfs. For that
> purpose, though, we cannot drop INSTALL_ROOT ... but possibly it's
> needed anyway for stuff like installing in another prefix without
> chroot intentions.
>
>
> My 5 cents,
>
> Thomas.
>

--
Regards, Treeve

Attachment: signature.asc
Description: This is a digitally signed message part.




Archive powered by MHonArc 2.6.24.

Top of Page