Official Release - CMOS

(It might be now, of course; I’ve not checked in a while.)

As a matter of fact, before writing the post you mentioned, I searched for the bleedin’ web page in question to check this. Turns out it’s dropped off the web.

o check this. Turns out it’s dropped off the web

The reason it’s not there anymore is because DirSync’s now under package management. See here
for an explanation.

I can’t agree with that particular developer’s intention to hide their package and insist the package manager is used. The worst-case should be a developer who won’t support a non-managed install, but I see no reason not to make the package zips available. Indeed, I’d like to make the format more friendly for manual installation (for example, for the directory with a skeleton boot sequence, call it !Boot not Boot as it currently is). I should point out that the riscos.info server-side stuff (which I’m using) links archives for manual installation – for example see http://packages.riscosopen.org/ (which is still in a very rough-and-ready state and needs plenty of work).

How hard would it be to give packman the option to present the files in an easy way like Store does for those who wish (or need) to do it manually?

First cut at a PackMan user’s manual
I haven’t had a chance to take any pictures, so it’s all in words as yet.

It might be feasible to add a ‘download package here’ button, but there’s already an ‘inspect contents of package’ feature (that’s how packaged programs are moved) and it’s important not to confuse matters.

Could there be an open archive option above install on the menu under Package ‘XXX’? It would open it if it is in the cache or fetch and open if it isn’t.

It would also be nice to have an option in choices for “I want to handle all installation manually”. So it becomes similar to store.

I can’t agree with that particular developer’s intention to hide their package and insist the package manager is used.

That’s me, I suppose:)

Although that was a coincidence and not at all a motivation, my webspace is full, so there’s no room for another zip without throwing away something else. So that is one reason not to provide the package myself. Of course I could have provided a link to the package, but my motivation was to get people to use the package manager. I think providing the link to the package defeats that point, it’s like saying “well, there’s this package manager, but really, just download it and do it yourself!”, I’m not going to do that…

Also, DirSync has another package it suggests you install, DSDiff. This package relies on DiffUtils. If I’d provide links to the packages I would have to provide links to all of these. And then I’d have to provide documentation how to install them and where and… well, you could use the package manager and get rid of all these problems. So that’s what I did.

If people want to download the packages themselves, fine. But I’m not going to promote it in any way.

Ah, it seems my website has been replaced by a message (in Norwegian) saying that my website will disappear 31.11.2012 (hm, when’s that??). Shouldn’t that mean my website is still there? Well, I can’t see it… Hm, that means I’m without webspace now, I suppose.

Maybe I should get my NAS to do some webserver stuff. (just now migrating from an old NAS to a new one…)

If people want to download the packages themselves, fine. But I’m not going to promote it in any way.

I am aware that the situation has changed with later versions of package management. However… when I tried some stuff from a popular site with a lot of packages (iconbar.com? riscos.info? I forget…), the package manager put the packages according to some predefined “this is where software goes”. Well, my filing system is not laid out anything like the ones provided on the boot discs. If I moved the installed package to a location benefitting my layout, the package manager will have “lost” it.

I’m very very happy that the ability to choose where to install is now a reality. I can look at package managing again (instead of pulling apart the zip files and reading the dependencies file manually); but perhaps it might be worth remembering that this discussion is coming across a little like a half-hearted holy war. People may have valid reasons to dislike package management (and off the top of my head, if we have multiple options and shared resources (UnixLib anybody?) how do we ensure it is all kept in sync?) and people may have daft reasons to dislike package management (too much like Unix, though I’m sure they be happy with any number of ported useful things like MP3 players and such <g>).

The way to win people over is to show them that package management not only works but takes away all that fiddly bull. They just ask the manager to see what needs updating, at least until it is capable if doing that for itself on a daily basis, at which point the thing pops up a notice telling the user what is new. Couldn’t be any damn simpler than:

XYZ has been updated to v1.23.45.67.89.b
one line of blurb from the author goes here
[ Read release notes ] [ Visit website ]
[ Update your copy ]   [ Remind me later]
[X] Don't notify me of updates to this package any more

