scripts/BuildScripts/FilesystemScripts/buildFilesystem.sh: add /etc/prawnos-release

austin987 commented

2020-12-01 14:12:04 +01:00

(Migrated from github.com)

No description provided.

SolidEva commented

2020-12-02 02:55:48 +01:00

(Migrated from github.com)

I'm not sure this is completely necessary. My goal is for all of the installed userspace and kernel items that are prawnOS specific to be packaged. I have nearly reached this just today with almost everything available as a package (some items still need work).
Since upgrades will be easy, a v2.1 image could end up with more recent packages and kernel than a v2.6 image

The only time a larger upgrade will be required is jumps between debian releases, and in that case the debian release indicates what the core system is based on.

If you have any use cases for this @austin987 (or anyone else for that matter) that I'm not seeing, please let me know :)

I'm not sure this is completely necessary. My goal is for all of the installed userspace and kernel items that are prawnOS specific to be packaged. I have nearly reached this just today with almost everything available as a package (some items still need work). Since upgrades will be easy, a v2.1 image could end up with more recent packages and kernel than a v2.6 image The only time a larger upgrade will be required is jumps between debian releases, and in that case the debian release indicates what the core system is based on. If you have any use cases for this @austin987 (or anyone else for that matter) that I'm not seeing, please let me know :)

austin987 commented

2020-12-02 06:34:38 +01:00

(Migrated from github.com)

I find it useful when testing multiple images/machines, being able at a quick glance to see what image I originally installed. It's also easier to compare tag/revision info than it is several individual package versions.

