sox update?

I can, although you seem to he having problems today.

I don’t have a problem, but Chris G does it seems regarding what is a package, and installing lots of individual files to allow an application to work.

Several people have now confirmed that for some versions, the Shared Libraries are in the application.

Until now I was not aware we had two versions of !Obrowser, is this other one on RISCOS Direct?

take it that you’re suggesting that several people here are “confused”, then?

Steve, you are a programmer whereas I am nowadays just a humble end user. I have always when getting software simply installed the application and used the supplied Boot Merge facilities. The package manager system is alien to the RISC OS world. The real problem is when what is being installed is not an actual package of all the files needed for the application to work. The !SharedLibs issue is just a side issue here as far as I am concerned. The issue is being expected to install various files as supplied in PackMan but actually part of a “Package”

Obrowser supplied via CD costs money, how are you going to handle that via the super doper Packman Package management system.

Very easily, as I’ve explained now several times. You don’t use PackMan; you interact with the package management system that PackMan is just one possible client of.

The hypothetical CD contains an installer, which is hardly controversial. It also contains all of the files to be installed, so there’s no internet connection required, which for ease can be stored in the standard packages which the package management system (again, not just PackMan) understands.

The installer looks for a package database, and creates one if it doesn’t already exist. It then installs all of the shared files in the standard places, checking each into the package database as it goes. If any files conflict with what is currently in the database, it can either resolve that or – if that fails – warn the user and stop before any damage is done.

At the end, you have an installation which is recorded in the package database. If the user already uses PackMan, it will therefore co-exist happily. If the user does not use Packman, then it will just look like a normal install – but should the user install PackMan in the future (to obtain something like Python, perhaps), then all the necessary information will be present to allow it to co-exist with the files installed from the CD.

The problem is that this approach breaks other applications which might already be installed. That’s not acceptable, even for beta software – especially since the issue hasn’t, to my knowledge, been clearly stated by those distributing Iris.

So you are happy to allow end users to install “beta” versions of the !SharedLibs over known working versions. Does not sound like a good idea to me, more likely to break stuff as the files are beta, still being tested.

It has been explained in these forums I believe, why the !SharedLibs is currently within !Iris by the ROD, was due to the fact the software and !SharedLibs were beta versions and could cause further issues to end-users.

Buts lets forget actual end-users. When a final release of Iris is ready I expect it to have merged the latest files required into !SharedLibs.

On Linux I can easily have a clear distinction and choose between a ‘packaged’ install and one that is not. For most run-of-the-mill things I use synaptic and it (generally) gives me a ‘system level’ install of the current version for my distro.

However I can also build and install things in my ‘user’ space which do NOT go via synaptic, and can’t be invoked in the same way.

e.g. I have a system command ‘ffmpeg’ that calls the version installed by synaptic. But I have also built versions (plural) I can call via a specific location like ~/Applications/ffmpeg/ and use these for exeperimental purposes. – e.g. being when the BBC experimented with flac streaming and a build of ffmpeg was produced to cope with it so I could make a clean recording for analysis and comparison with what the BBC were intending.

Synaptic doesn’t trample on this, just means I can call the versions in different ways.

If people are going to intro package managers (yes, possibly plural) to RO then this sort of thing might be needed to avoid our own version of dependency hell.

But yes, I think Package Management is desirable and good – provided it doesn’t screw up other things for some users.

And FWIW I’m not a fan of the ‘flat pak’ approach. 8-]

I don’t have a problem, but Chris G does it seems regarding what is a package, and installing lots of individual files to allow an application to work.

From what I’ve read here, I’m afraid that the misunderstanding all seems to be at one end.

The !SharedLibs issue is just a side issue here as far as I am concerned.

Unfortunately they’re the whole issue as far as this discussion goes. The Shared Libraries are complex¹, and hard to manage by hand. They post-date PackMan, and so have always been supplied by package management. Sure, there have been a few exceptions – but the discussions here about the problems installing the YouTube stuff should show you why this isn’t optimal.

The reason this is getting heated and contentious is because messing with the shared libraries in an uncontrolled way can break pre-existing software installed on a computer. Unlike older stuff in !Boot, there’s never (as far as I know) been a precedent of installing !SharedLibs by hand. There’s not the “grandfathering” get-out that there is when shipping internet modules or even the Shared Unix Library as a Boot Merge package.

