Package Details: hydrus 273-1

Git Clone URL: https://aur.archlinux.org/hydrus.git (read-only)
Package Base: hydrus
Description: Danbooru-like image tagging and searching system for the desktop
Upstream URL: http://hydrusnetwork.github.io/hydrus/
Licenses: WTFPL
Conflicts: hydrus-docs, hydrus-sources
Submitter: Score_Under
Maintainer: Score_Under
Last Packager: Score_Under
Votes: 11
Popularity: 0.106009
First Submitted: 2015-02-28 18:11
Last Updated: 2017-09-14 17:22

Latest Comments

Score_Under commented on 2017-07-30 15:44

The python-lz4 manual update shouldn't be necessary any more - I've succeeded in taking ownership of the package and updated it to the latest version.

irlittz commented on 2017-07-30 14:31

@Score_Under thank you for updating! For anyone else wanting to install this now: you'll have to manually update the PKGBUILD for python2-lz4 and install it yourself. This is what I did https://gist.github.com/anonymous/ad3eeb8577ed41f704a11497304baf9f. Feel free to use, if you think it is adequate.

EDIT: Nevermind, apparently Score_Under has ownership of that package now, and it is updated. Thank you again.

irlittz commented on 2017-07-29 18:18

@Score_Under did you abandon this package? I'm asking because it would have been easily possible to create a temporary AUR package that provides/replaces python2-lz4 instead of waiting for more than a month for a change that is not coming. When you hopefully get around to doing this, adding hdf5 as a dependency will be needed.

quantumphaze commented on 2017-07-24 12:35

Any news on python2-lz4?

If aurifier is MIA then it should have been orphaned by a TU by now. It's been nearly a month since you filed the request.

Score_Under commented on 2017-06-30 07:47

Currently waiting for python2-lz4's arch package to update before we can update this package any further. I'm going to see if I can claim it.

BrainDamage commented on 2017-01-25 12:19

python2-socks dependency should be replaced with arch's official package of python2-pysocks, it provides the same software

Score_Under commented on 2016-12-16 02:28

Guys, please stop flagging the release out of date less than a day after the release. I am well aware of the release schedule and am subscribed to the github release notifications.

Aelius commented on 2016-10-23 04:35

I had no idea the upstream package was so convoluted. You're certainly doing good work, and I appreciate that you have been maintaining the paths-in-opt.patch to provide a sane install.

The bug in yaourt created a mild inconvenience which will now be avoided- it won't behave 'exactly the same', if that is any consolation.

I'm not familiar with python but I am aware of python bytecode. The packages I deal with always install source, and setup.py stores the bytecode in __pycache__ folders alongside the source. I believe this is standard operating procedure; I may not be able to tell you why it should be done this way, but I don't see a reason to defy convention either.

Thanks, though!

Score_Under commented on 2016-10-23 02:12

This has a source package because it is written entirely in Python, which is in theory a source-only language. In practice, libraries and programs in python should be (and are) compiled down to .pyc/.pyo files to reduce startup time. That process leaves the source code irrelevant, other than for error reporting. Python has no way of including debug info other than as source code, and it's customary to provide source anyway, so I don't think there's any question that the source code should be provided by this PKGBUILD. The only question is whether to split them into different packages or not.

As for the docs, I don't quite remember why I first had them in a separate package. It was probably just that the documentation wasn't all in the right directory at the time.

Given that the DOC_DIRS method of filtering docs out from the package seems to be working correctly, and that the other Python packages in the arch repos serve as a precedent for packaging python modules with their sources, I've decided to roll all three packages into one.

However, even though it's a little more in line with how other things are packaged now, I can't see what the practical outcome of this change is. Yaourt users are going to experience exactly the same, being unable to choose which packages to install (because there is now only one package), and users of other AUR helpers must now install everything.

While I am usually a fan of packages which are split in such a way as to give you "everything you need" in one package and extras in others, in this case people can just build the AUR package with modifications if they want to.

Regarding its distribution as one package from upstream, I don't want to follow the author's example there because I don't trust their packaging skills. There is a 125MB package provided on GitHub with an installed size of 282MB(!!), which includes everything from the requisite python libraries right down to libx11, gtk, and readline. It includes ffmpeg, swfrender, and upnpc as binaries. Even the Windows binaries are included. As a result of how it packages the source, it ties itself to an architecture right off the bat, which no pure-Python code should need to do. It makes stack traces useless due to how the executables are built, despite containing a complete copy of the source code. Even ignoring the package itself, the upstream source doesn't provide an equivalent to setup.py, which is a fundamental of python software packaging.
Given that the package does not even make the distinction between what is part of Hydrus and what is part of the operating system, I will not use that package as an example for how to appropriately divide the Hydrus AUR package. In fact, the problems with the official package are what initially motivated me to begin the Hydrus AUR package.

tl;dr: done, but why (practically speaking)?

Aelius commented on 2016-10-22 19:23

Makes sense that it's a yaourt bug. I've never encountered it before (which I think says something about how common it is to do this), and I'm not sure what benefit this structure of sources/docs/main brings us.

Docs are never separated from the package they describe, so the existence of this as a discrete package confuses me.

Hydrus' source is upstream, if you want access to the source, 'makepkg --noprepare --nobuild' (or any of the other many ways) suffice. Having an entire package for the source confuses me, and I can't say I've ever seen a source package.

Finally, hydrus is distrubted as one package from upstream. What benefit do we gain from dividing this release into three- and does this benefit warrant bucking the more common established ways to get at the docs and source?

All comments