gtk2.scm is not downloaded while downloading audacity2, if gtk2.tcz is installed

[jls]

 

[roberts]

Not a bug. It is by design that scm know about tczs and therefore not load duplicates. Tczs do not know about scms.
You should raise the issue about the missing library in the extension area.

[jls]

I though scm where indipendent from tcz, anyway audacity doesn't start couse it's looking for  libtiff.so.5 which is in gtk2.scm,
The fact is that if I manually download and install gtk2.scm audacity starts.

[Jason W]

I also thought that scms were independent from installed tczs, as we had removed tcz dependencies out of the scm dep files, so scm and tcz interchangeability was not being tested.  In this case adding libtiff.so.5 to the scms that were built against gtk2.scm should let them operate with gtk2.tcz installed.  Or tiff and its development files can be updated in the repo while adding the existing tiff libs as a dep extension of all that needs it. 

But with things built against a python or will often have it's shebangs in scripts pointing to the installed python or perl, if the scm is installed it would be /apps/bin/python or /apps/bin/perl.  Interoperability there will not be so simple, though some scripts use "/usr/bin/env python". 

I will stop and ponder a solution.

[roberts]

It is the dependencies that are involved here. The test during dependency processing of an scm was seeing if such dependency was already satisfied by way of an installed tcz. Jason, if you wish that portion of  test to be removed I will gladly do it. It is at line 142 of scm-load

Code: [Select]

if [ ! -f /usr/local/tce.installed/"$PKGNAME" ] && [ ! -d /apps/"$PKGNAME" ]; then

Perhaps some pre-testing to ensure that it will not break other scms and their dependencies.
I await your response.

[Jason W]

Ok, at least for now we can test only for installed scms and not tcz.   Thanks.

[Jason W]

Removing the test for installed tczs seems to work as expected so far.

[roberts]

Change effected for 4.6.2.

[AbNoRMiS]

sorry for interfere
because i don't quite understand why will removed checking for installed tcz equivalent
i would say that may be problem is not in that should download scm deps necessarily
but in that it's time to update graphics-libs-1.tcz which has not been updated for 3 years
i think that when scm deps do not loaded if already installed its tcz equivalent
it was very pertinent decision for that to do not load libraries duplicates
for example now i have midori.scm which does not work without gtk2.scm
but seems that problem is in old midori.scm version but not in that should load gtk2.scm necessarily
as soon newer midori.tcz will be converted to midori.scm then i can remove gtk2.scm and free up 22mb

p.s.
though if look from other hand then perhaps 22mb is not so large size

[Jason W]

Gtk2.tcz would be simple to update it's deps to match versions with gtk.scm, but perl and python are the more complicated issue, even if the tcz and scm versions were maintained in parallel.  If we can get python and perl to work as interchangeable between scm and tcz for the scms that need them, that kind of brings the question of being able to use what is normally considered system library dependencies like gtk2 and python instead of them existing in scm form and adding the extra development overhead of maintaining and testing 2 separate versions.   But, tcz deps has been addressed and it is preferred to keep tcz dependencies from being listed in the scm dep files to prevent potential system inconsistency.

Midori.scm was built from scratch against gtk2.scm, not converted from the tcz, that is why it prefers gtk2.scm at present.

But I will look into updating the graphics-libs extension, but it would mean splitting out some of the libraries contained into separate extensions and added to existing dep files to prevent breaking existing apps. 

[AbNoRMiS]

just i remembered that previously midori.scm worked with gtk2.tcz before update some tcz
but now i understood that there are some difficulties and limitations when building scms
thanks for explanations

[AbNoRMiS]

maybe can add some control directives for scms which are built from scratch against some scm
for example require=name.scm in config/spec to force loading dependencies when it required

[Jason W]

On further study of perl and python, there is not a reliable way to make their shebangs portable to be able to make different python or perl packages installed into different places interchangeable.  And using the default shebangs that result from a "make install" without further hacking is usually  the best and most trouble free way to go.

I too lament that gtk2.scm is 22mb large, most of it locales that most folks will never use.  But you only have to download it once, and updates are incremental.   Though some scm uses in cloud mode involve downloading not much if any more MB than their tcz counterparts when downloading just that extension and it's deps,  I guess it goes back to accepting that the scm is going to be a larger download on average than the tcz method. 

[althalus]

On further study of perl and python, there is not a reliable way to make their shebangs portable to be able to make different python or perl packages installed into different places interchangeable.

Most portable way I've found is:

Code: [Select]

#!/usr/bin/env python
Of course, even that isn't foolproof, sometimes env ends up in /bin/env instead, and doesn't deal with distros where python 3's binary is python and the binary for python 2.7/whatever is python27. May have other implications for the particular use case being discussed here that haven't occured to me.

[Jason W]

That would normally work, but I found with trying to package edna I believe that e full path is needed.    And for perl, the full path it seems is needed to use the -w option.

But even if it did work, it means adjusting and testing every perl or python script in an extension, which is a large overhead of time and resources.