WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: dependence~ dependence~ dependence~  (Read 5708 times)

Offline polikuo

  • Hero Member
  • *****
  • Posts: 723
dependence~ dependence~ dependence~
« on: November 02, 2020, 05:02:11 AM »
I think there should be a dedicated Child Board for dependence reporting.

Just like [Extension requests]

Anyway ~

CorePure64 11.1

gnome-shell-gir needs network-manager-applet-gir (not copied)

gnome-session uses xdg-user-dirs (not copied)

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14815
Re: dependence~ dependence~ dependence~
« Reply #1 on: November 02, 2020, 06:14:54 AM »
We could use TCE Bugs for dependency problems?

For network-manager-applet-1.8.10 in CorePure-10.x, dev and gir files were produced by the build. For network-manager-applet-1.16.0 in CorePure-11.x, no dev or gir files were produced. I don't see any errors when using network-manager in gnome-session?

I didn't include xdg-user-dirs in the gnome-session deps because xdg-user-dirs-update is only required once if you have a backup.

Edit:
Code: [Select]
$ g-ir-inspect Shell --print-typelibs
typelib: xlib-2.0
typelib: GDesktopEnums-3.0
typelib: GModule-2.0
typelib: xfixes-4.0
typelib: Meta-6
typelib: Clutter-6
typelib: Gtk-3.0
typelib: GObject-2.0
typelib: Gck-1
typelib: St-1.0
typelib: GL-1.0
typelib: CoglPango-6
typelib: Json-1.0
typelib: Cogl-6
typelib: PolkitAgent-1.0
typelib: GLib-2.0
typelib: cairo-1.0
typelib: Atk-1.0
typelib: Gvc-1.0
typelib: Polkit-1.0
typelib: Gdk-3.0
typelib: ClutterX11-6
typelib: Gio-2.0
typelib: NM-1.0
typelib: Gcr-3
typelib: Pango-1.0
typelib: Cally-6
typelib: GdkPixbuf-2.0
typelib: PangoCairo-1.0
typelib: Graphene-1.0
NM-1.0 is supplied by networkmanager-gir
« Last Edit: November 02, 2020, 06:21:22 AM by Juanito »

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11619
Re: dependence~ dependence~ dependence~
« Reply #2 on: November 02, 2020, 07:08:31 AM »
Hi polikuo
I think there should be a dedicated Child Board for dependence reporting. ...
Missing dependencies belong in  TCE Bugs.

Offline polikuo

  • Hero Member
  • *****
  • Posts: 723
Re: dependence~ dependence~ dependence~
« Reply #3 on: November 02, 2020, 09:20:48 AM »
For network-manager-applet-1.8.10 in CorePure-10.x, dev and gir files were produced by the build. For network-manager-applet-1.16.0 in CorePure-11.x, no dev or gir files were produced. I don't see any errors when using network-manager in gnome-session?

So somewhere in the gnome-session tree need some fixing ?
It's been a long time since I last use Corepure64.
I'm starting fresh and tce-install -w gnome-session reports they are missing

I didn't include xdg-user-dirs in the gnome-session deps because xdg-user-dirs-update is only required once if you have a backup.

OK~
tce-load reports not found back then, a typo perhaps ?

Offline hiro

  • Hero Member
  • *****
  • Posts: 1229
Re: dependence~ dependence~ dependence~
« Reply #4 on: November 02, 2020, 10:17:54 AM »
Hi polikuo
I think there should be a dedicated Child Board for dependence reporting. ...
Missing dependencies belong in  TCE Bugs.


what if there is bloat and too many dependencies? that's not a bug or?
i tried installing gparted on the latest release over an LTE modem, had to give up in the end :D

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11619
Re: dependence~ dependence~ dependence~
« Reply #5 on: November 02, 2020, 11:22:03 AM »
Hi hiro
... what if there is bloat and too many dependencies? that's not a bug or? ...
If the dependency doesn't belong, it's a minor bug.
If the extra dependency can't coexist with another installed extension, maybe not so minor.
If it's a build leftover (gtk3-dev.tcz instead of gtk3.tcz), it pulls in an extra 140 MB of dependencies.

Offline polikuo

  • Hero Member
  • *****
  • Posts: 723
Re: dependence~ dependence~ dependence~
« Reply #6 on: November 02, 2020, 11:38:53 AM »
Missing dependencies belong in  TCE Bugs.

So ~

A child board of TCE Bugs  ::)

Just speaking out my thought, cause there are so many posts related to dependence

It kinda make sense to have a special place to sort things out...

To me, bug sounds like typo in start-up scripts, program having weird behaviors,
 missing files here and there, incompatible libraries ...etc

Dependence is just a portion of it...

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14815
Re: dependence~ dependence~ dependence~
« Reply #7 on: November 03, 2020, 04:50:52 AM »
So somewhere in the gnome-session tree need some fixing ?

gnome-shell-gir deps adjusted

Offline polikuo

  • Hero Member
  • *****
  • Posts: 723
Re: dependence~ dependence~ dependence~
« Reply #8 on: February 07, 2022, 04:08:51 AM »
Hi

A quick one, binutils depends on flex.

Just extracting some simple archives with ar command

Code: [Select]
ar: error while loading shared libraries: libfl.so.2: cannot open shared object file: No such file or directory
On both PiCore port, the deps are OK

On both x86 x86_64, binutils.tcz.dep isn't presented.

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14815
Re: dependence~ dependence~ dependence~
« Reply #9 on: February 07, 2022, 05:16:11 AM »
dep files adjusted - thanks

