Re: [aps-devel] From source?

[Robert Millan]

On Tue, Dec 31, 2002 at 02:02:48PM -0200, Lalo Martins wrote:
> (if any of this sounds confrontational, please take it with a grain of salt.
> I'm just trying to brainstorm here; if I wanted to be confrontational it
> would be much easier to leave and start my own, then engage in flamewars
> with you and your users about which one is better) ;-)

no problem, i always take things with some salt ;)

> This is the kind of project where you can't take too much risk.  I'm in
> favour of as much discussion, design and prototyping/experimentation as
> possible, so that when we really start we are 111% sure of what we're doing.

not exactly, most of the dessign isn't started yet but we do know some things.
mostly because of the ultra-modular dessign we already know the specs for
some of the modules. eg:

kitten - wolfgang started this already
unionfs - long ago
otherfs/whatever_you_call_it - doesn't seem hard so i'd like to start with this
gnunetfs - shouldn't be complicated if it clients the standard gnunet daemon

> > uhm.. shall i write a TODO?
> 
> I suggest the use of Savannah's task manager, and the bug tracker for
> planned features.

good.. i need to learn a lot on savannah yet ;)

> > Well I disagree with that, as think there are other solutions for problems
> > like SDL's (and i'm somewhat RISC-zealot ;)
> 
> Sorry, I don't understand what RISC has to do with it :-)

when one is a True Believer [tm] that the future is RISC it comes out
that compile optimisations are futile :)

but please let's not discuss on this ;)

> I would like to hear about your solutions and how they are better than
> building from source.

For our case there's also the advantage of trust (noone can sanely trust
binaries by themselves, without considering the builder's trust)

But i don't see why we need to decide to use either binaries or sources,
integration of binaries in Aps is simple and would work like this:

we have /gnunet/foo/1.0/i386/bin/foo

a translator that is part of Aps verifies its trust and provides it if
the verification is succesful:

/packages/foo/1.0/i386/bin/foo

unionfs, commanded somehow, adds it to / when the user wants to "install" it:

/bin/foo

If you want to dynamicaly build the package from source, you just have to
integrate it. For example by adding the adequate translator between unionfs
and /packages. (new todo item)

> I was talking about this with Knghtbrd (another former Debian developer of
> some fame), and we talked about how there could be a "public cache" of
> binary packages to speed up the most common builds (specially the huge,
> hairy stuff: gcc/libc for each architecture, perhaps in 3 or 4 flavours of
> hardware optimization, for example).  However, requiring each and every
> packager to build new binary packages every time there is an upstream
> release is, trust me on that, a sure cause of trouble.  If you want to be as
> big (in number of packages and people) as Debian, you will inherit its
> problems.

A valid solution would be that the packager uploads only source (or source
plus a single arch). then end users automaticaly build it for their own use
_and_ if they're at the time trusted developers their build is uploaded and
shared.

This way exhaustive and careless building for all arches is managed in
an anti-autoritarian, anarchic fashion. No need to run autobuilders, just
use your system and install stuff while your builds are automaticaly shared
(only for those who want it, of course)

> Simple (IMO) sollution: get source package from where it is usually
> distributed, unpack it somewhere temporary (/src? /var/gaps/src?), build,
> install into the package-specific filesystem (tree), then add it to unionfs.

That is a separate sollution, incompatible with using GNUnet for distribution.
my/our idea was that the package-specific tree is a "translated" result
of gathering network contents with GNUnet.

of course, you can gather sources from that.

> (The Linux port of aps would then need to manage installed files the way
> more "traditional" packaging systems do.  No big deal - not as cool as the
> Hurd alternative, but pretty straightforward).

this is not useful. we have dpkg already, which is very good in its context

> What form does the package take when under /packages?  A file?  A directory
> tree?  Containing what?  How are versions represented/managed?

we haven't specified this, but an example could be:

/packages/<package>/<version>/<arch>/<binary_tree>

> How does the user express the desire to install/update/remove a package?  By
> running a program, as usual?  What about installing right off CVS, is it
> possible at all?

every package should be updated automaticaly when the next version in archive
matches the trust criteria that the user requires.

for example, the equivalent of using "stable" would be to define a strict
criteria, and "unstable" a non-strict one.

it's possible to obtain it right off the cvs, for example it could be like:

/packages/<package>/cvs/<arch>/<binary_tree>

which has attached "cvsfs" (another todo item, go for it ;)). maybe trust
verification needs to be dropped for cvs, or it would work some other way.

in any case the frontend would just know that "cvs" is always the latest
version and use that to calculate upgrades.

> > > I'd like to plead for a ports/portage like system.
> 
> I maintain my unabated plead :-)

It's welcome! I explained what the backend framework would be like, if you
want a ports-like system you just need to write a module (in the form of
a translator) that does the job. All it should do is on every request build
the package from scratch, then cache the results for further requests.

note that this would likely be between /packages and /(unionfs)

well actualy we probably need that component anyway so you don't need to
ask for it ;)

> Sorry, in this case I don't understand what are you trying to build here.
> If all you want is a way to share files, you're raining on the ocean.
> 
> Your stated goal seems to be similar to Apt, right?  But Apt is useful
> because it is tied to dpkg's dependency, versioning, virtual package,
> configuration, etc system.  (If you don't believe me, go see how much the
> Apt port to RPM sucks.)

The goal is to create a tool that replaces both dpkg and apt. That tool would
be dessigned exploiting the Hurd's capabilities to allow developers
contributing anarchically (note i use anarchy as oposition to authority, not
as chaos or disorder), by evaluating trust in a democratic way.

It would also follow the previous ideas, like using unionfs to install
packages.

-- 
Robert Millan

"Omnis enim res, quad dando non deficit, dum habetur et non datur,
nondum habetur, quomodo habenda est."

"For if a thing is not diminished by being shared with others, it is
not rightly owned if it is only owned and not shared." 

                Aurelius Augustinus (354-430)