Gentoo Archives: gnap-dev

From: "josé Alberto Suárez López" <bass@g.o>
To: gnap-dev@l.g.o
Subject: Re: [gnap-dev] [RFC] Summer of Code Proposal: GNAP Love
Date: Wed, 26 Mar 2008 13:19:13
Message-Id: 1206537543.15053.9.camel@supercoco
In Reply to: [gnap-dev] [RFC] Summer of Code Proposal: GNAP Love by Philipp Riegger
hi :)

as we talked before...

El mié, 26-03-2008 a las 13:57 +0100, Philipp Riegger escribió:
> Good morning, > > I have some ideas for Summer of Code which i'd like to discuss with you.
new ideas ever welcome
> I'm mostly interested in making GNAP usable and my proposal includes > lots of tasks in GNAP and catalyst, of which i'd like to finish as many > as possible and do some research on the rest. > > catalyst tasks: > > • 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.
i like this can be usefull, the problem is how mcuh espace you need to redistribute all sources we need (not only gnap-core srcs, i mean extensions srcs too)
> • (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.
i dont understand it well
> • 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.
this will be one of the biggest features so as you know is hard.
> • Documentation > In an email from some days ago i read, that documentation is planed for > after the release. I could support this and proofread it, since i need > the knowledge anyway.
you mean gnap doc or catalyst doc?
> • (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.
ever welcome :)
> • Cross compiling research > This is the continuation of the uclibc stuff with some plans on what > could be done how. > > • Non-root builds research > Wouldn't it be nice if being root was not necessary for using catalyst? > I would like to look into the possibilities there and what is needed to > make it reality.
i think that is hard, you dont need root only for catalyst, other GNAP operations need to be root.
> GNAP tasks: > > • Code/Tree hosting, VCS > I've done some work last year and that does only exist as some patches, > since there is no central repository for GNAP development. First i'd > like to establish one and move all existing resources there.
yes, what about your google-code testing?
> • GNAP 2.1 > There are some known and easy to fix bugs in GNAP 2.0. There have also > been some code cleanups. The last thing is, that the current GNAP is not > really usable, since the tree snapshot is so old, that most of the > distfiles are not fetchable from mirrors or other places. So i'd like to > make a new release, be it in the tree or in an overlay.
you are right, but first we need and updated tree
> • Reimplementation in python research > Catalyst is written in python, maybe we could make better use of it if > we reimplemented some parts of GNAP in python? This is just a research > item, i'd like to look into it and form some statement about it. I'll > probably not do it.
i prefer to keep bash
> • uclibc-cross-compiling support > This depends on catalyst. > > • (Cross-compiling support) > My last years project. My thoughts/plans about that should be discussed > with the community and put on the GNAP development website. > > • GNAP releases, long term support > This is just an idea i have. Think of something like this: With each > gentoo release, we take the release snapshot, form our reduced GNAP > snapshot (only supported profiles, unsupported USE flags masked, > unneeded ebuilds (X, desktop stuff) not in the tree) and support it for > some time security wise (like the releng team does during release). This > is more of a research topic, with informing what needs to be done, > writing of scripts, maybe doing a proof of concept (maintaining a > snapshot for some weeks to see how it works).
-- gnap-dev@l.g.o mailing list


Subject Author
Re: [gnap-dev] [RFC] Summer of Code Proposal: GNAP Love Philipp Riegger <lists@××××××××××××.de>