sox update?

I really don’t get the reluctance to using packages. It solves a number of problems:

1. You get a single interface to many repositories of software
2. Software can be downloaded and installed really easily
3. Dependencies will ‘just work’
4. Software can be updated really easily

I have got myself a Pi and RISC OS 5, having been away for a number of years. But even I don’t know where I am supposed to go to acquire software. The poor chap asking about MIDI software recently showed how it is like some sort of secret society!

I think Andrew made the point about some software being Beta and not wishing to “alter” someones set up that may cause issues

I doubt it matters too much to the package database whether it’s trampled by beta or fully-released software. Either way, it’s trampled. Then things break, and the users blame PackMan.

and given the feedback here I can see why even though I may not entirely agree with it.

I’m afraid that I need convincing that the feedback here hasn’t been caused by exactly this kind of trampling, whether by beta browsers or by other installs by users who use Packman “under duress” because they think they know better how to manage complex stuff like Shared Libraries.

I think the issue really comes down to mixing self installed and uniquely set up stuff and just letting a package manager do everything. If you mix the two then it can cause issues but is that a fault with Packman if someone installs via it first then tinkers with that install and wonders why an update fails?

Exactly. Which is why it is so problematic that there’s a couple of high profile pieces of software using Shared Libraries – libraries that are package managed by pretty much all of their other clients due to the complexity of getting the correct things in the right places – which don’t keep the package database updated when they’re installed.

It’s been explained many, many times that it is quite possible to stick a “package database aware” installer on to a CD or USB stick, and have it install the shared bits in a way that can co-exist with the other, pre-existing clients which are using package management. Such an installer wouldn’t use PackMan, or even need PackMan to be present… but it would work with PackMan if the latter were installed, and would simplify the installation of PackMan later on if not.

It looks like there are two versions of !Obrowser in existence. One where everything is embedded in the application folder and one that has an installer.

There is only one version of !OBrowser and !SharedLibs is not within the application. There is !Otter which is !Obrowser minus the RISCOS front end, that seems to depend on the updates to !SharedLib resources from Packman.

Iris which is officially still in beta does currently have a !SharedLibs within the application, so as not to potential polute the ‘default’ !SharedLibs within !Boot.resources Not ideal but I think a necessary evil at the moment.

I think the issue really comes down to mixing self installed and uniquely set up stuff and just letting a package manager do everything. If you mix the two then it can cause issues but is that a fault with Packman if someone installs via it first then tinkers with that install and wonders why an update fails?

Who said I was mixing package installs with what have been installed by default. I have no objection to package managers as long as they don’t remove modules etc, which do not need replacing, like in one case putting an older version in place of a new version, because that the version the dependancy said it should be! No warning was given. Hence why I have concerns about the way the package manager for RISC OS works in certain cases.

As long as people understand what they gain and what they lose by using Packman and adhering to guidelines then it works but if you take a “free” spirit approach then may be leave alone but don’t slate Packman because you like that freer choice.

What guidelines? You ask the package manager to install something, it should do so, but warn if removing or replacing with an older version for some unknown reason.

I am also not “slating” Packman, just expressing concern, in particular with regards to !SharedLibs and with some of the posts in another thread on these forums about Python 3.8 and which bits need to be installed to get things working and YouTubedl etc.

Who said I was mixing package installs with what have been installed by default. I have no objection to package managers as long as they don’t remove modules etc, which do not need replacing, like in one case putting an older version in place of a new version, because that the version the dependancy said it should be! No warning was given. Hence why I have concerns about the way the package manager for RISC OS works in certain cases.

So have you reported this to the developer, so that it can be investigated and, if necessary, fixed?

I am also not “slating” Packman, just expressing concern, in particular with regards to !SharedLibs and with some of the posts in another thread on these forums about Python 3.8 and which bits need to be installed to get things working and YouTubedl etc.

The conclusion of which was to install everything via PackMan.

Iris which is officially still in beta does currently have a !SharedLibs within the application, so as not to potential polute the ‘default’ !SharedLibs within !Boot.resources Not ideal but I think a necessary evil at the moment.

Which immediately breaks everything that uses !SharedLibs. The same thing happens with the similarly embedded version of !OBrowser.

Given that I’ve used Linux for years I have no argument against the use of a package management system. But the problem some of us now have is that we have been installing software for many years using other methods. And the ‘PackMan’ system clearly doesn’t fully take that into account.

So it is akin to the days when Linux management systems (plural) used to fall over each other.

Trying to imply that not using PackMan is a practice that ended before the web is clearly nonsense. 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.

