On Sun, 02 Jun 2024, Florian Schmaus wrote:
Note that this changes readme.gentoo-r1.eclass to export phase
functions when it previously did not.
On Sun, 02 Jun 2024, Florian Schmaus wrote:
+ (
+ insinto "${_GREADME_DOC_DIR}"
+
+ doins "${_GREADME_TMP_FILE}"
+ cksum --raw "${_GREADME_TMP_FILE}" | newins - "${_GREADME_HASH_FILENAME}"
+ assert
+ )
On Sun, 02 Jun 2024, Florian Schmaus wrote:
IMHO that's a very bad idea and will probably break ebuilds that rely
on the current behaviour.
I pondered about this and its one of the reasons I'd rather start with
a fresh eclass.
That said, worst case scenario I could came up with is that the elog
message is printed twice. And this is also only the case if the ebuild
has readme.gentoo_print_elog *not* in pkg_postinst. However, the readme.gentoo-r1.eclass documentation suggests you to put it in
pkg_postinst.
And if an ebuild has readme.gentoo_print_elog *in* pkg_postinst, which
should be true for nearly all ebuilds currently inheriting
readme.gentoo-r1, then you don't use the newly exported pkg_postinst
function (and the outcome of the exproted pkg_preinst is simply
ignored).
Bottom line is: exporting the functions should do no harm.
On Sun, 02 Jun 2024, Eli Schwartz wrote:
Per the commit message, the old readme and the new readme can have the
same contents, but be compressed by different compressors on the live
system vs the image, and/or a compressor with unstable algorithms,
and/or one that isn't installed at the time of merging.
Given you've explicitly rejected disabling compression, I don't quite
see how you can have your cake and eat it too.
On Sun, 02 Jun 2024, Eli Schwartz wrote:
readme.gentoo-r1.eclass as proposed in this thread is exactly such an upstream program (gentoo is the upstream, and gentoo cannot cope with compressed files there).
It strikes me as rules lawyering to use this as an argument against
the eclass, but whatever. The alternative to `docompress -x` is to
*not have to decompress* when comparing the compressed contents of two
files, which means recording persistent state.
There is one approach that I can think of for this:
- recording state in a second file (additional to README.gentoo itself)
If you dislike this solution, and are unwilling to back down on
"docompress -x", then my personal feeling is that it is *your*
responsibility to come up with an alternative mechanism for
implementing the functionality.
On Tue, 04 Jun 2024, Florian Schmaus wrote:
Both is fine with me.
That said, many filesystem support inline data. If I am not mistaken,
then its even enabled by default for xfs (which we recommend in the
handbook) and btrfs. Also some README.gentoo files become suitable for inlining after compression (btrfs' limit is 2048 bytes).
Considering this, the 4-byte hash file is superior under the right circumstances when compared to excluding README.gentoo from
compression. And I could imagine that the circumstances are right for
many of our users.
On Tue, 04 Jun 2024, Florian Schmaus wrote:
And yes, "docompress -x README.gentoo" would make the code muuuuuuuuch simpler.
In any case, the above size considerations aren't important. My main
point is that the code is getting way too complicated for the simple
task of printing a few lines in pkg_postinst.
On Tue, Jun 04, 2024 at 07:45:39PM +0200, Ulrich Mueller wrote:
In any case, the above size considerations aren't important. My main
point is that the code is getting way too complicated for the simple
task of printing a few lines in pkg_postinst.
Have to say that this is mostly how I feel as well. Not that I followed
this whole conversation in full.
That aside, with all this talk of using the installed README.gentoo,
note that the file may not even be there because of FEATURES="nodoc".
Albeit could just assume it's unchanged in these cases.
Don't know if idea came up in this thread before but, if *really* had
to implement a mechanic to display the README.gentoo again on changes,
think I'd personally add an optional version variable/argument that
could be bumped by the ebuild maintainer whenever the README is
changed. Then if the version it's replacing is older than that it'll
display it again with a notice explaining that it changed. There are
some limitations to this approach but well, e.g.
- won't work without a bump/revbump to compare with
- maintainer might forget to set the version after changes
- version won't mean as much if update the README in all ebuild
versions at once, and can't tell what's actually been seen
(might cause occasional see-it-again when stabilizing)
- can't display a diff if wanted one, not that the hash approach
could do that either
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 475 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 18:55:19 |
| Calls: | 9,487 |
| Calls today: | 6 |
| Files: | 13,617 |
| Messages: | 6,121,093 |