ghaerr
Suggestion: Package Manager.
As I see most people who have ELKS on their PC have Ethernet cards, and there being a tiny amount of programs bundled with elks, a package manager would be cool to see.
Hello @Sasytoremember,
Thank you for the suggestion! Although this is a good idea, I fear we it may be a while before ELKS is ready for an outside package manager, mostly because of 1) compilation outside of ELKS isn't currently supported well (although I'm working on that), and 2) one must setup and compile a special toolchain, and the C library for that toolchain and ELKS live inside the ELKS source tree. (Moving libc out of the ELKS tree has its own issues, so that may not happen as quickly).
That said, it would be nice to be able to install newer versions of programs already built from the ELKS tree, without having to replace the existing running filesystem with the default built disk image. I think @Mellvik is working on something like that, which uses the network for transport and installation. (Perhaps this is what you were requesting in the first place? :)
Thank you!
Thank you @ghaerr, hi @linuxbash, hi @sasytoremember.
Yes, that would be something! As ELKS grows it does indeed get harder to keep track of things, in particular for visitors dropping by every now and then, but also for those of us living with ELKS daily. That said, ELKS is still small (and smaller than many, maybe most package managers) and the requirements are different from larger systems. The entire system is really a package. IOW a package manager is probably overkill.
Your question did trigger some thinking though. And like @ghaerr points out, I've been experimenting with various approaches to simplify updating running systems with new binaries. Pre-built HD images are fine for emulators, and the floppy images are fine for physical systems, but a running system needs a way to be kept up to date without overwriting local configurations. So far, ftp and tar files have been sufficient, but a more automated regime would be desirable. BTW - by 'automated' I don't mean automatic updates of a running system, but more or less automatic building of the components required to make such updates simple.
Towards that, here are some ideas covering what I've been missing:
-
An automatically generated tar file of a 'complete' system, built along with the HD images. A 'complete' system should possibly be configurable - or include all the stuff that goes onto hd images (which I've never used so I don't really know :-) ) - binaries that don't make it on floppy images, man-pages, /lib files like bootblock.bin, etc.
-
A script on ELKS that fetches this file via ftp/urlget and installs updated files (I'm not sure the ELKS tar command has a 'dont-overwrite-newer' option, we should add that).
This (let's call it the pull-scheme) would require the development host to have a working ftp server without too many security restrictions, which may be a problem. Doing it the other way (push scheme) may be more 'predictable', but would also require more resources on the ELKS system (ELKS has cron but it isn't activated by default for that reason - we're running out of process slots and memory).
I've also been planning on writing a script (on ELKS) to collect locally modified (configuration) files into a tar file for easy transfer to some host (backup). Files like /etc/{hosts,inittab,mount.cfg,net.cfg}, /bootopts, shell startup files, files in home directories (!), ...
I'm thinking loud here, so let's keep this thread open for a bit and discuss what's a reasonable balance between practical usefulness and cost (time, resources).
@ghaerr, I suggest we start with a 'complete system' (compressed) tar-file, that would be very helpful. What do you think?
—M
- aug. 2022 kl. 03:17 skrev Gregory Haerr @.***>:
Hello @Sasytoremember https://github.com/Sasytoremember,
Thank you for the suggestion! Although this is a good idea, I fear we it may be a while before ELKS is ready for than outside package manageris, mostly because of 1) compilation outside of ELKS isn't currently supported well (although I'm working on that), and 2) one must setup and compile a special toolchain, and the C library for that toolchain and ELKS live inside the ELKS source tree. (Moving libc out of the ELKS tree has its own issues, so that may not happen as quickly).
That said, it would be nice to be able to install newer versions of programs already built from the ELKS tree, without having to replace the existing running filesystem with the default built disk image. I think @Mellvik https://github.com/Mellvik is working on something like that, which uses the network for transport and installation. (Perhaps this is what you were requesting in the first place? :)
Thank you!
— Reply to this email directly, view it on GitHub https://github.com/jbruchon/elks/issues/1390#issuecomment-1214261307, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3WGOA6YMNUBF6CQK36N7TVZBCLZANCNFSM55QIXKQA. You are receiving this because you were mentioned.
Hello @Mellvik,
Thanks for your many interesting ideas on updating existing ELKS installations, its nice to have them all here in one place, to fully contemplate the issues and possible solutions.
a running system needs a way to be kept up to date without overwriting local configurations.
Yes - perhaps we need a list of what exactly what files constitute a local configuration, so that they might be automatically extracted from an update utility.
A script on ELKS that fetches this file via ftp/urlget and installs updated files (I'm not sure the ELKS tar command has a 'dont-overwrite-newer' option, we should add that).
The script idea is nice, but the tar 'dont-overwrite-newer' option won't work, as almost all files produced will always have a later date than the prior version, and thus would be overwritten needlessly.
I suggest we start with a 'complete system' (compressed) tar-file, that would be very helpful.
Preparing a tar file from a build would be easy, but I think we should still discuss more about how it will be used on the real hardware, what exactly should it contain, its directory structure, whether a .config option is necessary, etc.
Thank you!
Thank you @ghaerr, it seems we're off to a good start already - with the thinking. And yes, I do think this should eventually become a .config option.
Here's the dream goal (push version):
issue the command eupdate <host> e.g.
eupdate elks17
to build and submit a compressed tar file to the named ELKS system - per some specifications in a file. And then process that file with tar or some script on the ELKS side.
Or (pull version) issue a similar eupdate command from ELKS which does essentially the same thing and requires some setup on the host side.
In both cases we would need a config file on the development host describing the details, some of which we've already mentioned.
Like
[host]
name=elks17
ip=10.0.2.17
skip=
The log file updates should ideally be triggered by some kind of confirmation from the target system ensuring the at the update was actually installed, not just generated.
A good thing about such an approach is that is lends itself to a step by step process. Like, the first step being the config file, a package/group named 'all' and a script reading it to build the tar file. No log, no transfer, just the tar-file - to be transferred manually. And take it from there.
We would find new and better/more convenient ways to do things as we move along.
My 2cents …
-M
- aug. 2022 kl. 17:08 skrev Gregory Haerr @.***>:
Hello @Mellvik https://github.com/Mellvik,
Thanks for your many interesting ideas on updating existing ELKS installations, its nice to have them all here in one place, to fully contemplate the issues and possible solutions.
a running system needs a way to be kept up to date without overwriting local configurations.
Yes - perhaps we need a list of what exactly what files constitute a local configuration, so that they might be automatically extracted from an update utility.
A script on ELKS that fetches this file via ftp/urlget and installs updated files (I'm not sure the ELKS tar command has a 'dont-overwrite-newer' option, we should add that).
The script idea is nice, but the tar 'dont-overwrite-newer' option won't work, as almost all files produced will always have a later date than the prior version, and thus would be overwritten needlessly.
I suggest we start with a 'complete system' (compressed) tar-file, that would be very helpful.
Preparing a tar file from a build would be easy, but I think we should still discuss more about how it will be used on the real hardware, what exactly should it contain, its directory structure, whether a .config option is necessary, etc.
Thank you!
— Reply to this email directly, view it on GitHub https://github.com/jbruchon/elks/issues/1390#issuecomment-1215132586, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3WGOAUB4DU64R2NBXYF73VZJMNVANCNFSM55QIXKQA. You are receiving this because you were mentioned.
As I see most people who have ELKS on their PC have Ethernet cards, and there being a tiny amount of programs bundled with elks, a package manager would be cool to see.
@Sasytoremember good idea. Even FreeDOS has the network packaging system http://wiki.freedos.org/wiki/index.php/FDNPKG .
