[gobolinux-users] Compile script annoyances

[Jonas Karlsson]

On Sat, 26 Aug 2006 08:38:33 +0200, V <mkdm_2000 at yahoo.com> wrote:

> Hi all,
>
> I've updated to the latest set of scripts and I tried
> to Compile xorg and had a few issues.  Here's my
> feedback.
>
I try to answer some of your questions, but I also like to know what  
version of Compile you're using. I'm guessing at 1.6.0, but I need to be  
sure.

> 1. When the process started it asked if I wanted to
> install Zlib 1.2.3, I said 'Y' and it reported back it
> was already installed.
>
> The script hung at 100% CPU utilization, I
> control-c'ed and it continued.
>
Strange. Hard to trace bug without more info.

> 2. As others have mentioned, I got asked a bunch of
> times: Compile: /Programs/Xorg/7.1 already exists.
> Continue? [Y/n], and also if I wanted to remove the
> existing source folders, etc.
>
As for getting the question about version already existing, it's a known  
bug and is resolved in the CVS.
About removing the source, you could use the option "--batch" to Compile.  
That always removes the source directory if it exists.

> 3.  Multiple prompting for the same item
>
> In the Xorg compile, Zlib 1.2.3 was brought up several
> times (at least 5, maybe more).  Can we just cache the
> result of a users input so if the same question pops
> up (even though it theoretically should not if
> everything is "kosher") it doesn't hold things up?
>
The dependency checking needs some fine tuning, we're aware of that. It's  
on my todo list to fix so that all questions about dependencies are cached  
during one "Compile session".

> 4. The automatic dependency system used to update a
> Recipe after a compile seems like it's a 95% solution,
> but the other 5% is a real problem.
>
> As we have all agreed, Glibc is still listed as a
> dependency and this causes all sorts of havoc since
> one cannot upgrade Glibc without special voodoo.  So
> we need to really remove this as a dependency.
>
Glibc shouldn't be regarded as a dependency. Have you run "UpdateSettings  
scripts" after you installed the new version of scripts? What do you get  
if you do 'ls -l /System/Settings/Scripts/Dependencies.blacklist'?

> I've also noticed with Compile, since someones Recipe
> may have a dependency with a different revision than
> the one installed (older or newer), one gets prompted
> to answer if this dependency should be installed or
> compiled even if you have an acceptable version
> installed.
>
> I have KDE 3.5.0 but I've compiled something where the
> person who created the recipe had KDE 3.4.3 and I get
> prompted if I want to install that version of KDElibs,
> etc.  A careless response could jack up the system.
>
How is your KDE 3.5.0 installed? In one directory, i.e.  
/Programs/KDE/3.5.0, or in multiple directories with one for KDE-Libs etc?  
If it's the former I can do some additions to the compability list.

> Maybe we should only prompt if the dependency listed
> is newer than an installed version.  i.e. you want
> Xorg, and you have GLib 1.2.2 and 1.2.3 is listed,
> then maybe prompt.
>
This is the behaviour. The dependencies listed is (at least it should be)  
the lowest version the current application needs and Compile should only  
ask in those cases where this version number is greater than what's  
installed on the system.

> Or perhaps, only prompt if the dependency is not there
> and warn the user his version is newer/older than an
> existing dependency.  I've noticed that there are
> instances where specific versions of something are
> required (i.e. you must have Tcl >= 8.2) but in most
> cases it does not matter.  Usually a program's
> configure script will tell you if it's an issue.
>
> Maybe do a test run of configure and grep for
> mismatching versions?
>
> Maybe we have profiles for Compile that allow the user
> to set how these default conditions are handled?
>
> Another approach of course could be the manual method
> (reading the readme or associated documents) and
> inserting in the Recipe that version >= x.y.z of
> Prog.Z is acceptable (and adding support for this into
> the Recipe/Compile system).
>
The automatic generated dependencies should only be considered as guidance  
when making a recipe. One should always look at the dependency list and  
manually edit it so that the lowest version needed is listed instead of  
the one installed on the current system.

> Sort of the same issue, the dependencies are sometimes
> valid for one persons' configuration but it is not
> global.  I think I was trying to compile SDL or an
> related SDL library and DirectFB was listed as a
> dependency since whomever supplied the Recipe must had
> or needed DirectFB.
>
> This is obviously not a requirement for SDL, and since
> something like DirectFB is somewhat specialized, it's
> possible if one answers "install everything" it could
> fail at that stage.
>
Yes, this is sort of the same issue as above. As well as one should check  
that the versions is the lowest needed, one should also remove any  
application that's really not needed directly by the current application.

> I don't know what can be done about this since this is
> added by an automated process.
>
As I said, the autimatic process should only be considered as a help and  
one should always manually edit the dependency list.

> Can we create a list of annoyances with the current
> set of scripts (if such a list is not already with
> someone internally) and try to resolve some of these
> outstanding problems?
>
We are working on getting a bugtracker up and running. Before it's up  
maybe the wiki is a good place to write such things down, i.e. for issues  
with Compile use the Compile talk page:  
http://gobo.kundor.org/wiki/index.php?title=Talk:Compile

> I really like the Gobo system a lot.  Everytime I pop
> back and use another Linux like Gentoo or
> Ubuntu/Kubuntu, I find myself wishing for Compile or
> InstallPackage since they work pretty well.
>
Nice to hear.

> But the Gentoo/Ubuntu package management is clever
> enough, or perhaps brute force enough that you say
> install something, and whatever else needs to be added
> is done almost automagically.  Not having to answer
> Y/n, or remove/reunpack/etc a hundred times is really
> nice.
>
We're working on it to get our tools more easy to use and most of all,  
getting the dependency checking better.

> The current deficiencies in the Gobo system make it
> nearly impossible to issue 'Compile prog' and walk
> away with high confidence further manual intervention
> won't be needed.  This becomes increasing problematic
> the more you want or need to do with the system.
>
This is an issue that lies very close to my heart. I'm looking at getting  
the entire install process, wether using InstallProgram or Compile,  
entirely automatic, using fully configurable options given in a conf file.  
But don't hold your breath waiting for it... :)

> As usual I'm verbalizing more criticisms than
> accolades of Gobo.  Just want to be clear, I'm
> providing my opinions in the spirit of positive
> feedback and constructive problem solving.
>
This kind of feedback is very appreciated, so please keep it coming. We're  
unable to make GoboLinux better unless we get feedback from the users.

-- 
/Jonas

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/