Packages in QL

[badaman]

We are lucky to have a lot of QL software available online for download, but we have heterogeneous QL systems: BBQL, extended QL, emulators, graphical environments, distributions...

Sometimes it is a bit of a pain to download the programs and deal with their configuration, installation in the right directory or device...

This mainly discourages those who do not have much experience or those who approach the world of QL carelessly, and makes them think twice about trying again.

I wonder if it would be feasible to promote the creation of a QL package system that allows developers to offer their new or old programs in such a way that, with a command, users can correctly install their programs in the different environments mentioned, thus helping users.

This certainly implies more work for developers and package maintainers, and implies thinking of an adequate and standard folder structure to facilitate this utility, but I think it would be very interesting to have something like this, if it does not already exist.

What do you think? Of course, if anyone with extensive knowledge asks, they can count on my commitment and support.

[swensont]

Having a "package" that supports all QL platforms would mean that a developer would need to have a variety of QL platforms for testing, such as:
- Qemulator
- QPC II
- SMSQmulator
- sQLux
- BBQL
- BBQL w/ Gold or SuperGold Card
- BBQL with Aurora
- Q68
- Q40 / Q60

That is a long list and I doubt anyone has all of that. Even with just the emulators, you would need multiple platforms (Windows, Mac, Linux).

I'm guessing that I'm not seeing the problem that this solution is meant to fix. Most QL software is easy to install. They might need to have a toolkit pre-installed (such as TKII or ENV).

Tim

[Derek_Stewart]

Having a "package" that supports all QL platforms would mean that a developer would need to have a variety of QL platforms for testing, such as:
- Qemulator
- QPC II
- SMSQmulator
- sQLux
- BBQL
- BBQL w/ Gold or SuperGold Card
- BBQL with Aurora
- Q68
- Q40 / Q60

That is a long list and I doubt anyone has all of that. Even with just the emulators, you would need multiple platforms (Windows, Mac, Linux).

I'm guessing that I'm not seeing the problem that this solution is meant to fix. Most QL software is easy to install. They might need to have a toolkit pre-installed (such as TKII or ENV).

Tim

Hi Tim,

I have all of the hardware on your list, except Aurora, which I have 2 non-working boards. But I have nearly got the Aurora PCB Schematics in KiCad. I am struggling with converting the the CPLD code to Verliog.

[tofro]

To be honest, in my opinion a package manager is a bit of overkill to the QL (WARNING: A bit of a rant incoming).

First of all, a package manager needs some sort of persistent database of packages, files and locations. Not very viable on, for example, floppy-based systems.

Second: package managers aren't simple pieces of software. To achieve something like only a subset of, for example, RPM on Linux, you'd need a substantial piece of code. And, if something goes wrong, problems are becoming much harder to fix for the average user than with other, more traditional and more transparent methods. Handling dependencies (like "needs PE version xxx and up") would probably have you create a software monster in QL dimensions...

Third: The variation of systems to target is just too big: There's people with "hard disk"-based systems that will only ever run a single BOOT that includes everything but the kitchen sink (and they maintain as some sort of sacred piece of software they'd never want someone else to mess with...), on the other end, people using floppy or mdv-based systems that will run amultitude of BOOT files, all different.

And fourth: The QL (and, even more, SMSQ/E) includes everything you could possibly need to build single-file installs. Compilers allow you to include all necessary files within one binary, and, if your program really needs some sort of specific install directory, the HOME system allows you to neatly do that.

This goes a bit along Per's recent rant on programming: If people would put a bit of thought into their programs, they could achieve nearly everything with a single file install, or, if more sophisticated, a single directory install plus HOME_DIR. Unzip, done, run. And if you can't expect them to do even that, why would you expect them to create the necessary information for a package manager?

To sum it up: The only "package manager" that I reasonably need and want is acp_obj

[badaman]

Tofro, thank you very much for your comments. I think they are very reasonable arguments.

[XorA]

For emulators Q-Emulator already has qlpak which is sort of what is asked for.

https://www.terdina.net/ql/software.html

[badaman]

For emulators Q-Emulator already has qlpak which is sort of what is asked for.

https://www.terdina.net/ql/software.html

Exactly. That's the idea, but extended to systems, not just the emulator. It seems that Q-emuLator is also the only one that supports that format.

It's complicated, but...

[swensont]

> It seems that Q-emuLator is also the only one that supports that format.

Since the .qlpak file contains Q-emulator config information, I don't think other emulators would support it. There are ways to get the same thing done on other emulators.
One could distribute software was a qxl.win file that is configured to boot and have all toolkits needed. If a specific emulator config is needed, that could be included and a script can all the emulator with the specific config file.

A full package system may not be worth the time invested in creating it. I was thinking about doing a open source spell checker for Quill, but I think I'm the only one still using Quill on a regular basis, so I put that idea on the back burner.

Tim

[tofro]

For emulators Q-Emulator already has qlpak which is sort of what is asked for.

https://www.terdina.net/ql/software.html

Exactly. That's the idea, but extended to systems, not just the emulator. It seems that Q-emuLator is also the only one that supports that format.

It's complicated, but...

qpak files are, in principle, the same thing as a container file plus the appropriate Q-Emulator settings.
There's no support for "blending in" the QPAK contents with an existing setup.

You could likely achieve the same thing by supplying software in QXL.WIN containers for the various systems (the ones that support them). This could be useful to have a quick glance at a program (or occasionally play a game), but rather not for integrating new software into your system.

[XorA]

I don't think other emulators would support it.

if Daniele was ok with me ripping off his ace idea, I would be up for adding support to sQLux and sQLay, the options are pretty similar anyway!