And it’s all so unnecessary. As I’ve now explained several times, this can be solved easily in a way that doesn’t require PackMan or a live internet connection – if there’s a will to do it. Installing and managing the shared libraries in a way that played nicely with the things already on the machine should have been sorted before the first beta and tested as it went along, not left until the last minute.

¹ Last April, I looked at Python in The WROCC and, to keep the “purists” happy, described how to install the dependencies by hand. Working that out took me about half a day and some help from here, and writing it up wasn’t simple – and I don’t have any other clients for the libraries. Now that Python is in PackMan, we don’t need to worry as it is all handled automatically.

I’ve not seen what’s on the CD but i would imagine there is some sort of script with instruction what to do to install it.

Nope, it an application just like any other RISC OS application, copy it to your Harddisc or whatever and then use the normal Boot merge to merge the updated resources via Configuration. Simple and easy to understand. There is a text file IIRC advising on best way to install etc..

The issue is being expected to install various files as supplied in PackMan but actually part of a “Package”

There is a lot of conflating going on here regarding the thread about YouTube-DL, YTPlay and SharedLibs etc.

YTplay doesn’t have a package and there for is out of scope , though some people were willing to help point someone in the right direction which is now being used against them to prove a point that has nothing to do with it, I dispair.

For example Python 3.8 is part of the requirements for YTplay, though there are many more requirments, and it is packaged to allow Python 3.8 to be installed and used independently and it does install SharedLibs etc because that is part of it’s dependancies.

The fact that YTplay needs some additional steps is not the fault of say the Python 3.8 package any more than having to do your own thing for the paid for OBrowser, which is a differently packaged version of the freely available Otter browser which has it’s own Packman package.

Once YTplay is made a packman package then it will pull together all the required dependancies and managae it for you.

In the mean time if someone is against using Packman to install the individual components then fine just do without watching YouTube video’s or be prepared to hunting everywhere for the bits and pieces for it to work.

Also no one is saying Packman is perfect but it does what is on the tin for the packages that are available.

So you are happy to allow end users to install “beta” versions of the !SharedLibs over known working versions.

Unless I’ve misunderstood, that’s not how it works. I’m happy to be proved wrong, however.

The package manager system is alien to the RISC OS world.

So the fact that it’s used in the two most widely used RISC OS distributions doesn’t count? (RISC OS Direct and NOOBS).

Nope, it an application just like any other RISC OS application, copy it to your Harddisc or whatever and then use the normal Boot merge to merge the updated resources via Configuration. Simple and easy to understand. There is a text file IIRC advising on best way to install etc..

Ok then. Even more straight forward to change the instructions to install the pre-requisites using PackMan instead.

Nope, it an application just like any other RISC OS application, copy it to your Harddisc or whatever and then use the normal Boot merge to merge the updated resources via Configuration. Simple and easy to understand.

Meanwhile in another universe someone said :-)

This is an interesting thread to me. Since I have encountered this issue with the various browsers I have been trying. For instance there seems to be a different set of !SharedLibs files required for Obrowser as against Otter itself.

In another case where the browser has its own !SharedLibs inside itself, and to be able to run that browser I have to stop Sargasso running to be able to run that browsers SharedLibs and then I can rerun Sargasso without issue.

Since Steve believes this thread has become heated etc., then I will leave the thread. I have express my concerns about the way Pacman currently works relating to “Packges” and where you have to install various bits while we await a properly packaged version of whatever software.

When PacMan or whatever package manager is developed to allow you to choose things better, as Jim has mentioned. I will until then generally avoid PacMan, but I will monitor developments with interest.

To put it another way, the current package manager system does not seem very End-User Friendly.

Since Steve believes this thread has become heated etc., then I will leave the thread.

I’d call it luke warm/tepid :-)

Any way as ever we all want the same thing and it is just a discussion on the journey plan on how we get there that is debated.

However I can also build and install things in my ‘user’ space which do NOT go via synaptic, and can’t be invoked in the same way.