The way to make the whole concept fail is to insult the user, patronise them, tell them they’re living in the dark ages, etc etc. This isn’t to suggest that YOU have done this, Jan-Jaap, but back on page one the word “dumb” popped up pretty quickly. Yeah, that’s the way to do it!

Ah, it seems my website has been replaced by a message (in Norwegian) saying that my website will disappear 31.11.2012 (hm, when’s that??).

Looking at the linked help page (via Google Translate), it looks like Tele2 is basically dumping all of their internet related stuff to concentrate on mobile. The date given, end-November, is when it’ll all cease.
It is, of course, rather crappy to pull the plug on a website like that, but I guess seeing as they’re throwing in the towel, they don’t care.
Can you still access the site content with ftp/sftp ?

Does your ISP not provide you with some webspace? I have a small lame site (my cow-orkers think that is my website!) through Orange. Not impressive, but it suffices for small stuff.

I’m very very happy that the ability to choose where to install is now a reality.

RiscPkg has always provided the possibility to put a skeleton app (like the ones in ResourceFS) that point to the real one. Although I’ve never taken this step myself, I’ve been thinking of putting all the RiscPkg packages somewhere in !Boot or whereever, putting the skeleton-Apps exactly where I want them.

Doesn’t that suffice? Is it really important to control where the apps are? I agree it is important to control where you want to start them from, but that’s not the same thing.

The way to win people over is to show them that package management not only works but takes away all that fiddly bull.

Well, it does and has done for some time… I used to update Netsurf very frequently. But now that the package for it seems to have gone, I hardly ever update Netsurf anymore… (I really should be asking somewhere about what happened and if there are any intentions to get it back).

Looking at the linked help page (via Google Translate), it looks like Tele2 is basically dumping all of their internet related stuff to concentrate on mobile. The date given, end-November, is when it’ll all cease.

Correct. I got an email about this as well, which I mostly ignored. So I suppose I should have known, but due to the virtues of RiscPkg, my website isn’t that important anymore… :-)

Can you still access the site content with ftp/sftp ?

Haven’t tried. But I have a local copy of the site, so nothing is lost apart from the webspace itself.

Does your ISP not provide you with some webspace?

Not sure, to be honest… As I said, I was thinking of using my NAS instead. However, I usually turn off my NAS during holidays and that might be unhelpfull when it is running my website…

Doesn’t that suffice? Is it really important to control where the apps are? I agree it is important to control where you want to start them from, but that’s not the same thing.

Riiiiight. So I’m to scatter around “skeleton apps” that point to the packaged ones because the packager wouldn’t allow me to put the software where I actually want it?
Can you not see the giant “WTF!?” in this concept? Can you not see that this is such a huge pile of FAIL that it is in danger of collapsing into its own event horizon?

The packager must maintain someplace a list of software it manages. Well, just write the software to <this location> and remember that. End of. No nonsense with skeletons, phantoms, ghosts, and minor-ranking demons, and the user is happy, not stressed. Win.

I’ve just been participating in a thread on the RPi forum – if you read from here onwards you realise how complicated installing things is for a RISC OS newbie. I’m just very sad that I couldn’t include GCC in the package list (PackMan seems to thrash the SD card more than the Filer does – a normal Filer GCC install takes about half an hour on a slow SD card, and I didn’t want to risk wearing out anyone’s card).

And I do think that moving apps is important – even on the ROOL distro, things are not laid out as the packages have them. So there’s already some pre-existing moves recorded when you start from scratch. Jan-Jaap, you want to put all your apps in !Boot with skeleton-Apps elsewhere. With the new moving apps feature, you can do that ;-) (but everyone else doesn’t have to)

NetSurf… I notice the test builds restarted a few days ago, but for manual install. If any NetSurf developers are listening, it would be really neat if these could be packaged once again :) Obviously that’s not going to be part of an official ‘stable’ distro, but the ability to keep track of ‘bleeding edge’ is quite handy. If there’s a stable NetSurf package available, I’ll happily make that available too.

Now things about PackMan are stable (ie I’m not panicking trying to work out why it nukes the !Boot.Loader partition), the wish list can start growing again… which is a good thing, in general :)

