Arch Linux User Repository

The AUR package for JpegXL support is outdated and does not build. If you need JpegXL support, follow the instructions in the comment I posted to update the PKGBUILD.

Seems to be a failure to run with latest updates. 2023-04-13.

Traceback (most recent call last):
  File "/opt/hydrus/hydrus/client/ClientController.py", line 2140, in THREADBootEverything
    self.InitView()
  File "/opt/hydrus/hydrus/client/ClientController.py", line 1296, in InitView
    self.CallBlockingToQt( self._splash, qt_code_gui )
  File "/opt/hydrus/hydrus/client/ClientController.py", line 478, in CallBlockingToQt
    raise e
  File "/opt/hydrus/hydrus/client/ClientController.py", line 417, in qt_code
    result = func( *args, **kwargs )
  File "/opt/hydrus/hydrus/client/ClientController.py", line 1291, in qt_code_gui
    self.gui = ClientGUI.FrameGUI( self )
  File "/opt/hydrus/hydrus/client/gui/ClientGUI.py", line 474, in __init__
    ClientGUITopLevelWindows.MainFrameThatResizes.__init__( self, None, 'main', 'main_gui' )
  File "/opt/hydrus/hydrus/client/gui/ClientGUITopLevelWindows.py", line 670, in __init__
    MainFrame.__init__( self, parent, title )
  File "/opt/hydrus/hydrus/client/gui/ClientGUITopLevelWindows.py", line 610, in __init__
    QW.QMainWindow.__init__( self, parent )
TypeError: object.__init__() takes exactly one argument (the instance to initialize)

It would be nice if I knew what headache people are having from this. I'm certainly getting headaches from discussing this for 7 years with very little elaboration as to exactly what is going wrong! I have received some feedback about some dependencies being poorly maintained, but no elaboration past that as to exactly what maintenance troubles are impacting the end user (especially now that I have taken matters into my own hands when it comes to breaking the python2 dependency in the chain, going as far as to break AUR rules to do so while TUs were backlogged and eventually take over ownership of the packages in question), and I have put an exception in the PKGBUILD to remove the help pages and all dependencies downstream of that if the user chooses not to build docs (which is not a standard practice by any means, and as demonstrated, breaks all context-sensitive help features within hydrus and some of the help menu too, but crucially it solves the exact problem people have been discussing for so long in this thread). Many years ago, this package used to be split into three, building sources, docs and optimised bytecode into separate packages, but there were complaints about that setup too, because people's AUR helpers hit on bugs when they handled it - despite it being widespread and a documented standard - and they don't want to use anything else.

Please, instead of one-sided complaints that propose only a solution without detailing the problem and do not consider the impact of that solution on the majority of the userbase, tell me:

