icu67-dev and icu70-dev reverse dependencies

[GNUser]

I noticed that  icu67-dev.tcz  and  icu70-dev.tcz  were recently removed from the TCL14 x86_64 repository. However, some  .dep  files still contain these extensions, which is causing breakage:

Code: [Select]

$ depends-on.sh icu67-dev
boost-1.74-dev.tcz
js52-dev.tcz
js78-dev.tcz
raptor-dev.tcz
$ depends-on.sh icu70-dev
boost-1.78-dev.tcz
harfbuzz-icu-dev.tcz
libical3-dev.tcz
tracker3-dev.tcz What would be the most appropriate fix? To replace every occurrence of  icu67-dev.tcz  and  icu70-dev.tcz  in  .dep  files with  icu74-dev.tcz?

[Rich]

Hi GNUser
While  icu67.tcz  and  icu70.tcz  are still present, I suspect the
dev extensions were removed so the older versions are not
used when building extensions.

It's likely the entries in those  .dep  files should be changed
to  icu74-dev.tcz.

Repo update will be complete in a few minutes.

[Rich]

Hi GNUser
This may be more involved than i thought.
The following still depend on  icu67.tcz
because the non-dev versions depend on it:

Code: [Select]

js52-dev.tcz
js78-dev.tcz
raptor-dev.tcz
The following still depend on  icu70.tcz
because the non-dev versions depend on it:

Code: [Select]

boost-1.78-dev.tcz
harfbuzz-icu-dev.tcz
libical3-dev.tcz
tracker3-dev.tcz
We'll have to wait for Juanitos input.

[GNUser]

Sounds good, Rich. I figured my naive first thought might not be the definitive fix. I just wanted to alert you guys to the problem.

[GNUser]

Hi GNUser
This may be more involved than i thought.
The following still depend on  icu67.tcz
because the non-dev versions depend on it:

Code: [Select]

js52-dev.tcz
...

Hi Rich. I've been thinking about this situation. I think it's fine.

I just randomly chose  js52-dev.tcz  for a thought experiment, but it could have been any of the others. Let's say I load  js52-dev.tcz  because I'm trying to build some application foo. When I load  js52-dev.tcz  , js52-dev's entire dependency tree is loaded. Its dependency tree looks like this:

Code: [Select]

$ deptree js52-dev
-----js52-dev.tcz
     |-----js52.tcz
     |     |-----nspr.tcz
     |     |-----readline.tcz
     |     |     |-----ncursesw.tcz
     |     |-----icu67.tcz
     |-----nspr-dev.tcz
     |     |-----nspr.tcz
     |-----readline-dev.tcz
     |     |-----readline.tcz
     |     |     |-----ncursesw.tcz
     |     |-----ncursesw-dev.tcz
     |     |     |-----ncursesw.tcz
     |-----icu74-dev.tcz
     |     |-----icu74-bin.tcz
     |     |     |-----icu74.tczSo we have a situation where icu67, icu74, and icu74-dev are all loaded. Application foo will be linked against icu74 because that's what the header files in icu74-dev tell the compiler to do. But presumably foo is also being linked against js52 (which depends on icu67). So in this situation, both icu74 and icu67 will end up in foo's dependency tree. It's messy but will work because icu67 and icu74 do not clobber each other and can both be loaded on the same system.

So in theory at least there is no problem. But experience is better than theory, so Juanito's assessment will be valuable. I'm sure he has dealt with this exact issue (given number of icu versions in repository) or something similar before.

[Rich]

Hi GNUser
I noticed it because I checked those extensions using the
Apps utility under TC14 x86_64. The  Size  tab shows all
of the dependencies.

I just don't know whether  js52.tcz  being linked to  icu67.tcz
will cause any problems when building against  js52-dev.tcz.

[GNUser]

I just don't know whether  js52.tcz  being linked to  icu67.tcz
will cause any problems when building against  js52-dev.tcz.

Hi Rich. Honestly, me neither.

[Juanito]

There's no obvious easy solution to this.

I'm loathe to break the repo by removing, for example, icu67-dev, but if it is left in place and gets loaded before, for example, icu74-dev, it will not be overridden leading to the incorrect headers being used to compile against icu74.

On the other hand, if, for example, icu67-dev is not loaded even though, for example, js52 might have been built against icu67, it does not seem to cause problems as long as icu67 is present. Note that libicu*.so have been removed from icu67 and icu70 to avoid linking against them.

The above would tend to suggest we either remove references to icu{67, 70}-dev in dep files or put icu{67, 70}-dev back in the repo and hope users take care.

[CardealRusso]

I noticed that  icu67-dev.tcz  and  icu70-dev.tcz  were recently removed from the TCL14 x86_64 repository. However, some  .dep  files still contain these extensions, which is causing breakage:

Code: [Select]

$ depends-on.sh icu67-dev
boost-1.74-dev.tcz
js52-dev.tcz
js78-dev.tcz
raptor-dev.tcz
$ depends-on.sh icu70-dev
boost-1.78-dev.tcz
harfbuzz-icu-dev.tcz
libical3-dev.tcz
tracker3-dev.tcz What would be the most appropriate fix? To replace every occurrence of  icu67-dev.tcz  and  icu70-dev.tcz  in  .dep  files with  icu74-dev.tcz?

o que  precisa do js52?
parece apropriado recompilar tudo do repositório para icu74

[Rich]

Hi Juanito

... The above would tend to suggest we either remove references to icu{67, 70}-dev in dep files or ...

To be clear, just remove the references or replace them with  icu74-dev.tcz ?

[Juanito]

..just remove the references

[Rich]

Hi Juanito
OK, I'll take care of it.

[Juanito]

Thanks 

[GNUser]

..just remove the references

Hi Juanito. That was an interesting solution. I was going to suggest replacing icu67-dev.tcz (for example) with both icu74-dev.tcz and icu67.tcz. This change would be extremely unlikely to cause breakage.

The only option that seems suboptimal would be to keep every icu*-dev version and rely on user to know that icu74-dev needs to be loaded first if more than one is being loaded. If repo were to have even a small handful of such special cases, it would be very complex to use.


Hi CardealRusso. I will answer in English as Rich has requested. To find which extensions need foo, you can run depends-on.sh foo. Currently, it seems only js52-dev depends on js52.

[GNUser]

Juanito, can you give this Padawan a clue as to how completely removing the references will not cause breakage?