aps-devel
[Top][All Lists]
Advanced

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

Re: [aps-devel] From source?


From: Lalo Martins
Subject: Re: [aps-devel] From source?
Date: Tue, 31 Dec 2002 14:02:48 -0200
User-agent: Mutt/1.4i

(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) ;-)

On Tue, Dec 31, 2002 at 12:56:53AM +0100, Robert Millan wrote:
> On Mon, Dec 30, 2002 at 05:49:32PM -0200, Lalo Martins wrote:
> 
> that's great. but this is quite stopped for now..
>(...)
> oh, and i'm very busy at the moment. probably next summer i'll have time to
> take it on seriously.

Np, I have other priorities too ATM.  Around summer I can set aside some
time if we agree this is the time for implementation.

> 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. I'd like to start writing a simple component
> as i need to learn a lot about Hurd interfaces yet.

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.

> uhm.. shall i write a TODO?

I suggest the use of Savannah's task manager, and the bug tracker for
planned features.

> > Now I switched to Gentoo
> > and I'm convinced ports-like "from source" pkg systems are the only
> > reasonable way to distribute/manage modern Free Software (for an example of
> > what I mean, check how many .debs there are for SDL: one compiled for arts,
> > one for oss, one for osd, one with everything plus a dummy package).
> 
> 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 :-)

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

Have you ever been an user of a source-only packaging system - for example,
Gentoo or Free/Open/NetBSD?  I took about two weeks of actual real-life use
to start realizing the advantages.  Here are the ones I think are more
relevant for us (for brevity, let's use the term "packager" for the person
who maintains a package):

1: less pressure on the packagers.  You don't have to build N binary package
files, just a (guile) script that builds the stuff.  As a former Debian
packager, I can assure you that this is no light issue.

2: customizability.  The user decides the exact build options (as in the
example I gave of SDL).  In a binary distribution you can in the best case
have many available choices of combination (again, as in my example) - but
exactly which ones, it's again up to the packager, not the user. Combining
this with item 1: a package like this one is an even bigger burden.

2.5: (sub-item of 2) optimization.  The reason a few people I know use
Gentoo is the ability to tweak compilation to the point of optimizing for
your hardware.  I have everything here, from kernel/gcc to gnome/mozilla,
optimized for my exact processor version.

3: portability.  Once kernel/libc/gcc are ported, the package tree can just
be imported and is ready to rock.  (Ok, some packages may have port-related
bugs, like endianess, etc - but that is not the packager's problem.)  For
example, a single source package tree could serve this "distro" for
ia32-linux-gnu and ia32-hurd-gnu.

4: tweakability.  It is much easier to put your own "hacked" version of the
software under the package system's control.  I do this all the time here.
`ebuild unpack foo.ebuild; hack /var/tmp/portage/foo-xxx/work/foo-xxx;
ebuild merge foo-xxx.ebuild` and as far as Portage is concerned, I just
installed foo version xxx.

5: (arguable) philosophy.  Such a distribution is (2.5, 3) available for
everyone regardless of hardware and (4) gives incentive to hacking.  IMVHO
this makes it feel more GNUish.  Also, it operates on the assumption that
the sources are available somewhere, without even considering for a second
that sometimes they aren't.

The single downside is that installing packages is much slower.

(Ok, it could be argued that it also requires a bigger "base" system - you
need at least a sane development environment to install stuff.)

> But i don't think Aps should be dependant on using only binaries, or only
> source (actualy when we start to use it and the trust web is not strong
> enough we'll be forced to use sources), but rather have both options.

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.

> 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.
> 
> Another idea that might be interesting would be to integrate the sources
> of a package in the same binary package tree, eg:

Sorry, IMVHO both alternatives sound like an uncalled-for abuse of the
concept of translations, and unnecessary extra work.

If something is free software, then presumably there is already a source
distribution *somewhere* (in the case of GNU, ftp.gnu.org mirrors).  Heck,
the user may even want to build from CVS.  (Or setup cron to do it every X
days... that's what I call courage)

Also, sharing the source tree makes it unnecessarily harder to hack it.

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.

(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).

> > 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?
> 
> You mean the user or the developer?

The user gets the package.  The developer provides it. ;-)

> If you mean the user, he/she'd have the package in his/her filesystem 
> hierracy,
> in /packages, then the combined translators of Aps would provide the package
> from GNUnet when asked, after verifying it's a trusted package.
I don't feel answered.

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

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?

> > I'd like to plead for a ports/portage like system.

I maintain my unabated plead :-)

> 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.

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.)


[]s,
                                               |alo
                                               +----
--
            Those who trade freedom for security
               lose both and deserve neither.
--
http://www.laranja.org/                mailto:address@hidden
         pgp key: http://www.laranja.org/pessoal/pgp

Eu jogo RPG! (I play RPG)         http://www.eujogorpg.com.br/
GNU: never give up freedom                 http://www.gnu.org/



reply via email to

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