Good day,
Hived off from the PrintPDF thread...

I selected one small item (!FontMenu) to work on from the updated list,
and singularly that downloaded and installed on this VRPC-DL RISC OS 6.20 machine to HostFS::HardDisc4.$.Apps.Font without any errors.

As noted in the other place, I have a couple of questions. :-)

Q1:

Where is the configuration that gives me a writable into which I can
specify the directory I want the item(s) installed?

Q2:
I do not *ever* want this app to install anything anywhere other than the
place I configure it to be done in.?

Q3:
That means *Never Ever* in "HostFS::HardDisc4.$.Apps."

Thanks :-)

Dave

--

Dave Triffid

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <59daec6c70dave@triffid.co.uk>
on 18 Apr 2022 Dave wrote:

I selected one small item (!FontMenu) to work on from the updated list, and singularly that downloaded and installed on this VRPC-DL RISC OS 6.20
machine to HostFS::HardDisc4.$.Apps.Font without any errors.

As noted in the other place, I have a couple of questions. :-)

Q1:

Where is the configuration that gives me a writable into which I can
specify the directory I want the item(s) installed?

Not all packages can be configured like this. It depends on whether the package maintainer has indicated that the applications are safe to move from their default locations. In this case, the package maintainer has not
flagged !FontMenu as safe to move.

You can tell this because when you double click on the package in PackMan, no components are shown in the area just above the Install button, and when you click to Install, the next window shows "No configurable components".

Bu contrast, try FTPc. You will see that in both dialogue boxes something appears in the components area, and in the Install window you have an area showing "Boot options" and an icon you can drag to define the location it should be installed to. If a package has several components they can often
be dragged individually to different locations.

Q2: I do not *ever* want this app to install anything anywhere other than
the place I configure it to be done in.?

I understand that sentiment. I quite agree! Fortunately the packages I've tried installing have all allowed me to move them during the installation process.

The original packaging system insisted on everything going in subdirectories
of Apps. A packaging system has to know where everything is so that it can
be updated and uninstalled when required, and the original tools took the
easy approach of forcing eveyrthing to be in particular locations. This affected uptake of the system as a lot of users did not like that. Alan Buckley has put in a lot of work to make the system more flexible, and I
think it will now suit a lot more people. It does depend on the packages
being constructed properly though. This is because for some packages they really do have to go in particular places if they are going to work.

An email to the package maintainer for FontMenu (Richard Swetman - his
details can be seen by double-clicking the package) might deal with the issue for FontMenu. He may have just failed to specify the fact that the
application is safe to move when he created the package. I made this mistake for one or two of the packages I was creating over the weekend, but I spotted it before I released them.

Hope that helps explain it!

--
Matthew Phillips
Durham

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <1a35f4da59.Matthew@sinenomine.co.uk>
Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

In message <59daec6c70dave@triffid.co.uk>
on 18 Apr 2022 Dave wrote:

[snip]

Q2: I do not *ever* want this app to install anything anywhere other
than the place I configure it to be done in.?

I understand that sentiment. I quite agree! Fortunately the packages
I've tried installing have all allowed me to move them during the installation process.

[snip]

For this reason I thought I might start using PackMan as it seems to be
being pushed and does announce updates. My experience was that it still
leaves abandoned directories in $.Apps.

If Apps was intended as a dump for any application that didn't have a
fixed home, why have the 'Add to Apps' config?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <1a35f4da59.Matthew@sinenomine.co.uk>,
Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

In message <59daec6c70dave@triffid.co.uk>
on 18 Apr 2022 Dave wrote:

I selected one small item (!FontMenu) to work on from the updated
list, and singularly that downloaded and installed on this VRPC-DL
RISC OS 6.20 machine to HostFS::HardDisc4.$.Apps.Font without any
errors.

As noted in the other place, I have a couple of questions. :-)

Q1:

Where is the configuration that gives me a writable into which I can specify the directory I want the item(s) installed?

Not all packages can be configured like this. It depends on whether the package maintainer has indicated that the applications are safe to move
from their default locations. In this case, the package maintainer has
not flagged !FontMenu as safe to move.

You can tell this because when you double click on the package in
PackMan, no components are shown in the area just above the Install
button, and when you click to Install, the next window shows "No
configurable components".

By contrast, try FTPc. You will see that in both dialogue boxes
something appears in the components area, and in the Install window you
have an area showing "Boot options" and an icon you can drag to define
the location it should be installed to. If a package has several
components they can often be dragged individually to different locations.

I've noted what you've written and that does indeed work as you describe.

Shame that the same can't be done with singular Apps like FontMenu.

Q2: I do not *ever* want this app to install anything anywhere other
than the place I configure it to be done in.?

I understand that sentiment. I quite agree! Fortunately the packages
I've tried installing have all allowed me to move them during the installation process.

