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

[austin987]

No description provided.

[SolidHal]

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]

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.

[SolidHal]

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]

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]

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]

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).

[SolidHal]

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]

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.