Using that analogy everything on RISC OS is ‘user’ space. You can already use PackMan to install the package wherever you want. If it already exists in that location it will prompt you whether you want to proceed and if so back up the existing install that isn’t currently under package management.

As Steve F says PackMan is just a front end to the Package database. It just happens to be the only one available.

For example Python 3.8 is part of the requirements for YTplay, though there are many more requirments, and it is packaged to allow Python 3.8 to be installed and used independently and it does install SharedLibs etc because that is part of it’s dependancies.

Python adds an extra layer of complexity. Whereas a normal application (e.g. Otter Browser) has a fixed set of dependencies.
Python has the ability to install python modules that could have any number of SharedLibs dependencies. e.g. pygame.

Just to wade into the mire…

It remains routine for people not to use PackMan. It has certainly been that way for decades into the use of the web to distrubute RO software.

Traditionally, RISC OS software was “an application”. In disc, in a downloaded zip file, whatever. You get it, draggy-droppy to where you want it, and mostly job done. It might need some SysMerge love if it has a few new modules, but by and large applications were self contained entities.

Such applications do not need to be “packaged”.

Now there’s something new. An application can pull in standard library code, rather like how it happens on, well, most other operating systems. And this use of libraries drops upon the end-user the concept of dependencies, and it may well be that those dependencies have dependencies themselves.
Such applications do need to be “packaged”, because packaging isn’t about giving the software an easy way to install itself (arguably Store opening a zip file with the program within is just as easy and RISC OSy). No, packaging is about installing the software and sorting out all the dependencies.

By then, of course, the poisoning of the package management well might have been so successful

And here is the crux of the matter. There isn’t any specific fault with Packman, there isn’t any specific fault with packaging. As far as I can see, it comes down to somebody or something quietly buggering around with the shared libraries and then people are left wondering why stuff breaks.

For the shared libraries and the complexities within (go and look, it’s complex), you basically have two choices. Use package management, or handle it all manually. You can’t mix and match.

The package manager system is alien to the RISC OS world.

As is the concept of shared libraries, if we’re honest. But sometimes you just gotta adapt, you know…?

there’s never (as far as I know) been a precedent of installing !SharedLibs by hand.

Hmm… When I first tried the Otter browser, I could have sworn I just downloaded a bloody big archive of libraries that I dumped into BootResources…? But, then, I didn’t have any shared libraries before, so nothing to conflict. I’ve not let Packman loose on it, so don’t know how that’d go.

And this use of libraries drops upon the end-user the concept of dependencies, and it may well be that those dependencies have dependencies themselves.

As opposed to the decades old setup of that obscure item you mentioned? (SysMerge)

Dependencies? RMEnsure – its always been there, and RO USers have always had dependencies for the apps they run, these are just sitting in a different structure.

Packman is just an automation tool to do the “new SysMerge” which someone decided to avoid using “because beta” which does make you wonder what they thought RO5.2oddnumber was supposed to be.

When I first tried the Otter browser, I could have sworn I just downloaded a bloody big archive of libraries that I dumped into BootResources…? But, then, I didn’t have any shared libraries before, so nothing to conflict. I’ve not let Packman loose on it, so don’t know how that’d go.

Well, properly written, it should check the version of the existing and offer to update if required. If Packman doesn’t do that then it needs a rewrite.

I’ve not let Packman loose on it, so don’t know how that’d go.

In the interests of scientific inquiry, I’ve just done exactly that. I have OBrowser and Otter Browser on my ‘old’ 5.28 card; the latter is the one and only version that is compatible with OBrowser. Telling PackMan to install its version of Otter produces this from the Conflict Manager:

Unable to install/update!
One or more files conflict with files already on your disk
!SharedLibs (35 children) at SDFS::HardDisc0.$.Apps.Network

You then have 3 choices: Show File list, Close, Backup and Retry

I’ve just pressed Close, as I don’t wish to proceed with the update. I shall now reboot and see if OBrowser is still functional…

UPDATE: I’ve rebooted. OBrowser will not now launch, and Otter will not launch on its own. It may be that I selected the wrong PackMan dialogue option above, but I think there’s a logical conundrum here: in order to find out what the conflicts were between what was already installed, and what I intended to install, I had to get to a point in the process from which an elegant withdrawal to the status quo ante seems not to be possible.

