[gobolinux-users] Source repositories and other suggestions
hisham.hm at gmail.com
Wed Nov 15 03:50:43 UTC 2006
On 11/14/06, Martin O.B. <martinobal at gmail.com> wrote:
> 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.
Thanks :) I'll complement MJ's answer covering the other topics:
> 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.
We are in process of improving the overall model of recipe development,
starting by adopting a Subversion server. I'm currently working on
cleaning up our store a bit so I can post an initial checkin. Once we can
give recipe contributors svn access, we should be able to have
recipe maintainers in a proper sense. This way we can have at least a
subset of the recipes tree that has a more "official" status in a sense
that it is maintained regularly.
> 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.
I like the latter idea; variants of it were already suggested but
I think different "distro branches" are quite possible by having some
kind of selection mechanism between Compile/InstallPackage and the
recipes/packages pool. It would be nice to see.
> 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.
Your example was a bit hard to follow (my fault certainly, it's past
1am as I write this), but work was put recently into revamping our
dependencies scheme, allowing to specify valid version ranges nicely,
recursive checking, etc. I think everything is in place now (André can
confirm this better as it's his code) but most recipes don't use it
yet. So, I think this is bound to improve over time.
And welcome to GoboLinux! :)
More information about the gobolinux-users