• Concretely, what problems are you currently experiencing through having the make-dependencies of Hydrus documentation installed?
  • Are these problems significantly more impactful than the other cursed problems surrounding this package, such as Qt python bindings not being as transparently interchangeable as QtPy likes to pretend (and thus the occasional switching of default qt bindings, or forcing of specific backends to be installed despite how that might change the behaviour for other software and override the sysadmin's wishes), or QtPy's version not being updated fast enough by the Arch packagers to keep up with Hydrus' growing requirements, or the whole python2-to-python3 move in general? If they are not, it doesn't seem reasonable to point a finger there and say that this is what's making the package difficult to use.
• The current iteration of the package contains a workaround which will avoid pulling in documentation dependencies if you choose not to build documentation. This does exactly what was asked, and I have received precisely zero feedback on it. Why is this not an acceptable solution?
• The official package provided by upstream contains many of the dependencies already pre-packaged and the documentation already pre-baked. If you are looking to minimise pacman dependencies, why are you using the AUR version rather than the upstream build?

I want to avoid making this a half-assed semi-broken out-of-the-box experience for the average user, and breaking all context-sensitive help and half the help menu itself is at best going to give people a bad experience (especially newer users, as many of the more advanced tools have a steep learning curve), or at worst going to end up with a bunch of spurious bug reports against the Hydrus project itself about these features being broken.

If I were to split this package into two completely separate pkgbases, which I assume is what is being asked, then nobody would install the separate docs package even if they needed it. It wouldn't have the same presence when someone's just looking to "install Hydrus from the AUR". To the outside observer who hasn't been part of this discourse, it is just yet another feature that the AUR version botches for no good reason. Additionally, keeping them both up-to-date at the same time, in lockstep with each other's version, would both be more effort in terms of package maintenance (as I now have twice the packages to maintain per Hydrus update), and more effort in terms of system administration for the end user (as they will need to manage version conflicts and install them in the correct order).

At the risk of repeating myself, I don't want to break features just to satisfy a vaguely articulated gripe people have and which people have flatly refused to elaborate on when questioned. If I'm going to break the software for all users, I want a good reason to do it. I don't want to throw the baby out with the bathwater. I don't think that's asking too much.

Please completely separate the software and the documentation into two packages. This is giving all of us a lot of unnecessary headache.

Can you elaborate on what issues you've had with those packages? If they are causing problems then that should probably be reported to the maintainers of those packages too

It's not about space. It's about having a bunch of poorly managed packages that keep breaking and interfering with other stuff is why I remove them.

Given that there are a couple of people with complaints about installing the python dependencies for the documentation specifically, as much as I would like to say install gentoo (not just as a meme this time, since gentoo's approach is towards fine-grained customisation of this type of thing), I've instead put in a nasty hack in the PKGBUILD to change the build-time dependency list depending on whether docs are included or not. This is by no means a standard thing to do and likely won't play nice with AUR helpers, so you may need to build it with standard tools instead, but if you edit /etc/makepkg.conf and disable docs there, it will avoid pulling those dependencies in.

To clear up a misconception I've seen in the comments here, it does affect a lot of built-in help when you exclude the documentation:

• Changelog is broken
• Easy downloader import help is broken
• Downloader sharing help is broken
• Gallery URL generators help is broken
• Downloader URL classes help is broken
• Login scripts help is broken
• Database migration help is broken
• HTML subscriptions help is broken
• Duplicates processing help is broken
• Page parsers help is broken
• Content parsers help is broken
• HTML, JSON, Compound, and Context Variable formula help are all broken

I don't think this is an acceptable experience for beginner users of hydrus, and it is only reluctantly that I have made a change that beginners might accidentally fall head-first into.

@joehillen I notice that your copy-paste output there has "old version" empty for all those dependencies. Please consider answering "no" when asked if you want to remove make dependencies after installation, as that is the path of least resistance for everyone and costs you about 20MB while avoiding the repeated re-download and rebuild that seems to be the issue you're having.

If 20MB is too far out of your space budget then I question the use of Hydrus, which is very space-hungry by its nature.

I don't need/want any of this crap:

community/python-csscompressor                        0.9.5-5      No
community/python-editables                            0.3-2        No
community/python-ghp-import                           1.1.0-3      No
community/python-hatch-nodejs-version                 0.3.1-1      No
community/python-hatch-requirements-txt               0.3.0-1      No
community/python-hatchling                            1.13.0-1     No
community/python-livereload                           2.6.3-2      No
community/python-pyaml                                21.10.1-1    No
community/python-regex                                2023.3.23-1  No
community/python-tornado                              6.2.0-2      No
community/python-watchdog                             2.3.0-1      No

Aur (14)                                 Old Version  New Version  Make Only
aur/python-mergedeep                                  1.3.4-2      No
aur/python-mdx-gh-links                               0.2-1        No
aur/python-pyyaml-env-tag                             0.1-1        No
aur/mkdocs                                            1.4.2-1      No
aur/python-htmlmin2                                   0.1.13-1     No
aur/python-jsmin                                      3.0.1-1      No
aur/mkdocs-minify-plugin                              0.6.4-1      No
aur/pymdown-extensions                                9.10-1       No
aur/mkdocs-material-extensions                        1.1.1-1      No
aur/mkdocs-material                                   9.1.3-1      No

If I need to read the docs, I'll just go online.

Just please remove the docs stuff from this package. Anyone using the AUR just wants the software. I've never seen another AUR package require the documentation as part of the build, and the mkdocs deps are a broken mess.

If anyone needs to build the docs, they should go build them from source themselves, which should really only be the Hydrus maintainers.

Thank you. I really appreciate having this pkgbuild available. And I prefer having the docs available to not.

This was a split PKGBUILD in 2016 but people didn't seem to like it because it interacted poorly with the AUR helpers they used. (read the comments from the second-last page for context). Since the mkdocs stuff is a makedep it can just be uninstalled after the package is built, or even never installed at all if you have a remote build host doing it for you. The DOC_DIRS variable is set in the PKGBUILD, which should allow for people to strip the docs out of the final package if they set the correct options in their makepkg.conf.

The only leftover parts of this process if you don't want docs are the need to render them in the first place and the need for the mkdocs tool to accomplish that. If you offload the building to a remote machine or chrooted build, then you never even need mkdocs installed on the machine running hydrus in the first place, so the only vestiges you get are the fact that the package files for it were downloaded, and the short couple of seconds extra in the packaging process to build the docs which might get discarded anyway.

I don't think people are asking for a split PKGBUILD. I think they're asking for multiple PKGBUILDs to completely remove the mkdocs step in this one, e.g. to quote HydrusUser "It's very annoying having to remove [mkdocs] every single time there's an update". Though of course doing so would mean that the docs package needs to be released separately, and there would be little guarantee for the users using AUR helpers that their versions are congruent between the doc and main packages. If people do want this split up into two separate pkgbases, I will take some convincing (alternatively I'm happy to appoint more co-maintainers).