[gobolinux-users] Source repositories and other suggestions
martinobal at gmail.com
Tue Nov 14 03:17:42 UTC 2006
Hi, I'm a new Gobolinux user! I'd heard a little about Gobolinux a while
ago, then, a few days ago, I saw an article comment in OSNews. The
article was actually about PC-BSD and people were discussing different
package management schemes. Someone mentioned Gobolinux, and Google did
the rest ;) All I can say is Wow!, this is an awsome concept, and people
often misunderstand what it's all about.
So,I have a few questions and I dare make some suggestions, newbie as I
am (here in Spain we say "ignorance is bold").
So let's see, we have a repository for recipes, another repo for
official packages and yet another for contributed packages, besides
local recipes and packages in each user's computer.
First question: are those recipes officially supported or contributed?
Why aren't there two categories: "official recipes" and "contributed
Recipes". I mean, offical packages are only useful for i686. Other archs
could benefit from official recipes.
There's another problem I've found: lots of broken links in the recipes.
For instance, a project changes from .gz to .bz2 and there you are, a
broken link. How about having an official repo for source files, which
simply acts as a mirror of the official project's site (no tweaking) but
ensures no broken links in Compile, for users who dont need to have the
very latest version? Whenever a developer adds a package to this "mirror
repository" he would check that he can compile it without missing
dependecies, otherwise add those dependecies to the repo aswell.
Another suggestions: other distros have several repos, from the most
"stable" from the most "bleeding edge". Gobolinux could have just one
repo for source, and different repos for different recipes (from stable
to experimental) or maybe one repo for recipes as well, and then an
online database with recipe classifications (regarding stability and
possibly other criteria) that Compile can read.
Now, excuse me if I don't make sense, but if I got it right, there's
this kind of problem with dependencies: You have applicaton app1 which
depends on library lib1.1 which in turn depends on library lib2.1. Maybe
app1.1 insists that it needs lib1.1 and does not accept later versions
by default, to provide better stability. But lib1.1 accepts to be linked
to any later version of lib2, that is, it assumes backwards
compatibility. So, if lib2.2 accidentaly breaks backwards compatibility
for the purpose of lib1.1, then app1 is broken, even if it didn't accept
later versions of lib1. Is it possible to use an option in Compile, so
that it recursively chooses the officially required version of each
dependecy, so that this problem is avoided? You could always have the
option of recursively update your dependecies to the latest versions,
and if some application breaks, recompile it and tell it to downgrade to
its latest working configuration, or in worst case, to recursively use
only officially tested versions of each dependency. From there, you
could also have the option to upgrade only security-critical libraries,
from a list automatically fetched by Compile.
I guess something like this must have been discussed here and in other
distros, but I'd thank some clarification on this subject..
More information about the gobolinux-users