dufflebunk at dufflebunk.homeip.net
Thu Jul 25 12:02:36 EDT 2002
On Thu, 2002-07-25 at 09:51, Sergey A. Lipnevich wrote:
> I still think tempfs is a very elegant solution to many
> problems (disk clean-up, /tmp using my otherwise unused
> most of the time swap partition, performance still
> there), but that's not the point. Why are we discussing
> what to change when there's a whole slew of sorcery
> functions to implement to be feature-complete for 1.0?
> Phil/CERisE/KG6MBQ <cerise at littlegreenmen.armory.com>:
> > Julian v. Bock said:
> > > I like it because my fs doesn't get filled with the
> remains of failed
> > > compiles. After a reboot everything is gone, and if
> I want to
> > > clean up manually all I have to do is the following:
> > >
> > > cd /usr/src
> > > umount *
> > > rmdir *
> > >
> > > This leaves the kernel dir / link intact.
> > I can think of a couple of work arounds. You
> could chroot into a
> > directory and install things to the appropriate
> places. You could then
> > relink things accordingly.
> > You could create a new directory as you would with
> tempfs and
> > do all sorcery related work within it. You could
> then delete leftovers
> > accordingly.
> > You could have a temporary file mounted as a
> loopback and do all
> > work in there.
> > The important part here is that Sorcery as a good
> packaging system
> > should clean up after itself. Tempfs is a simple
> idea thrown at a
> > problem. I believe that the benchmarks have bourne
> out that using the
> > native filesystem may be a better idea.
> > I don't believe that having Sorcery clean up after
> itself and
> > having Sorcery use the native filesystem are mutually
> > -Phil/CERisE
> SM-Discuss mailing list
> SM-Discuss at lists.ibiblio.org
Quidquid latine dictum sit, altum sonatur.
PGP public key at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 232 bytes
Desc: This is a digitally signed message part
Url : http://lists.ibiblio.org/pipermail/sm-discuss/attachments/20020725/bfecb9d3/attachment.bin
More information about the SM-Discuss