aps-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [aps-devel] From source?


From: Wolfgang Jaehrling
Subject: Re: [aps-devel] From source?
Date: Tue, 31 Dec 2002 18:53:32 +0100
User-agent: Mutt/1.3.28i

On Tue, Dec 31, 2002 at 12:56:53AM +0100, Robert Millan wrote:
> we have to discuss a lot of topics but because of the modularity of the
> project, some work can be started already. I think Wolfgang is working on a
> kitten translator currently.

Yes.  Although I did not compile the code I wrote for it yet. ;-)

> So if you want to install from source, for example we could have (why not?)
> a (slow) translator that builds a source package and provides the resulting
> files, while doing some form of local caching with the results.

I do not understand what you mean here.  Could you elaborate?  I am
particulary confused about what is the reason to let a translator
build something and why any kind of local caching is needed.

> Another idea that might be interesting would be to integrate the sources
> of a package in the same binary package tree, eg:
> 
> <package>/all/src/foo.c
> <package>/i386/bin/foo
> 
> Where <package>/all contains non-arch-specific files and <package>/i386
> contains files for i386. then the installer (unionfs or a derivative) would
> merge them together and get /src and /bin into the / hierrachy.

I am afraid that this bloats the packages a lot.  Remember that there
are people who cannot afford to download huge packages all the time.
And if you do not delete the unnecessary files anyway, you waste tons
of disk space as well.  So what is the point?

> > So, I'd like to inquire as to the other extremity of the process; so far you
> > have been talking about installing/updating/removing packages, unionfs etc.
> > But how do you get the package in the first place?

I don't think that getting packages is a major issue for getting the
package management _as a whole_ to work at all; doing it _right_ is a
different issue, which is mostly what Robert wants to do in APS, if I
am understanding him correctly.

> > I'd like to plead for a ports/portage like system.  If this is going to be
> > official GNU stuff, I suppose we could hook Guile into it (as I can't see
> > how such a system would work without scripting).
> 
> I guess Wolfgang had Guile in mind already :)

I always have Guile in my mind ;-) but I did not think of using it in
this situation yet.  I do not have a firm opinion on this issue,
because I do not know what kind of scripting we need exactly.  If
there is another language that has the necessary abstractions for this
job (I'm particulary thinking of Bash here), but Guile does not have
them, we probably shouldn't use Guile.  In every other case, it sounds
like a good plan to use it.

> > It strikes me that building official GNU software is straightforward due to
> > the Coding Standards; we have a more or less hard guarantee that "cd foo;
> > ./configure; make; make install prefix=/tmp_fs_something" does the trick.
> > However I would like to have a facility similar to portage's USE switches,
> > if possible hooked right into configure's --with/--enable.

I am not familiar with USE switches, though I have an idea of what
they might do.  Could you quickly explain them or provide a link to a
description?

> yes, but distribution building is a separate issue. for what Aps is concerned
> it should be provided a signed package (either binary or source), incorporate
> it into the archive, and being fetched by end users after its trust being
> checked.
> 
> so you can use any building interface with Aps. for example nothing would stop
> you from taking debian packages or gentoo ports into Aps and building a
> debian-based or gentoo-based distribution.

But for the GNU system, we do need a building framework as well.

Cheers,
GNU/Wolfgang



reply via email to

[Prev in Thread] Current Thread [Next in Thread]