Packman

IMHO, some things lack in Packman:

• Design: more powerful search (ability to search only for new utilities in ROOL source, for example) ; icons + screenshots ; better looking UI; configurable start page (possibly with some package suggestion).

• More configuration: Dosbox-X should not go to Apps (configurable) + Emulation (non configurable), but a set of two user definable variables.

No directory should be static (just for translation issues or to mitigate some issues as Emulation placed Apps and not in Diversion).

• Meta packages to install a set of packages in one time.
• Linked packages (to reference in a repository one package provided in one another).
• For experts, the ability to not install some dependencies.

Combination of meta+linked packages would permit to do things as "install two packages: the vanilla software from one third party repository + the translation from your own repository).

Nota: the not install dependencies (or choose dependencies to install), could be a way to make meta packages.

• Virtual packages (to install packages stored elsewhere as zip/whatever).

For virtual packages, it could be done with a third party app, feed with a script (wget the file, decompress, copy). Then it would be very easy to make a catalog of third party titles, without having to ask for permission to distribute them (because it’s sometimes just impossible).

• Configuration packages: to reference sources, and then add remove sources easily.

Nota: perhaps that some of this can already be done under Packman.

I think meta packages are already possible. You have a package with a Control file that Depends: on a collection of other packages. If you install that package, the others will be installed too. The current server backend scans the .zips for their Control files to build the package lists, so you do need a .zip but I think if it had just RiscPkg.Control (and probably RiscPkg.Copyright just to make that position explicit) in there it would be fine – it would be a package you’d install and uninstall that didn’t install any files onto your system.

Virtual packages are also supported in the package lists: you can just cite URL: http:/somewhere-else.com/whatever.zip and Packman will follow that link. The above server script doesn’t handle that, so you’d have to construct your own package list – but that’s just a text file so shouldn’t be hard to do. That’s essentially just a redirect, ie it’s stored on a different server from the one hosting the list. I’m not sure how it handles things if the metadata from the package list and that from the .zip differ – perhaps Alan can advise?

(adding packages to the ROOL server explicitly does not support redirects for security reasons – they have to live on the same server as the pointer file. This restriction doesn’t apply to third party servers hosting their own lists)

If you generated a package list file with an app and stored it on your machine, would that allow some of the other things that you want? I suppose that would need Packman to support local files (perhaps file:// URLs) for package lists, which I’m not sure it does.

remove PackMan

FFS!!!

If someone could be arsed, they could put together a OtherStuffIsAvailable package containing a HTML file with links to all the “other stuff”.

I think meta packages are already possible. You have a package with a Control file that Depends: on a collection of other packages. If you install that package, the others will be installed too.

Yes, I was thinking of this as a possible solution. But there is no way to just take a part of what is proposed this way (would need an option to ignore some dependencies).

Virtual packages are also supported in the package lists

Ah, cool.

If you generated a package list file with an app and stored it on your machine, would that allow some of the other things that you want?

That’s a good idea too :)

I have read a few reviews by people that tried RISC OS on the RPi, and said it has very little software

Question: how does they know? There is no application count inside PackMan…

Yes, I was thinking of this as a possible solution. But there is no way to just take a part of what is proposed this way (would need an option to ignore some dependencies).

So we need a WeakDepends between Depends and Recommends! ;-) I think often you’d ignore recommended packages (I usually do on Linux) but might be encouraged to think a bit more if some were promoted a bit more strongly, yet not mandatory.

remove PackMan

FFS!!!

+1 to Stuart’s reaction to that statement. PackMan is THE way forward and works well. Nothing in this life is flawless.

Given that this seems to be a multi-requirement post in wish list, I would like to add to the list:

Have a CLI based version of PackMan or a way to install Packages from a command line based process, this would help enormously to automate builds that have pre-compiled dependencies.

Pre-compiled dependencies help boosting build speed on RISC OS, given that is not particularly fast right now on that regard.

Packman is built around LibPkg so in theory there is no blocker to a CLI version – somebody just needs to write a CLI frontend to LibPkg. Being able to do that in a crossbuild environment would be nice too.

Packman is built around LibPkg so in theory there is no blocker to a CLI version – somebody just needs to write a CLI frontend to LibPkg. Being able to do that in a crossbuild environment would be nice too.

good point! I’ll have a look into that, if no one else has time for it.

would be better to remove PackMan

+1 to Stuart’s statement. Packman, when used correctly, makes some complicated and tedious stuff a fair bit easier, plus it can be automated and kept up to date.

and put together good sets of HTML

You mean like all the crap that’s already been done that’s now decades out of date?

pointing to at least the 500 biggest 32-Bit clean RISC OS Soft sites

I’m sorry, I think I’ve just wet the bed.

Five hundred?

Five… HUNDRED?

Wait, five hundred biggest, implying…implying…

Oh, I’m going to have to lie down now.