about nekoware installation -
soviet - 08-22-2020
I was thinking about the nekoware package installation after fighting the damn dependency issues on some packages.
Considering that nekoware will never change or be updated, is possible that someone that have all the packages installed just tar the /usr/nekoware directory and upload it ?.
Then just untaring the directory in other irix install should work i suppose ?.
RE: about nekoware installation -
kaigan - 08-22-2020
(08-22-2020, 04:35 PM)soviet Wrote: I was thinking about the nekoware package installation after fighting the damn dependency issues on some packages.
Considering that nekoware will never change or be updated, is possible that someone that have all the packages installed just tar the /usr/nekoware directory and upload it ?.
Then just untaring the directory in other irix install should work i suppose ?.

There are a
lot of Nekoware packages, especially if you include beta. I would suggest making use of the nekodeps.pl script, available here:
http://techpubs.spinlocksolutions.com/irix/nekoware-installer/.
You'll need to grab a copy of descript.ion and rename it to current.ion, so that you have the proper dependency information. You can grab it from the IRIX Network Nekoware repository here:
http://ftp.irixnet.org/nekoware/current/descript.ion.
After that, you can run the script and install whichever packages you like, with the script doing the dependency work. It can occasionally have some issues with complex dependency sets (GIMP comes to mind), but most things work fine.
RE: about nekoware installation -
Raion - 08-22-2020
I wanted to originally update Nekoware, keep in mind that was my original plan before Axatax took over. The issue with tarballing it is that there's a lot of useless Nekoware packages and some conflicting packages. You can't install beta and current packages that conflict with each other and dependencies can quickly become circular.
RE: about nekoware installation -
mgtremaine - 08-23-2020
Installing everything in Nekoware is going to lead to some disappointment. As others have said things are out of date and conflicting and once you install certain things you are committed to keeping them (python 2.4 I'm still looking at you). As painful as it might seem I would carefully pick out the package you really want and focus on getting those installed. Or wait for neko2 and or sgug to bring things up to date. I have thread here where I was trying to unwind some of the packages, and I know others have spent a huge amount of time and newer updated packages (python 2.7.+ etc... )
Just my warning... Don;t let me get in the way of your fun.
-Mike
RE: about nekoware installation -
jpstewart - 08-29-2020
(08-22-2020, 05:09 PM)kaigan Wrote: After that, you can run the script and install whichever packages you like, with the script doing the dependency work. It can occasionally have some issues with complex dependency sets (GIMP comes to mind), but most things work fine.
Do you remember what, specifically, went wrong installing GIMP with the nekodeps.pl script?
I recently discovered that neko_gimp-2.4.6 in current depends on neko_lcms-1.14 from obsolete. It won't work with neko_lcms-2.1 from current. There's no way the script could figure that out. (The problem is that the dependency in the GIMP package essentially says "LCMS 1.14 or higher" but the LCMS packaging changed enough between 1.x and 2.x to break backwards compatibility.)
As for the larger question of handling dependencies, one can download the tardist files from Nekoware current, extract them all, and then let Software Manager worry about it. You can only open a limited number of tardist files at one time in Software Manager, but if you unpack them into their component files first there's no limit on what can be in the directory. (That's how things are shipped on IRIX CDs, not as tardist files.) Since I'm a Bash shell user, I run the following command:
Code:
for FILE in *.tardist; do tar xvf $FILE && rm $FILE; done
That extract severything and removes the original tardist files since there's no point in having them take up twice the disk space. (They can always be re-created if you really need them.)
Then from within Software Manager, I just "Open Distribution" and browse to the directory containing Nekoware. It'll scan the whole directory to find stuff that's marked for installation by default, check prerequisites, satisfy the ones it can, and list "Conflicts" where it can't. It's much easier than adding one tardist at a time.
The only downside is that you can only have one version of a package in the directory at any give time. That's how I discovered the conflict with GIMP/LCMS versions.
RE: about nekoware installation -
kaigan - 08-29-2020
(08-29-2020, 07:50 PM)jpstewart Wrote: Do you remember what, specifically, went wrong installing GIMP with the nekodeps.pl script?
I don't remember off-hand, but the issue you mentioned with neko_lcms would likely be it. Like you said, the script can't really account for an issue like that. It's still a very useful tool, but an imperfect one.
RE: about nekoware installation -
Raion - 08-29-2020
I'll make sure that we include both version of lcms if we just rebuild old GIMP.
RE: about nekoware installation -
jpstewart - 08-31-2020
(08-29-2020, 11:02 PM)Raion Wrote: I'll make sure that we include both version of lcms if we just rebuild old GIMP.
If you re-build GIMP you'd be better off building against a current LCMS package. As far as I can tell, it's just the (Nekoware) packaging that made incompatible changes, not LCMS itself. In fact, by setting "rulesoverride on" in inst, I've installed GIMP and the latest LCMS. Of course inst complains about unsatisfied dependencies, but GIMP works. (At least in the preliminary testing I've done so far.)
What seems to be happening is the neko_lcms-1.14 package put bin/jpegicc and bin/tifficc in separate subsystems called neko_lcms.sw.jpeg and neko_lcms.sw.tiff. GIMP depends on those subsystems but they don't exist in the neko_lcms-2.1 package. However, it looks like the two required binaries are in neko_lcms.sw.eoe instead of their own subsystems. So the needed binaries are in the newer package, just under a different subsystem name.