Hey Jerome, On Tue, Dec 3, 2024 at 1:19 AM Jerome Shidel via Freedos-devel < freedos-devel@lists.sourceforge.net> wrote:
> > 0.8.3c would have been some changes made to the 0.8.3b version. It got a > version bump so it would not be confused with the existing 0.8.3b package > by any of the programs that update packages. > > Hmm wouldn't it be better to have a separate package revision, e.g. like Debian linux does with its packages, instead of introducing random version bumps? So for example the freedos DOG could be marked as version 0.8.5b-3 meaning that this is version 0.8.5b of DOG 3rd revision of the package (meaning that you e.g. fixed some thing in how it's packaged (by moving some files around for example). However, the process will be different when FreeDOS 1.4 is released. > Because I manually jammed the packages into that repo, they do not have the > additional metadata for the modified-date inserted into them. When 1.4 > comes out, I will use the management software to add them and therefore > they will get the additional field data inserted. > Ah okay, that explains that. > As for the 1.3 and unstable repositories lagging behind on updates… I will > get around to them eventually when I have the time and energy to update > them. > Thanks for doing the heavy lifting of managing the repository! :D > Part of the problem is that when a package is updated, it MUST get an > updated version number. This is not an issue with the repository itself. > They don’t actually care and can deal with duplicate version numbers. The > problem is that the clients will not see them as being an update. > Here it could help if the package revision is counted as the part of the version, then you only need to bump the package revision. Debian does this all the time e.g. if a program is re-built with different compiler options etc. > Version numbers is also a minor issue for the CI/CD on GitLab. While > updates can be merged and committed without changing the version number, > the CI/CD will see that the version has not “changed” and not create a new > “release”. This is not a problem for the RBE3 (or RBE4). They do not > download those package release files. The RBE checks out the project and > builds its own package based on the branch being used for the OS build. The > RBE could not care less about actual version numbers. > > Too say management of this stuff is short-staffed is a huge > understatement. Therefore some things are going to fall behind from simple > prioritization. As I have mentioned several times in the past, I have only > so much time I can devote to FreeDOS. Unfortunately, that will be even less > in the future. The situation would be quite dire if I had not automated > most of the package management and release building processes. > Thanks for explaining it all; it makes a lot more sense now! I really appreciate that you alone are tackling this and indeed more of us should help. Unfortunately my time is also limited and as this is a pure hobby for meI have to choose where I put my energy. And I selfishly choose DOG because it's what's fun for me. > And the list has nothing better to do then having lenghty arguments about > UPX licensing... > > > Agreed. > > While it is important to try and clear up any licensing confusion, there > are other things that we can do that are beneficial to FreeDOS. > Agreed Anything that helps save me time doing all this stuff is a big plus. For > example, when there is an update to a program, update the package at GitLab > and issue a merge request. > While many are easy to update, others are not. They all take time. > Cool, I was unsure if you wanted a PR. Will do for DOG at least :) Time that could be freed up for me to do other things. Like update the > repository packages, work on RBE4, improve my own FreeDOS programs like > FDIMPLES, run down some odd edge case issues, etc. There are number of > really cool projects which I have started that end up being pushed onto a > shelf for later because of the lack of time. V8Turbo, Blinky’s Adventure > and the FD-NLS Desktop app are to just name a couple. Hmm would a package builder's guide be a helpful thing to have? Is there already some documentation for that? > > There are many ways the community can contribute to make everything > better. FreeDOS is an open source community project. > 100% Maybe if we write a package build guide we could have more help, I feel packaging is something non-developers could definitely help with. --Wolf -- |\_ | .\---. / ,__/ / /Wolf <wolf+...@bergenheim.net>_
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
