[gobolinux-users] Re: Compiling Glibc 2.3.6
Carlo Calica
carlo at calica.com
Wed May 17 06:31:16 GMT 2006
On 5/16/06, Hisham Muhammad <hisham.hm at gmail.com> wrote:
>
> One thing we *don't* have right now but that I see as a kind of
> solution for these stability problems is to do the following:
> - treat the recipe store as simply a "pool" of recipes (any version of
> anything can go there);
> - have lists of recipe/package versions that are known to work well
> together; like a "stable" list.
>
So "pool" is our stand alone Compile recipes. The stable list is our
"whitelist" of "approved base". Should we view that on a release by
release basis?
Conceptualy, that seems the easiest to manage. Especially WRT
developer screw ups. It would also simplify recipe/package reivisions
to simply recipe revisions on a release basis.
> That's just doing what other distros do, of course. There's no need to
> reinvent the wheel in terms of distro maintenance (we have a lot of
> other wheels to reinvent, so let's not focus on the wrong ones :) ).
> What I have in mind is a model with pool+stable list for managed
> system upgrades, and the recipe pool split in core/extras for recipes
> with assigned maintainers and one-off contributions -- abusing a
> little both Debian and Fedora terminologies.
>
recipes == pool with Core/Extras split to imply level of support(++).
Abusing others terminoliges is great!!! In a way, defining how we
handle binary package defines the distro we are (Compile should
provide a Gentoo like solution). Frankly, I'm only interesting in
Core at this point. Providing Extras bin packages is a secondary
concern. I figure the community will provide for that.
> There could be even many of those lists, kind of like some developers'
> personal "patch sets" for the Linux kernel. Users who want to follow
> one of these lists would use some script to keep their systems in sync
> with that list (that script could interact with InstallPackage and
> with Compile (to rebuild the user's personal additions to the list,
> when needed, etc -- over time the sync script could become very
> smart)).
>
Those lists are similar to "editions" suggested long ago. I think we
should focus on what gobolinux.org (and mirrors) can provide. Design
for ourselves.
PS. I'm planning on upgrading hosting for calica.com. Suggestions,
please email me.
PPS. Is the delay on 013 hurting users?
--
Carlo J. Calica
More information about the gobolinux-users
mailing list