Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Teh Future

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Ismael Luceno <ismael.luceno AT gmail.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Teh Future
  • Date: Tue, 9 Apr 2013 00:26:45 -0300

On Fri, 25 Jan 2013 17:27:54 -0600
David Kowis <dkowis AT shlrm.org> wrote:
> Single spell file:
> ------------------
> Opening 6 files is difficult. Opening one file is easy. I can
> maintain a much better context regarding what my variable names are,
> and what I'm going to do with them. There's no reason we *must* split
> things up into many files, and I don't think there's any benefit to
> it. I believe this is a change we must implement.

I think some unification is good, but it's not for everything.

Configuration and meta-data are good candidates for unification into
one file, while build steps into another.

Also, it would be a good idea to move descriptions into single file for
the whole grimoire. It would make search way more efficient, and
doesn't add any complications.

> Core grimoire:
> --------------
> We need to pare down the amount of stuff that is well supported. We
> don't have enough manpower to take care of all the things. The Core
> grimoire will provide binary packages of the things we support. Those
> configs are what we support. This way we can guarantee that someone
> will be able to get a working system fired up based on the configs
> we've got. We should have no problem supporting configs for i686 as
> well as x86_64 eventually, but we can target only one for the
> beginning.

+1. Would that imply splitting the main grimoire?

> Chroot based build process:
> ---------------------------
> For building binary packages, I want to take advantage of a chroot and
> unionfs (or rsync and hardlinks or something.) Inspiration from this
> page:
> https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot
> It's probably the sanest way to produce a package that we can ensure
> isn't melding in dependencies we don't want and such. By ensuring that
> we build things into binary packages as well, we can catch leaky
> installs, or missing dependencies when we're building the chain of
> packages. Additionally, it'll give the system itself protection from a
> stupid installer doing bad things, or a partially failed install.

May I suggest using sysroot? I tried it a few times and it worked fine.

We should do unprivileged builds and install with DESTDIR. And for the
very few spells that require it, we could use fakeroot.

It's way simpler.

<...>

I agree with the rest.

Attachment: signature.asc
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page