Given that, I’d suggest that those developling and wishing to get PackMan to become universal may need to look more carefully at how to ensure it doesn’t mess up other things which it finds, and at least alerts the user and provides some kind of ‘skip that’ or ‘undo this’ options. Otherwise this kind of problem will continue.

Who said I was mixing package installs with what have been installed by default.

Hi Chris,

No one has said that, it was an observation that mixing things can cause issues.

Equally the recent issue around YTPlay/YouTube-dl came down to the fact that older setups and instructions confused things.

Packman is not perfect and as also highlighted before there may be a requirement for some sort of scan /merge facility.

In the meantime packman helps to ensure that the requirements for a particular program are met and as long as packman is used like any other installer, i.e good housekeeping practice is in place like backups etc, then it works well for some abet not for others as I acknowledge.

So have you reported this to the developer, so that it can be investigated and, if necessary, fixed?

I have already answered this upthread. It was already reported. I believe fixed that specific one.

The conclusion of which was to install everything via PackMan.

Hmm yes, like the other thread about YouTubedl, oh you need to install this bit and this bit from Packman for it to work. That is NOT a package management, that is a piecemeal install with no instructions and thus another reason why I have concerns about package managers as such. i.e in that example its NOT a PACKAGE being installed by loads of bits of software that should really be packaged.

Which immediately breaks everything that uses !SharedLibs. The same thing happens with the similarly embedded version of !OBrowser.

Can you not read! !SharedLibs is NOT within !OBrowser. Stop casting blame on others for the the way !SharedLibs is currently being done. Your updates to !SharedLibs for the plain !Otter broke !OBrowser as pointed out elsewhere at the time (its a while back when this was reported by someone else). Hence I have not installed those updates via Packman.

What is it about !Iris is BETA software using a BETA version of !SharedLibs currently. So rather then polute the active !SharedLibs used by other applications, its kept seperate. I have no issue with this for the time being – its a temporary measure.

As for Packman, where the application is actually a package, like for example say Cashbook, then I am happy to consider installing it via Packman. But I tend to use !Store for all my Applications instead, its personal choice at end of the day.

Trying to imply that not using PackMan is a practice that ended before the web is clearly nonsense. 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.

It was more a comment of the ‘traditonal way’ of installing on RISC OS.

No-one is forcing anyone to use PackMan but certain software is becoming increasingly difficult to manage by installing manually.
If may not be perfect but PackMan offers a solution to the problem of maintaining the SharedLibs folder without having to worry about all the interdependencies.

Hmm yes, like the other thread about YouTubedl, oh you need to install this bit and this bit from Packman for it to work.

That’s because not all the the dependencies are currently managed by PackMan. Once they are it will just be a case of installing YTPlay. The rest will be taken care of by PackMan.
The instructions will just be install or update YTPlay from PackMan.

Can you not read! !SharedLibs is NOT within !OBrowser. Stop casting blame on others for the the way !SharedLibs is currently being done. Your updates to !SharedLibs for the plain !Otter broke !OBrowser as pointed out elsewhere at the time (its a while back when this was reported by someone else). Hence I have not installed those updates via Packman.

I mentioned it previously. There are two versions of !Obrowser. One that embeds everything in the application folder and one that has an installer. Either way they both end up breaking !SharedLibs. Whether you believe that or not is up to you.

What is it about !Iris is BETA software using a BETA version of !SharedLibs currently. So rather then polute the active !SharedLibs used by other applications, its kept seperate. I have no issue with this for the time being – its a temporary measure.

But Iris doesn’t need to be distributed that way. It currently breaks a lot of existing software. If it was done via PackMan it would always be guaranteed to install and update correctly.

Iris which is officially still in beta

Okay, I’ve been reading here for a long time, reading other RISC OS sites for a long time and keeping an eye on RISC OS and its developments, but I’m getting a bit confused. Is Iris still in beta?

It’s not really related to this topic, so I’m going to ask a question elsewhere about it.

There is only one version of !OBrowser and !SharedLibs is not within the application.

Well, it is in the version I’ve got on my ‘old’ 5.28 install: the !OBrowser application contains a directory called Resources, and this contains roughly 132MB’s worth of !SharedLibs. It’s precisely because I discovered it was impossible to update Python /and/ keep OBrowser operational that I decided to go all in on the !PackMan route (see the ‘Updating Youtube-dl’ thread elsewhere). Otherwise, it seems to me, any given installation is condemned to increasing obsolescence as more recent innovations like Python are progressively updated. !OBrowser is useful, but I want to access YouTube, and possibly other stuff in the pipeline. Others are free to make different choices of course. Like it or not, we live in a world where shared libraries and other imports will be increasingly important, and therefore a package manager will be indispensible.