Doesn’t that suffice? Is it really important to control where the apps are? I agree it is important to control where you want to start them from, but that’s not the same thing.

It doesn’t really matter whether you or I think it suffices: if a sizeable chunk of your userbase won’t accept it, then it’s not going to work. Which I think is where we came in.

It doesn’t really matter whether you or I think it suffices: if a sizeable chunk of your userbase won’t accept it, then it’s not going to work. Which I think is where we came in.

This thing is it is working. I don’t know whether you’ve noticed or not but !PackMan is installed by default in the recently launched Raspberry Pi distribution. Already you can see on the Raspberry Pi forums that users who have never used RISC OS before are having trouble locating and installing software on RISC OS.
All it takes it to explain how to use !Packman. It may not be the best package management software in the world but it works and is simple to use. The source code is available and it’s being actively developed.
If the use of RISC OS on the Raspberry Pi takes off in even a small way those small number of decenters will just be a distant memory.
There are lots of complaints about package management systems on other platforms but most people still use them. I use linux mint debian edition. It has nearly 18000 packages available by default. I can’t even begin to imagine how you’d deal with finding and keeping the packages up to date without one.
There are about 150 available in !PackMan at the moment. That number is only likely to increase. You may not have a use for any of them but they’re there if you need them a few mouse clicks away. Without having to hunt around for dependancies or the most up to date version.
If you or those you feel you ‘represent’ don’t want to use it then fair enough but don’t keep going on about it as though it’s going to drive everyone away from RISC OS. It clearly isn’t. Most have already gone.
The potential number of new or returning users to RISC OS with the Raspberry Pi could quite quickly dwarf the number of existing users.

It doesn’t really matter whether you or I think it suffices: if a sizeable chunk of your userbase won’t accept it, then it’s not going to work. Which I think is where we came in.

And I’d like to know why it isn’t accepted. I don’t understand it. I can’t recall anyone ever having stated to hate the Apps icon on the iconbar because they’re only skeleton-apps, and yet the concept is exactly the same.

What I’d like to change about PackMan (I haven’t seen this new version, mind you) is it putting the apps in a flat structure somewhere out of sight, so no subdirectories for “Disc” and “Text” and whatever, just one dir with all the apps, out of sight. And then an easy way to save the skeleton apps exactly where you want them. That way finding the actual app is easy, only one directory to check. And the skeleton-apps follow the structure the user has chosen for them.

What I’d like to change about PackMan (I haven’t seen this new version, mind you) is it putting the apps in a flat structure somewhere out of sight, so no subdirectories for “Disc” and “Text” and whatever, just one dir with all the apps, out of sight.

In other words, you want RISC OS to abandon the notion of self-contained application directories, and switch to opaque, arcane installation procedures like Linux’s, where every application must be installed as root and feels entitled to dump its data in several obscure non-userland places and squirrel away its binary god-knows-where.

Have you ever considered that perhaps you might be happier simply not using RISC OS at all? Perhaps we should also remove the ‘Back’ button from all windows on the basis that no other operating systems have one and so therefore it’s undesirable?

The quality of debate on both sides of the packaging argument is really pathetic. Antis dislike packaging because it reminds them too much of Linux. Pros dislike existing, longstanding RISC OS features like application directories because they don’t remind them enough of Linux. Can we please just have the right tool for the right job, and reap the benefits of package management, without trying to force RISC OS to be something which it quite plainly isn’t for no reason other than ideology?

dumb

As the originator of this comment I should point out that it was directed at those who refused to upgrade because something was packaged. As it appears from later postings, there are no such people, what actually happened was the location of the package files was not published, so that upgrade was not simple without using the packager. This is a totally different situation.

Riiiiight. So I’m to scatter around “skeleton apps” that point to the packaged ones because the packager wouldn’t allow me to put the software where I actually want it?
Can you not see the giant “WTF!?” in this concept? Can you not see that this is such a huge pile of FAIL that it is in danger of collapsing into its own event horizon?

The Skeleton apps are just the RISC OS equivalent of links or shortcuts.

