Move HD pre-installed apps to PackMan to allow updating
Jon Abbott (1421) 2641 posts |
The Pi HD comes with various apps, some part of RISCOS, others 3rd party. To allow users to easily keep these up to date, it would be great if they were all packaged for distribution via PackMan and then installed to the HD image via PackMan so they can be updated quickly and easily. The current process of hunting around the internet for the latest version, then having to find pre-reqs such as SharedUnixLib, Tinct is not user friendly. 3rd party apps may require approval from the authors and obviously someone has to maintain them and keep them up to date, but this should hopefully already be happening with the HD image pre-installs, so it’s not that big a leap to move to packaged distros. The other advantage to distributing software this route is the user can easily remove (or add) software they do or don’t want in the OS install. |
Steve Pampling (1551) 8155 posts |
I didn’t think Tinct was ARMv7 friendly :) but yes I do understand your point in general.
Some people are a bit vocal about where package managers put the software vs where they want to put that software. Take a deep breath and wait for them to say something negative. |
John Williams (567) 768 posts |
May I just point out that the correct “ectriture”, or perhaps “rendition” is “RISC OS”. The approved verbal rendition is “RISC” “O” “S”, though I myself have trouble with that! However, we do need to maintain standards to some level! May I recommend Pluto’s auto-correction facility! What a pity it doesn’t work on fora (or, as I would prefer, forums, not being a pedant grade 1). John |
John Williams (567) 768 posts |
Look at the title bar! |
Colin (478) 2433 posts |
:-) Better still ROOL can supply a vanilla PI/harddisc4 image and someone else can offer/support an ‘extras’ package. Or as an absolute maximum just supply packman and people can install what they want – or delete it if they want. That way you can encourage people to use packman |
Jon Abbott (1421) 2641 posts |
This was one I had to manually update when I updated NetSurf to an the latest version (which seems to fix the Page Zero access I was seeing with the pre-installed version on the HD image)
This could of course be an option for developers or folk running servers that don’t need all the bloatware or just want a small install. |
Alan Buckley (167) 232 posts |
And due to this PackMan was changed. For many years it allowed you to move things after they were installed and more recently gives you a suggested location which you can override before installing. There are a few exceptions of course. Some packages haven’t been updated yet and some things do have to go in a specific place. |
Alan Buckley (167) 232 posts |
This should be possible. I believe ROOL have even talked about this before. I have had various email conversations, but nothing got to a stage where I had enough feedback to pursue it. It’s relatively easy to set up. You just need a zip program, write the control and copyright files and look into dependencies. The hard part is to pull the correct version number from the source tree. To get this to happen, I have a few questions: The main thing is how to integrate this into the ROOL build system. We could start by just creating a few packages to get the system going and then add more and more as time goes on until most of the HardDisc is covered. As the author of PackMan I’m more than happy to make any adjustments to how it works, if any are required, to it to make this happen. |
Jeffrey Lee (213) 6048 posts |
I’d say that they should come from the source build process. The way I’d do it would probably be as follows:
Each component has a VersionNum file which contains the version number and date, e..g Paint. This is what’s used to generate the version number & date strings for both modules and applications. Apart from being a valid C header, there’s also an awk script which parses the file and injects the version/date into other files – that’s probably your best bet if the data needs to be injected into any package control files.
During the build, you’d probably want a new, top-level ‘Packages’ directory in the build tree. After the build, you’d want them to be uploaded here: http://packages.riscosopen.org/ I believe Theo Markettos is the mastermind behind that area of the site. Presumably he or someone at ROOL would be responsible for writing the script which scans the output folder and uploads new packages It may also be worth taking a look at the ABRelease component which handles packaging of ROMs and the disc image ready for upload (this component implements a special release_autobuild build phase that isn’t currently exposed through the !Builder UI).
Indeed! Also note that it’s possible that in previous discussions people may have come to different conclusions than me on how to do this kind of stuff (but I can’t remember which threads those discussions were in, and it’s probable there were some email discussions which I haven’t been a part of either). Theo or a ROOL staffer might be your best bet for finding out what the current plan of action is. |
David Feugey (2125) 2709 posts |
I have one suggestion: to be able to make packages based on third party zip files. for example a ‘take the file x and directory y from the zip file downloadable at this place, then take the patch x from this other zip file’. I could for example make a package for SPatience based on original SPatience archive and the RISC OS FR’s patch. No need to ask author and RISC OS FR authorization, since their work will not be inside the archive. Of course, a way to alert the maintainer when the third party zip is changed (or not available any more) would be great. |
Alan Buckley (167) 232 posts |
I can see why this would be useful, but it unfortunately doesn’t fit well. All the files for a package need to be in the package file and the copyright and distribution rights need to be clear. In most cases I try to contact the author(s) for their permission (even when the copyright and distribution rights don’t require it). Most I’ve asked are OK to let their software be packaged even if they are not interested in the packaging themselves. |
Jess Hampshire (158) 865 posts |
Wouldn’t it be possible to package a fetcher program/script as though it is the actual program. When it is executed, it would fetch the files and populate the package folder as though it were normally packaged, and run the program normally the next time. To make this easier, packman would need an option for run a custom installer on the initial setup, and options to patch files, rather than replace them on update. However back on to the main subject, I would like packman to be able to manage the whole !Boot too, including softloads. Meaning if the ROM had it, hdform, and working DHCP, it would be possible to do an over the air install with only the ROM image. |
Alan Buckley (167) 232 posts |
I don’t think this would be possible, or if it was it would probably over complicate things. However, package folder for a downloaded hard disc image could be set up with the information on what is already installed.
As far a I can see there will always need to be a minimal boot system, to start with. Most of the components within it can probably be packaged, but I’m expecting there will always need to be something that needs to be there first. |
Alan Buckley (167) 232 posts |
I’ve downloaded and had a look at the build system now and can see how packaging may be added in the individual make files at least. I really need to shell out £50 for the DDE next, so I can look at it running. Christmas is coming soon though! Can AMU do any text transformation in the makefile? Or would it need an external program to set a variable for it to use? I really need to get the version in dotted form and transform it so the dots are replaced with slashes for file names so I can create the package file name. |
David Feugey (2125) 2709 posts |
Quick suggestion: date of release in the software list (or detail). |
Jeffrey Lee (213) 6048 posts |
I suspect you’ll have to use an external program. |
Jess Hampshire (158) 865 posts |
I would envisage a minimal !Boot along with !HForm !Packman and a configure option for the boot drive being in resourcefs in the ROM. On the Pi, (with the current state of partition support), this should allow RISC OS to be downloaded with NOOBS, with minimal data used on the SD card, and the the rest of the system be installed on a USB drive. |
Alan Buckley (167) 232 posts |
I’ve started to try a few things out for this now and have managed to add a package target to the Maestro make file that will create a package for it. |
Jeffrey Lee (213) 6048 posts |
It’s zipped up under RISC OS, as part of the release_autobuild phase (which isn’t accessible from !Builder, but can be invoked by running srcbuild manually). Specifically it’s the ABRelease component which handles the zipping up of the disc image, ROMs, etc. – see Resources.DiscDev.release_autobuild. Also note that if you do try invoking release_autobuild manually, there are a couple of system variables you need to set. I’m not 100% sure what they are, but looking at the ABRelease makefile it looks like they’re AutoBuild$Root (root output directory) and AutoBuild$Build (subdirectory for the current build, e.g. DIscDev) |