the !OBrowser application contains a directory called Resources, and this contains roughly 132MB’s worth of !SharedLibs. It’s precisely because I discovered it was impossible to update Python /and/ keep OBrowser operational that I decided to go all in on the !PackMan route (see the ‘Updating Youtube-dl’ thread elsewhere)

I would assume that if you pull out the SharedLibs chunk from OBrowser (hide it away in a safe place for a while), then use PackMan to ensure the up-to-date SharedLibs is installed and seen at boot then everything that requires SharedLibs – including OBrowser, should work.
Stating the obvious, but perhaps the people distributing Obrowser could do that for the regular release so that its “SharedLibs” use is er, actually Shared?

Hmm yes, like the other thread about YouTubedl, oh you need to install this bit and this bit from Packman for it to work.

Well as YTPlay is not packaged via Packman then is it any wonder you have to go hunting down bits.

It also highlighted that an old standalone non-managed YouTube-dl application was causing an issue.

All in all it just backs up the fact that a packaged version of YTplay with all it dependancies sorted out for you would have not led to the issue.

Is Iris still in beta?

Yes as far as it is not generally available to all users, not withstanding hardware/RISCOS version dependancies.

Asa far as I recall ROD stated they would be looking at making it available to those that purchased OBrowser soon and then to a wider audience later.

Drop ROD
a line and I am sure they will up date you.

That’s because not all the the dependencies are currently managed by PackMan.

So in that case why tell users to use Packman to install that way. Untill it is packaged as a single install, then we should not tell people to try via this method. Once it is properly packaged then fine.

Stating the obvious, but perhaps the people distributing Obrowser could do that for the regular release so that its “SharedLibs” use is er, actually Shared?

The version as supplied via the purchased CD here is provided with a merge facilty to updated !SharedLibs. As on the CD version here !SharedLibs is NOT within the application.

So in that case why tell users to use Packman to install that way. Untill it is packaged as a single install, then we should not tell people to try via this method. Once it is properly packaged then fine.

That applies to the dependencies that are already available via PackMan. Quite a few people have successfully done so and can play Youtube videos using YTPlay and Sargasso.

The version as supplied via the purchased CD here is provided with a merge facilty to updated !SharedLibs. As on the CD version here !SharedLibs is NOT within the application.

That’s the other version of Obrowser. There’s no reason why it couldn’t have been installed using PackMan. Then the issues with it wouldn’t have occurred.

Can you not read!

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

!SharedLibs is NOT within !OBrowser.

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

Stop casting blame on others for the the way !SharedLibs is currently being done.

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

What is it about !Iris is BETA software using a BETA version of !SharedLibs currently. So rather then polute the active !SharedLibs used by other applications, its kept seperate.

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.

I have no issue with this for the time being – its a temporary measure.

So long as everyone is fully aware of the problems that this causes, and the fact that the symptoms will very likely not show up in Iris but in innocent third party software, that’s fine. Is everyone fully aware of this? Even those not on the beta scheme, but who are reading the criticisms of PackMan in forums like this?

As for Packman, where the application is actually a package, like for example say Cashbook, then I am happy to consider installing it via Packman.

Why on earth would you choose to install CashBook, which requires no external dependencies aside from the Shared C Library, via package management, but actively refuse to use it for applications like Iris which have many complex dependencies shared with other software, and are the precise use case for a package management system?

Stating the obvious, but perhaps the people distributing Obrowser could do that for the regular release so that its “SharedLibs” use is er, actually Shared?

It has been suggested, including a way that it could work for installation CDs, but certainly my input seems to have fallen on deaf ears. I don’t know if anyone else has had more joy.

The irony is that sooner or later, OBrowser and Iris will need to use some form of package management — whether that’s PackMan or a custom CD-based installer which understands how to read and interact with the package database (and probably holds its payload in packages, too, since that will make deployment a lot easier as those packages will already exist). If they don’t, the support headache for ROD will be phenomenal, as guiding users in the complexities of manually updating shared resources will be a nightmare.

By then, of course, the poisoning of the package management well might have been so successful that there will be no choice but to provide a manual option… and the resource to support it and hold users’ hands when things get badly broken.

There’s no reason why it couldn’t have been installed using PackMan. Then the issues with it wouldn’t have occurred.

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

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

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.
It’s just a case of changing the instructions to install the prerequisites for !OBrowser via PackMan instead.