I take the opposite view from you, it seems. I feel that a packager should restrict what it does to specified directories (i.e. location of system components plus a defined location.) If I put an application in a different folder, I don’t want to find that the packager has upgraded it for me. I prefer a shortcut to the version I expect it to play with.

The old RiscPkg client only worked fine for my way of thinking.

Packman now also works for your way of thinking.

However it is not compatible with the third way of thinking, which is people who want or need to do it manually. Store is. (And Packman would only need a small change.)

A point for those who appear to be of the opinion that the entire packacking process should always be used:

What about someone with a RISC OS machine that is not online? (e.g. IRUG’s Risc PC).

With another RISC OS system online, the store approach is fine, but what if the only means of download is a PC then you need access to the original package link.

Antis dislike packaging because it reminds them too much of Linux. Pros dislike existing, longstanding RISC OS features like application directories because they don’t remind them enough of Linux.

Personally I’d like to see all the packages out of the way in resources, and then have a packagesFS where the whole thing is managed by filer.

Antis dislike packaging because it reminds them too much of Linux. Pros dislike existing, longstanding RISC OS features like application directories because they don’t remind them enough of Linux. Can we please just have the right tool for the right job, and reap the benefits of package management, without trying to force RISC OS to be something which it quite plainly isn’t for no reason other than ideology?

Well, I’m pro packing as it sorts out the dependencies, however despite using linux quite a bit (not least as the base for the RADIUS server at work) many aspects of linux behaviour get right on my ….
The location of executables is one such. (bin, sbin, usr, share plus sub-directories and combinations. Oh and what wonderful fun to scatter the configuration all over the shop.

n other words, you want RISC OS to abandon the notion of self-contained application directories, and

I don’t think that Jan-Jaap is mandating that these things should be used. It’s just a suggestion which may or may not be useful.

Perhaps we should also remove the ‘Back’ button from all windows on the basis that no other operating systems have one and so therefore it’s undesirable?

You seem to have joined the ‘what next brigade’. You’re not a Daily Mail reader by any chance? :)

I think some are confused why yourself, Steve F. and possibly others are making such a fuss over a Package management application that has a certain amount of control over where things are installed.
Package management seems the natural thing to do once the number of applications grows to the point where it becomes unmanagable. There needs to be a certain amount of control.

All RISC OS needs is an application that downloads and installs applications which manages dependancies and upgrades for you. !PackMan does that now. It helps to avoid the chaos of having to download different versions with multiple dependancies manually.

What about someone with a RISC OS machine that is not online? (e.g. IRUG’s Risc PC).

With another RISC OS system online, the store approach is fine, but what if the only means of download is a PC then you need access to the original package link.

All PackMan needs is a simple web server set up with the ‘package source file’ pointing to the downloaded packages.

A package manager may be fine for completely new installs – eg a new user to RISC OS. The problem is that the current offering(s) of package manager has a lot of problems with conflicts etc on established systems. For example, as suggested in the forum a day or so ago, I thought I would install Packit to see what would be involved in packaging some of my own software. It fails to install because there is a conflict – I already have the Tabs module in !System. I know how to fix that, but a lot of users may not.

Yesterday I installed an app I had never used before to try it. Unfortunately Packman crashed and exited during the install. The app did appear to be installed, and worked, but again the user experience is not what it might be.

If a user is lukewarm about packaging to start with, then it wouldn’t take many such experiences to put them off completely.

I can’t recall anyone ever having stated to hate the Apps icon on the iconbar because they’re only skeleton-apps, and yet the concept is exactly the same.

Because Apps: is a virtual filesystem. The apps don’t really exist there, *AddApp just creates a link from the Apps resource to the real application.

Not quite the same as stashing applications someplace on a real filing system, and linking to it from somewhere else on the same filing system because the installation dodah was incapable of putting it there in the first place.

For example, as suggested in the forum a day or so ago, I thought I would install Packit to see what would be involved in packaging some of my own software. It fails to install because there is a conflict – I already have the Tabs module in !System. I know how to fix that, but a lot of users may not.

The version of !PackMan installed on the Raspberry Pi has the option to back up the existing files if there are any conflicts.

Unfortunately Packman crashed and exited during the install.

Hopefully as time goes on most of these type of problems will be ironed out.