dev-qt/qt-docs-5.12.4: Add split docs handling #12575
Conversation
a17r
added
the
do not merge
eclass/qt5-build.eclass
Outdated
| # @DESCRIPTION: | ||
| # Timestamp of split Qt5 documentation tarballs, part of tarball naming. | ||
|
|
||
| # @ECLASS-VARIABLE: QT5_DOCURI |
There was a problem hiding this comment.
I'm not sure about the use case for this variable, will it ever need to be customized by the ebuild? OTOH, it doesn't hurt either...
There was a problem hiding this comment.
While this part of the PR does not exist anymore, this QT5_DOCURI variable would have actually been required to incorporate the files for charts, datavis, networkauth, script, virtualkeyboard and webengine that all exist in separate subdirs from the main documentation.
eclass/qt5-build.eclass
Outdated
| # IMPORTANT: Don't forget to update on version bumps! | ||
| # Key:Value pairs of known Qt5 documentation tarballs where key=<version> and | ||
| # value=<upstream timestamp>, sorted by <version>, descending. | ||
| QT5_DOCSMAP=( |
There was a problem hiding this comment.
you can probably use an associative array
declare -A QT5_DOCSMAP=(
[version]=timestamp
...
)
(can also be declared readonly after init)
Also, isn't this an internal variable? why documenting it as @ECLASS-VARIABLE? I think a normal comment should be enough.
There was a problem hiding this comment.
The problem with the associative array is ordering; so we 'break' live ebuilds because they won't use 'latest available per branch' anymore but whatever hash turns out first.
There was a problem hiding this comment.
uhm, I wasn't thinking about live ebuilds at all... it sounds like they could be a headache either way... even in your implementation, whenever you add a new entry to this array (e.g. on a version bump), do you have to remanifest all live ebuilds? I'm not sure I like this.
There was a problem hiding this comment.
With an associative array, we could have separate entries for each 5.x.9999 branch, and bump them separately if desired. This would lead to less coupling.
There was a problem hiding this comment.
True, re-manifesting the live ebuilds on version bumps would be the consequence I did not think about myself yet. On the plus side, version bumps don't happen that often. I don't think there is another way to supply live ebuild users with the docs though?
Other solutions? We could split them out and mirror each Qt package in app-doc/*, that creates yet another haskell/acct-user/acct-group/virtual situation and we would need to hope for https://bugs.gentoo.org/691798 to be fixed soon. Alternatively, add a dev-qt/*-docs companion per package.
Or we just keep the one true dev-qt/qt-docs ebuild and just add USE flags for all our Qt packages. That presents the least expensive upkeep.
Both alternative solutions would have the benefit of not having to rebuild 'real' Qt code when switching on USE doc.
With an associative array, we could have separate entries for each 5.x.9999 branch, and bump them separately if desired. This would lead to less coupling.
Yes, but on the other hand, would we ever not bump those when we have a new Qt version bump? It would even be the same manifest run when done in Qt overlay. Fatal, of course, if missed.
There was a problem hiding this comment.
The more I think of it, the more I just want to keep it all in qt-docs.
Radical departure incoming. (previous state of PR still remains in qt overlay).
There was a problem hiding this comment.
Yes, but on the other hand, would we ever not bump those when we have a new Qt version bump? It would even be the same manifest run when done in Qt overlay. Fatal, of course, if missed.
Probably. But the point is that we wouldn't have to, e.g. we could bump those only at each new minor Qt version, not at each patch-level version bump. I'm not saying we have to do that, it just gives us the option to do it. Less coupling is good.
a17r
force-pushed
the
split-docs
branch
3 times, most recently
from
85bfbe8
to
fa65e9c
Compare
a17r
changed the title
a17r
force-pushed
the
split-docs
branch
2 times, most recently
from
9e6cd72
to
6b37e5c
Compare
Pull request CI reportReport generated at: 2019-08-18 22:00 UTC All QA issues have been fixed! |
|
I'd like to add this soon as it is a continuation of qt-docs-5.12.3 with USE modularity, it won't stop us from a more sophisticated future approach. |
|
Adding USE flags to |
Closes: https://bugs.gentoo.org/689754 Package-Manager: Portage-2.3.71, Repoman-2.3.17 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
Submitting early so you can see what I am currently working with.
Does not involve changing ebuilds at all like that.