Offline CentralWare

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 764
Re: dependence~ dependence~ dependence~
« Reply #10 on: February 08, 2022, 09:16:34 PM »
@Juanito, @Curaga and everyone else:


We're currently re-designing the functionality of tce-load/tce-ab which has the ability to back-step into older repository versions in order to find files which may not yet have made it into the latest version's repo directory (or TCZ's which have simply fallen through the cracks and forgotten about.)  HOWEVER, there's a debate as to how things should be prioritized, so I'm throwing this out there for everyone else to put in their two cents:


Installed TCL: v11.1 x86_64
     Version_Max then defaults to 11.x (the highest version in the repo to hunt through) and Version_Min is set to 5.x by default; both are command-line controlled


Extension: busybox-httpd.tcz
     Scenario: Let's say this extension does not exist in tinycorelinux/11.x/x86_64/tcz but DOES exist in 9.x/x86_64 as well as 10.x/x86; merely as an EXAMPLE.
  • I'm "assuming" most x86 extensions are just copied or linked from x86 into x86_64, but since we don't compile the masses, it's just an assumption.
  • I'm "assuming" most people would want the newest, MATCHING platform (x86_64) even if there was a newer NON-MATCHING (x86)??  (Toss-up here!)
  • I'm picking on busybox-httpd simply because busybox exists in all platforms and httpd relies on internal busybox functions, some of which may break over time as busybox evolves.
Please give your opinions, experiences, thoughts, etc. in relation to "if it were you, what would you do?"


Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11619
Re: dependence~ dependence~ dependence~
« Reply #11 on: February 08, 2022, 11:44:08 PM »
Hi centralware
I'll start by expressing an opinion.  I suspect this type of function would not be incorporated into Tinycore due to the
potential of users installing incompatible extensions causing breakage or inconsistent system behavior. This in turn
would likely lead to bug reports due to problems the users themselves created.  End of opinion.

Pitfalls:
Dependency versions change causing breakage. Examples that have caused issues include libffi, libpng, openssl,
and ncurses. Those came to mind because they affected a fairly large number of extensions.

Extensions get refactored into multiple smaller extensions, resulting in missing dependencies.

Extensions get combined (ipv6 and netfilter) resulting in a name change, dependencies no longer exist.

Extensions get dropped, dependencies no longer exist. Now you need to copy them too with the possible
issues listed above.

...   I'm "assuming" most people would want the newest, MATCHING platform (x86_64) even if there was a newer NON-MATCHING (x86)??  (Toss-up here!) ...
I don't understand this. You can't mix 32 and 64 bit extensions.

Quote
... I'm picking on busybox-httpd simply because busybox exists in all platforms and httpd relies on internal busybox functions, some of which may break over time as busybox evolves. ...
I'm pretty sure  busybox-httpd  does not use the system supplied  busybox  if that's what you are implying. Based on
the  .info  file, it's a tiny version of  busybox  with only 2 applets compiled.

Offline CentralWare

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 764
Re: dependence~ dependence~ dependence~
« Reply #12 on: February 09, 2022, 02:10:26 AM »

@Rich: Opinion received and well taken.


Argument: The next time there's an ARM kernel compilation, a new(ish) version is presented in the repo (say 14.x) and people start learning of its existence.. while Béla is getting nailed to the cross with the barrage of posts saying "where's this extension?" and "isn't it compiled yet?" this is where we decided to leave the poor guy alone and experiment with tce-load/ab and more times than not, it's successful.  Yes, there are going to be those extensions which get broken when ncurses.tcz gets revamped and renamed to ncursesw.tcz and a few of the functions which used to be part of the package are now found in separate dependencies scattered around the universe (etc. -- that's just a rant from a recent TCL Apache/LAMP build that went South. :) )


Example: We use dropbear for in-house SSH; back in v6 through v8 it went MIA within the repo; and I think it reappeared in 9.x.  Instead of hunting, or God forbid hounding an already overworked crew "Hey, where's my bear?" we re-used 5.x's copy throughout the different versions without a hitch.  Actually, 9.x might have even been our submission; I can't recall.


As for x86/x64 "...you can't mix..." maybe you can clarify something for me?
I recall posts from WAY back when that had discussed opting for x86_64 to be created in TC, different approaches, etc. and maybe there's been assumptions fed from dusty memories, but if x86 is strictly 32 bit kernel/user and x64 is strictly 64 bit kernel/user, what are the filename64 items doing in 12.x/x86/release/distribution_files?  (I thought these were supposed to be something like 64b kernel / 32b userspace where x86 extensions would operate, but I also recall someone noting it wasn't like M$'s WoW/emulation/etc.?)


Regardless, thanks for your input and efforts!


  Mr. T. J. Glawitsch -- President
    American Networks, Assoc.
CentralWare Development Centers


Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14815
Re: dependence~ dependence~ dependence~
« Reply #13 on: February 09, 2022, 02:30:14 AM »
what are the filename64 items doing in 12.x/x86/release/distribution_files?  (I thought these were supposed to be something like 64b kernel / 32b userspace where x86 extensions would operate, but I also recall someone noting it wasn't like M$'s WoW/emulation/etc.?)

Those files do indeed allow running Core64 - i.e. 64bit kernel with 32bit userspace

There was also a somewhat hacked 32/64 bit multi-lib "demo" at http://tinycorelinux.net/11.x/x86_64/tcz/src/multilib/

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: dependence~ dependence~ dependence~
« Reply #14 on: February 09, 2022, 02:31:39 AM »
Core64 = 64-bit kernel and 32-bit userspace. But that uses the x86 repo natively, it can't use the x86_64 repo.
The only barriers that can stop you are the ones you create yourself.