Yes, I understand that in RO the concept of ‘user space’ as distinct from space for the ‘system’ simply hasn’t existed. That, I think, is the root (pun alert!) of the difficulties we can run into.If we are going to have a packaging system – which I welcome – then we perhaps need one that takes this into account.

On Linux I know that “~Applications/ffmpeg/(version)” will give me something different to “ffmpeg” and can use either in a controlled way without them falling over each other. Maybe RO ways of defining system variables/paths or similar needs to be used to do something like this and make the distinction. dunno. But as things stand it makes me wary. FWIW up to now I copy stand-alone versions of sox, ffmpeg, etc, into my Library directory because that’s what I’ve done for ages, and it works OK.

Just to add: I also welcome the availability of libraries which more than one program can call and use. Just been using an example that Colin G. developed for USB audio and let me write things that I’d have found impossible if I couldn’t call the things it provides for other programs.

On Linux I know that “~Applications/ffmpeg/(version)” will give me something different to “ffmpeg” and can use either in a controlled way without them falling over each other. Maybe RO ways of defining system variables/paths or similar needs to be used to do something like this and make the distinction. dunno. But as things stand it makes me wary. FWIW up to now I copy stand-alone versions of sox, ffmpeg, etc, into my Library directory because that’s what I’ve done for ages, and it works OK.

I’m not sure how any of that would make you wary of package management on RISC OS.
As an example at the moment I’m testing at least 6 different versions of ffmpeg all installed via PackMan from a local Package source. To run them I just type in the alias.

ffmpegvfp
ffmpegeabi
ffmpegfpa
ffmpeg431
ffmpeggit
ffmpeg3

FWIW I also change the names of some older/different versions and keep them in the Library directory.

But are you saying the package system installs them with the various names?

That could cause some other snags. e.g. I’m currently looking at making an “!AudioScope” program that will examine, analyse, and display the content of audio files (wav, flac, etc, etc) in a way similar to my !USBScope. Shows sections of the waveforms, spectra, etc. To do this it will call ffmpeg and ffprobe so it can access any audio in files that they can convert. This, of course, assumes the user can get what it needed via a standard ffmpeg/ffprobe call…

However my concerns upthread are wrt to pre existing programs which a PackMan install might trample on because something they depende upon has been fiddled with in a way they know zilch about.

N.B. This was why I intially asked about sox. But since then I decided it made more sense to use ffmpeg as that may give a wider set of file types being readable. e.g. people could examine the audio in AV files as well as audio files.

But are you saying the package system installs them with the various names?

The package system isn’t doing anything other than installing it where it’s told to and recording it. If a new version becomes available PackMan tells you which ones have been updated since the last time ‘update list’ was run. It’s then just a case of installing the update.

The rest of how it’s handled is standard RISC OS.

If by chance you try to install something in a location that a pre-exiting application exists that PackMan doesn’t know about with the same name PackMan will prompt you with several options what to do. If you then choose to ignore the sensible option and overwrite PackMan backs up the original files.

Taking ffmpeg as an example. In all the example names given above the folder is always called !FFMpeg. The package name is what uniquely identifies it in PackMan. When each version is installed PackMan prompts where to install it and whether any of the Boot options need to be set. The defaults can be set in the Package itself by whoever creates it.

As I created the Packages I know to install them in different locations or I could have given them different application names and install them in the default location and with the default boot options set in the Package.
Some Packages are system packages so the boot options are greyed out and there is no option to install it in another location. Again this is just the default set in the Package by whoever created it.

The !Boot file in each ‘!FFMpeg folder also sets the alias used to run a particular version of ffmpeg. There is also an ffmpeg in $.Library. To run this version it’s just a case of putting a % in front of the command. This stops RISC OS using the alias. Aliases have the highest precedence in RISC OS.
Again none of this is down to PackMan being able to get it wrong.

You can have the same problems with installing in the ‘traditional’ way. For example ffmpeg 4.x could have a different option to perform a particular action compared to ffmpeg 3.×. The person installing the new version won’t know it’s going to stop their existing application working until it is run and the option is no longer there. Did you remember to take a backup before updating.