[gobolinux-users] Source repositories and other suggestions

Martin O.B. 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..

Regards,

Martin OB


More information about the gobolinux-users mailing list