The original packaging system insisted on everything going in
subdirectories of Apps. A packaging system has to know where everything
is so that it can be updated and uninstalled when required, and the
original tools took the easy approach of forcing eveyrthing to be in particular locations. This affected uptake of the system as a lot of
users did not like that. Alan Buckley has put in a lot of work to make
the system more flexible, and I think it will now suit a lot more
people. It does depend on the packages being constructed properly
though. This is because for some packages they really do have to go in particular places if they are going to work.

An email to the package maintainer for FontMenu (Richard Swetman - his details can be seen by double-clicking the package) might deal with the
issue for FontMenu. He may have just failed to specify the fact that
the application is safe to move when he created the package. I made
this mistake for one or two of the packages I was creating over the
weekend, but I spotted it before I released them.

Hope that helps explain it!

Thank you for the above Matthew, it does indeed explain a lot.

FontMenu is really neither here nor there, I just picked on that to
download as a test...

Dave :-)

--

Dave Triffid

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <mpro.rajf5u007e59400js@ypical.nospam.invalid>
on 18 Apr 2022 Frederick Bambrough wrote:

For this reason I thought I might start using PackMan as it seems to be
being pushed and does announce updates. My experience was that it still leaves abandoned directories in $.Apps.

I tried installing FontMenu earlier, which was forced into Apps.Fonts. After removing it again via PackMan, the Fonts directory was deleted again, so it certainly cleans up in some circumstances.

If Apps was intended as a dump for any application that didn't have a
fixed home, why have the 'Add to Apps' config?

There is a difference between Apps the directory on the hard drive and Resources:$.Apps which is the virtual filesystem you access from Apps on the iconbar.

In the standard boot sequence all applications in the immediate Apps
directory on the hard drive (but not its subdirectories) are added to Resources:$.Apps and the user can choose to add other applications to Resources:$.Apps which can be stored anywhere on the hard drive (or on other filing systems). At various stages in RISC OS history some of the bundled applcations have been ROM-based, and so !Edit, !Paint and !Draw were among those applications appearing in Resources:$.Apps but when supplied in ROM
they will not have been anywhere on the hard drive.

The original instigator of the packaging project clearly felt that putting everything in the Apps directory on the hard drive was the tidiest way to
keep things under control, but this ignored the fact that Acorn-issued hard disc arrangements had for a long while had a number of other directories,
like Diversions, Printing, Utilities and users had followed suit and created more.

On a Linux system, where packaging was first popularised, the packages get installed in fixed locations, in fact in areas that cannot be written to
by the ordinary user. This makes it much easier for the packaging tools and means there is much less risk of confusion.

--
Matthew Phillips
Durham

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <6cb93bdb59.Matthew@sinenomine.co.uk>
Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

In message <mpro.rajf5u007e59400js@ypical.nospam.invalid>
on 18 Apr 2022 Frederick Bambrough wrote:

For this reason I thought I might start using PackMan as it seems to
be being pushed and does announce updates. My experience was that it
still leaves abandoned directories in $.Apps.

I tried installing FontMenu earlier, which was forced into Apps.Fonts.
After removing it again via PackMan, the Fonts directory was deleted
again, so it certainly cleans up in some circumstances.

[snip]

I found that PackMan created the empty directories in $.Apps when
configured to install an application elsewhere.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <mpro.rak1pi00425vb014x@ypical.nospam.invalid>
Frederick Bambrough <freddie@[127.0.0.1]> wrote:

In message <6cb93bdb59.Matthew@sinenomine.co.uk>
Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

In message <mpro.rajf5u007e59400js@ypical.nospam.invalid>
on 18 Apr 2022 Frederick Bambrough wrote:

For this reason I thought I might start using PackMan as it seems to
be being pushed and does announce updates. My experience was that it
still leaves abandoned directories in $.Apps.

I tried installing FontMenu earlier, which was forced into Apps.Fonts.
After removing it again via PackMan, the Fonts directory was deleted
again, so it certainly cleans up in some circumstances.

[snip]

I found that PackMan created the empty directories in $.Apps when
configured to install an application elsewhere.

Has this issue been reported to the Packman developer? Its could be a bug
that not been reported by anyone yet.

If people do not report issue to the developers, they they don't get
fixed.


--
Chris Hughes
Don't miss this years Wakefield Show 21st May 2022 - we have move to
Cedar Court Hotel, Bradford
check the latest information at www.wakefieldshow.org.uk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <e8d97fdb59.chris@mytarbis.plus.com>
on 19 Apr 2022 Chris Hughes wrote:

In message <mpro.rak1pi00425vb014x@ypical.nospam.invalid>
Frederick Bambrough <freddie@[127.0.0.1]> wrote:

I found that PackMan created the empty directories in $.Apps when configured to install an application elsewhere.

Has this issue been reported to the Packman developer? Its could be a bug that not been reported by anyone yet.

If people do not report issue to the developers, they they don't get
fixed.

I emailed Alan yesterday. He responded pretty quickly about another issue I had noticed.

--
Matthew Phillips
Durham

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)