Most distros ship some sort of /etc/*-release file, so it fits well with that scheme. IMO it's also a bit of future proofing, while the data may not be useful now, it's a few bytes and could be useful in the future.

But if not, no worries. As I said, mostly helpful if multiple images/versions are in play (a la #248), but I can keep it locally if not desired upstream.

I find it useful when testing multiple images/machines, being able at a quick glance to see what image I originally installed. It's also easier to compare tag/revision info than it is several individual package versions. Most distros ship some sort of /etc/*-release file, so it fits well with that scheme. IMO it's also a bit of future proofing, while the data may not be useful now, it's a few bytes and could be useful in the future. But if not, no worries. As I said, mostly helpful if multiple images/versions are in play (a la #248), but I can keep it locally if not desired upstream.

SolidEva commented

2020-12-03 19:58:31 +01:00

(Migrated from github.com)

I understand the desire to have a version in the filesystem. Not sure if the git describe --tags is the most useful though. When I run it on the master checkout I get v1.2-41-g76f1e12
While that is technically the most recent tag, there are quite a few commits on top of it at that point (41 to be exact)
Finally, since currently the tags are created when I upload a release and not before I build the image for the release, even the distributed images would have the previous tag with some number of commits instead of the correct tag.

Entering the same info from #248 into the prawnos-release file would probably make the most sense, and be the most useful as a benchmark for future comparison. Plus, then there is no need to handle a scenario where that info doesn't exist.

Once PrawnOS has a stronger concept of releases, it might make sense to formally put that info in the prawnos-release file.

I understand the desire to have a version in the filesystem. Not sure if the `git describe --tags` is the most useful though. When I run it on the master checkout I get v1.2-41-g76f1e12 While that is technically the most recent tag, there are quite a few commits on top of it at that point (41 to be exact) Finally, since currently the tags are created when I upload a release and not before I build the image for the release, even the distributed images would have the previous tag with some number of commits instead of the correct tag. Entering the same info from #248 into the `prawnos-release` file would probably make the most sense, and be the most useful as a benchmark for future comparison. Plus, then there is no need to handle a scenario where that info doesn't exist. Once PrawnOS has a stronger concept of releases, it might make sense to formally put that info in the prawnos-release file.

austin987 commented

2020-12-08 18:30:03 +01:00

(Migrated from github.com)

While I agree that the info used to make image and /etc/prawnos-release should match, I'd push for the git describe --tags output.

While you're right that the tag isn't updated until a release, that's fine. As you pointed out, it tells you how far from the last tag is, at a glance (41 commits). Those could be typo fixes or major features, obviously more info is needed, but at a glance it tells you it's not super close to 1.2, which is itself useful info. If you need the exact hash, it's there, 'g76f1e12' means 'git commit 76f1e12'.

When 1.3 was built, it should show 1.3 there. The next build would then be 1.3-1-gxxxxx.

That said, in my super ideal world, the image name and the image itself would have the branch that built it, and the commit/tag info available, and in a consistent format.

That said, I'm happy to work on doing it, we just need to agree on how it should look :). #248/#250 are both independent moves in that info, but as you rightly pointed out, they should be considered/designed together.

While I agree that the info used to make image and /etc/prawnos-release should match, I'd push for the `git describe --tags` output. While you're right that the tag isn't updated until a release, that's fine. As you pointed out, it tells you how far from the last tag is, at a glance (41 commits). Those could be typo fixes or major features, obviously more info is needed, but at a glance it tells you it's not super close to 1.2, which _is itself_ useful info. If you need the exact hash, it's there, 'g76f1e12' means 'git commit 76f1e12'. When 1.3 was built, it should show 1.3 there. The next build would then be 1.3-1-gxxxxx. That said, in my super ideal world, the image name and the image itself would have the branch that built it, and the commit/tag info available, and in a consistent format. That said, I'm happy to work on doing it, we just need to agree on how it should look :). #248/#250 are both independent moves in that info, but as you rightly pointed out, they should be considered/designed together.

austin987 commented

2020-12-08 19:05:08 +01:00

(Migrated from github.com)

For the locally modified problem, we can use the --dirty option of git describe, which will append -dirty if there are uncommitted changes to the tree:

austin@debian-desktop ~/src/PrawnOS (dev-image-unique-testing) $ git describe --dirty --tags
v1.3-3-g7a41c5d-dirty
austin@debian-desktop ~/src/PrawnOS (dev-image-unique-testing) $ git checkout -f
austin@debian-desktop ~/src/PrawnOS (dev-image-unique-testing) $ git describe --dirty --tags
v1.3-3-g7a41c5d

For the locally modified problem, we can use the `--dirty` option of `git describe`, which will append `-dirty` if there are uncommitted changes to the tree: ``` austin@debian-desktop ~/src/PrawnOS (dev-image-unique-testing) $ git describe --dirty --tags v1.3-3-g7a41c5d-dirty austin@debian-desktop ~/src/PrawnOS (dev-image-unique-testing) $ git checkout -f austin@debian-desktop ~/src/PrawnOS (dev-image-unique-testing) $ git describe --dirty --tags v1.3-3-g7a41c5d ```

austin987 commented

2020-12-08 19:17:51 +01:00

(Migrated from github.com)

Looking at it a bit more, two ideas:

maybe it makes sense to generate /etc/prawnos-release from make (i.e., so we can use the same variables used for making the image). Then buildFilesystem.sh can move/copy that file as needed. If we care about the non-git case, then again we can handle that in the makefile.
Maybe it doesn't make sense to include the branch name in /etc/prawnos-release. We could have a second file for build info (for example, /etc/prawnos-buildinfo, or similar), and include, e.g., the git branch, full sha, git commit message/author/date/whatever else may be useful for developers, while keeping /etc/prawnos-release to just the release (i.e., git tag or git describe --tags --dirty).

Looking at it a bit more, two ideas: 1) maybe it makes sense to generate /etc/prawnos-release from make (i.e., so we can use the same variables used for making the image). Then `buildFilesystem.sh` can move/copy that file as needed. If we care about the non-git case, then again we can handle that in the makefile. 2) Maybe it doesn't make sense to include the branch name in /etc/prawnos-release. We could have a second file for build info (for example, /etc/prawnos-buildinfo, or similar), and include, e.g., the git branch, full sha, git commit message/author/date/whatever else may be useful for developers, while keeping /etc/prawnos-release to just the release (i.e., `git tag` or `git describe --tags --dirty`).

SolidEva commented

2020-12-09 01:32:12 +01:00

(Migrated from github.com)

This seems to mostly be a discussion then about what info is most useful where.

We have 2 places we want additional information:

in the name of built images
in the image itself (aka /etc/prawnos-$BLAH), where BLAH is release/buildinfo/etc

and the information that would be useful to have is:

What PrawnOS release version is this image?
What git sha is this image?
Is this image a clean or dirty build of the specified git sha?
what branch was this image built on?

required information

From that, the most "powerful" piece of information is the git sha. It alone can tell you release version and branch.
The next most useful is if it was clean or dirty, a git sha can be misleading if the tree was modified before the build. This isn't a guarantee of course, there are way to accidentally build a "clean" image with dirty pieces.

tagged versions

The version is nice to include as a way to quickly get an idea of when the image is from. Using the output from git describe --tags would mean both v1.2-XX-$sha and v1.3-0-$sha are actually the same. Someone seeing v1.2-XX-$sha when they thought they downloaded v1.3 would just cause needless confusion.
A possible fix for this:

make release could take a PVER environment variable and use that to tag the current sha as that version
the base image is then forced to rebuild, which triggers the logic to add a new updated /etc/prawnos-$BLAH with the tag it just added
the release image then gets named properly using that tag

branch name

This is easy enough to add to the generated image filename, but adding it to the /etc/prawnos-$BLAH introduces some complications similar to including the tagged version. In addition, if you hop around branches often during development there are a few easy situations where /etc/prawnos-$BLAH ends up with completely incorrect branch information that would be the opposite of helpful when debugging.

Conclusion

Really, I want any information included in either the image name or in /etc/prawnos-$BLAH to be as accurate as possible about the state of the image. Inaccurate information will lead to just relying on the git sha instead, or the versions of included packages, and that just leaves more hassle for developers. As the main dev that is something I worry a bit about :D

This seems to mostly be a discussion then about what info is most useful where. We have 2 places we want additional information: 1) in the name of built images 2) in the image itself (aka /etc/prawnos-$BLAH), where BLAH is release/buildinfo/etc and the information that would be useful to have is: 1) What PrawnOS release version is this image? 2) What git sha is this image? 3) Is this image a clean or dirty build of the specified git sha? 4) what branch was this image built on? ### required information From that, the most "powerful" piece of information is the git sha. It alone can tell you release version and branch. The next most useful is if it was clean or dirty, a git sha can be misleading if the tree was modified before the build. This isn't a guarantee of course, there are way to accidentally build a "clean" image with dirty pieces. ### tagged versions The version is nice to include as a way to quickly get an idea of when the image is from. Using the output from `git describe --tags` would mean both `v1.2-XX-$sha` and `v1.3-0-$sha` are actually the same. Someone seeing `v1.2-XX-$sha` when they thought they downloaded `v1.3` would just cause needless confusion. A possible fix for this: - `make release` could take a `PVER` environment variable and use that to tag the current sha as that version - the base image is then forced to rebuild, which triggers the logic to add a new updated `/etc/prawnos-$BLAH` with the tag it just added - the release image then gets named properly using that tag ### branch name This is easy enough to add to the generated image filename, but adding it to the `/etc/prawnos-$BLAH` introduces some complications similar to including the tagged version. In addition, if you hop around branches often during development there are a few easy situations where `/etc/prawnos-$BLAH` ends up with completely incorrect branch information that would be the opposite of helpful when debugging. ## Conclusion Really, I want any information included in either the image name or in `/etc/prawnos-$BLAH` to be as accurate as possible about the state of the image. Inaccurate information will lead to just relying on the git sha instead, or the versions of included packages, and that just leaves more hassle for developers. As the main dev that is something I worry a bit about :D

espoelstra commented

2020-12-16 04:25:47 +01:00

(Migrated from github.com)

I think the Linux standard used by most distributions is trending towards /etc/os-release, with some also using /etc/lsb_release and/or /etc/issue though I believe Debian also has /etc/debian_release just to be special.

This pull request has changes conflicting with the target branch.

scripts/BuildScripts/FilesystemScripts/buildFilesystem.sh

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin austin987/releasefile:austin987/releasefile

git switch austin987/releasefile

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch master

git merge --no-ff austin987/releasefile

git switch austin987/releasefile

git rebase master

git switch master

git merge --ff-only austin987/releasefile

git switch austin987/releasefile

git rebase master

git switch master

git merge --no-ff austin987/releasefile

git switch master

git merge --squash austin987/releasefile

git switch master

git merge --ff-only austin987/releasefile

git switch master

git merge austin987/releasefile

git push origin master

Rows
Columns

scripts/BuildScripts/FilesystemScripts/buildFilesystem.sh: add /etc/prawnos-release #250

required information

tagged versions

branch name

Conclusion

Checkout

Merge