[gobolinux-devel] Symlinking of metarecipes

[Jonas Karlsson]

On Wed, 06 Dec 2006 23:38:57 +0100, Hisham Muhammad <hisham.hm at gmail.com>  
wrote:

> On 12/6/06, Jonas Karlsson <jonka750 at student.liu.se> wrote:
>> On Wed, 06 Dec 2006 00:25:10 +0100, Hisham Muhammad  
>> <hisham.hm at gmail.com>
>> wrote:
>>
>> > On 12/5/06, Jonas Karlsson <jonka750 at student.liu.se> wrote:
>> >> On Tue, 05 Dec 2006 23:39:47 +0100, Hisham Muhammad
>> >> <hisham.hm at gmail.com>
>> >> wrote:
>> >> > Won't work. PATH and LD_LIBRARY_PATH won't be enough. The proto  
>> stuff
>> >> > installs headers. Then you'll have to handle C_INCLUDE_PATH. And if
>> >> > something uses C++, then CPLUS_INCLUDE_PATH and so on and so on  
>> and so
>> >> > on. It's hackish. And then some other recipe in the future may look
>> >> > for share/ stuff which won't work unless properly symlinked. Doing
>> >> > this is asking for meta-recipes to break in mysterious ways.
>> >> >
>> >> "and so on and so on and so on."
>> >> I can only see that there are six variables to take care of (PATH,
>> >> MANPATH, INFOPATH, LD_LIBRARY_PATH, C_INCLUDE_PATH and
>> >> CPLUS_INCLUDE_PATH)
>> >> of which two have to have two entries bin/sbin and lib/libexec.
>> >
>> > No, the set of variables is unbounded: think of PkgConfig, Python,
>> > etc. Potentially, any program can create an environment variable that
>> > establishes a path dependency that can be necessary in a later step.
>> >
>> I still don't see the problem. The only problem I see with not  
>> symlinking
>> is that one has to update environmental variables so that the files
>> installed (and not symlinked) are found. If an app creates environmental
>> variables to resources outside of that dir, I can't see how that would
>> break things. Maybe I'm missing something.
>
> I gave you an example already. Pkgconfig won't be able to find .pc
> files installed by subrecipes until they are symlinked. Ok, so then
> you could say "handle PKG_CONFIG_PATH too then". This breaks the
> earlier argument that "I can only see that there are six variables to
> take care of". Like I said, the set of variables is unbounded. Any app
> can come up with a scheme that requires an additional var to be
> handled, and then one would have to run after them as things break
>
Ok, you've convinced me :)

>
>> > In another email, you suggested for sub-recipes to have 200+
>> > hand-maintained Dependencies files, while we removed Dependencies
>> > files from sub-recipes precisely because of the maintenance burden.
>>
>> I still think that dependencies should be in every sub-recipe.
>
> And who is going to figure out the dependencies for each of the 200+
> subrecipes? Most importantly, how? Removing Dependencies from
> subrecipes was André's idea, which I agreed with. He may be able to
> provide more insights on the rationale for this decision.
>
There are not that many dependencies. The complete meta recipe Xorg has 9  
dependencies. If you look at the separate sub packages, i.e. Xorg Libs,  
they have about 3 depenndecies each. Of cource they depend on earlier  
parts of the Xorg meta, but we can't check on that atm, as we don't know  
what's installed in the meta directory.

>> Look at my
>> other thread, where one of the components of Xorg 7.1 needed another
>> component of Xorg 7.1 (but the latter wasn't installed due to an error  
>> by
>> me). I would like to be able to update sub apps separatly, when it's
>> possible.
>
> Not running the whole compilation in order opens the gate for errors
> like the one you had. When going against the recommended and tested
> behavior of compiling a meta-recipe all at once, there's the option of
> emulating Compile's own behavior by using Compile -n -e -k on the
> subrecipe at your own risk.
>
Perhaps I used the wrong example, as my point didn't get through. What I  
meant was that if dependencies was listed in the sub recipes I would have  
got a warning that the dependency wasn't installed (but again that require  
that we know what's installed in the meta directory).

As for 'Compile --app-name --app-version -keep', I think that the sub  
recipes should emulate this by specifying 'part_of_name=Xorg' and  
'part_of_version=7.1' inside the recipe (the variable names could be  
discussed).

>> The difference, the way I see it, is that dependencies fail once in a
>> while, but your idea of add do_symlink=no had the possibility to fail
>> 200+ -#_of_proto times.
>
> Which is why I only advocated it for proto's. (Of course, I proposed
> it as an alternative to tweaking env vars, not as an alternative to
> subrecipe dependencies).
>
It did not sound like you meant proto only, but more as in "start with  
proto and then experiment with the rest", but I guess we misunderstood  
eachother again :)

Anyway I feel like we should approach this some other way as I'm stuck on  
that we don't know what files are installed in the meta directory.

-- 
/Jonas

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