Here's an idea: If there are ever different size variants of the ISOs, e.g. micro, mini, full, etc.; if the source for that disc's packages will fit on that disc with the binaries, ship a binary-only iso and a bin+src iso. Otherwise, ship mostly separate binary and source ISOs.
However, in following the tradition laid down by a few Linux distributions, namely Slackware, include the base system source on the binary disc(s). In every case, this is the kernel, but ideally include source for the command interpreter and other core system things shipped with a minimal install. If the counterargument here is "but the user must install...", gonna cut you off riiiiight there and point out that every Linux distribution that ships the Linux kernel source code alongside an otherwise binary-only release has exactly the same requirements - install GNU make and GCC, etc., to use said source code. We're still shipping development tools on the release disk, yes? Not just end user things? On Fri, Sep 27, 2024, 17:51 Jerome Shidel via Freedos-devel < freedos-devel@lists.sourceforge.net> wrote: > > > > On Sep 27, 2024, at 6:24 PM, Michael Brutman via Freedos-devel < > freedos-devel@lists.sourceforge.net> wrote: > > > > > > > > I expect that all of the binaries and source are up to date at the time > they are packaged, and that is a large effort - thank you! > > > > But some projects are still active and move independently of FreeDOS. > mTCP (my project) is one such example, and with years between the FreeDOS > releases the binaries get stale fairly often. > > > > There isn't much that can be done about the binaries getting stale, as a > distribution is a snapshot of what was available at the time. But I'd love > to find a way where FreeDOS doesn't have to take responsibility for > shipping source code too. For active projects it's much more desirable to > mirror the source code that matches the shipped binaries, but to refer > people to the current source code, not a historic snapshot of the source > code. > > > > I'm trying to fix the binary staleness problem by including a small > utility that people can run to see if they are up to date. I don't really > know how to solve it for the source code, other than for just to plaster > use warnings on the source code letting people know that it is probably out > of date already. And that seems sub-optimal. > > > > > > Help me understand the GitLab environment for something like mTCP - is > it just repackaging the binaries and source that I provide on my web site, > or is it going further to recompile things? (I used to know this but I > have my hands full enough with mTCP ...) > > For mTCP, not much happens. > > The binaries and sources are simply placed in a directory structure that > is compatible with the package managers and consistent with other packages. > There are also a couple metadata files that are maintained as well. > > Things in the root directory of the project are for management purposes or > to ease browsing the package on GitLab. Anything in the project root is > specifically excluded from the FreeDOS compatible package. That includes > some CI/CD files that are used to provide a FreeDOS compatible package > directly from GitLab. The packages built by the CI/CD are not used by the > RBE. > > At present, none of the projects on GitLab use the CI/CD to rebuild > binaries from source. The CI/CD is only used to perform some basic > verifications and generate a FreeDOS compatible package. > > For mTCP specifically, it is just a matter of updating the binaries, > sources, documentation files in the project. Plus the version number in the > LSM file in the APPINFO directory. It is one of the easier projects to > update. :-) > > If LFN files are used, they get wrapped up into zip archives > automatically. > > So, yes. It is mostly just repacking. > > :-) > > > > > > > > > _______________________________________________ > > Freedos-devel mailing list > > Freedos-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/freedos-devel > > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel >
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
