On Wed, 2008-03-26 at 09:17 -0500, Andrew Gaffney wrote:
> Philipp Riegger wrote:
> > • Squashfs snapshot support
> > I don't like it, that it takes so much time to unpack a new snapshot and
> > it takes so much disk space to store it. Plan is: distribute tree
> > snapshots as squashfs images, mount them directly into the workdir,
> > use /mnt/distfiles and /mnt/packages instead of snapshot subdirectories.
>
> Eh, I've never found unpacking a new snapshot to be all that cumbersome. While
> it probably wouldn't take much to implement this, I don't like the idea. At
> least, I'd never use it, since it would remove the ability to poke around in the
> snapshot_cache.
Well, i've been playing around with different snapshots over time and
i've also been renaming the snapshot with each change to be able to undo
a change. But in times of source control management, this should be
unnecessary.
The main point here seems to be, that we use catalyst in completely
different ways. While i see /var/tmp only as catalysts working dir you
work there. I usually try to do my change in the tree or overlay, tar
it, copy it to /var/tmp and restart catalyst.
> > • (Squashfs seedstage support)
> > Maybe the same is possible for stages? A future plan for this could be
> > to mount the squashfs image directly and use unionfs for the real work,
> > but i have no idea how deleting files in such a setup works. Research is
> > necessary here.
>
> This isn't really feasible.
Do you mean in the way of "doable" or "usable"? I'm thinking of
diskspace and speed, again.
> > • uclibc-cross-compiling support
> > Cross compiling is hard, but it should be possible to build arch-uclibc
> > from arch. Research, what needs to be done combined with the
> > implementation, if possible. This would also make GNAP more flexible.
>
> If you want a uclibc stage, use a profile that has uclibc as the default
> virtual/libc provider.
Is that possible? Last time i checked, i needed an uclibc seedstage,
because otherwise catalyst wanted to build uclibc on a glibc system and
they were blocking each other.
> > • (Code cleanups)
> > I write this everywhere, but since i need a basic understanding, i have
> > to read (parts of) the source and maybe i find something worth
> > improving.
>
> Catalyst is definitely in need of code cleanups. However, that's just a result
> of a codebase that's changed hands multiple times over many years. We do random
> cleanups already as we encounter code that needs it.
So this might be an interesting task, which you would support? Or do you
think, it's already done all the time, this is not needed?
> > • Cross compiling research
> > This is the continuation of the uclibc stuff with some plans on what
> > could be done how.
>
> Like I said on IRC, this is vapier's territory.
But if we keep it like that, it's questionable when it will be done.
Maybe someone should look into vapiers thoughts and plans and work on
that.
Philipp
--
gentoo-catalyst@g.o mailing list
|
