Package Details: hydrus 601-1

Git Clone URL: https://aur.archlinux.org/hydrus.git (read-only, click to copy)
Package Base: hydrus
Description: Danbooru-like image tagging and searching system for the desktop
Upstream URL: http://hydrusnetwork.github.io/hydrus/
Licenses: custom
Conflicts: hydrus-docs-dummy
Submitter: Score_Under
Maintainer: Score_Under
Last Packager: Score_Under
Votes: 40
Popularity: 0.87
First Submitted: 2015-02-28 18:11 (UTC)
Last Updated: 2024-12-04 21:42 (UTC)

Dependencies (40)

Required by (2)

Sources (5)

Latest Comments

« First ‹ Previous 1 .. 7 8 9 10 11 12 13 Next › Last »

Score_Under commented on 2017-06-30 07:47 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC) (edited on 2016-10-23 02:21 (UTC) by Score_Under)

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 (UTC) (edited on 2016-10-22 19:24 (UTC) by aelius)

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?

Score_Under commented on 2016-10-21 22:41 (UTC)

@Aelius I think splitting the package out into three would be the wrong behaviour, since the docs and sources basically come for free in the git repo. Packaging them while packaging the base hydrus package is the simplest way to go about it. I don't think separating into separate PKGBUILDs is any more proper. If you have the ABS checked out, take a look: $ grep -r package_ /var/abs It's a very common idiom in official PKGBUILDs to package related software alongside each other if that makes it quicker and simpler to package things. Yaourt queueing all three for install is a bug in yaourt, rather than this PKGBUILD. Since makepkg supports building multiple packages from one PKGBUILD, the failure to correctly wrap that feature is entirely on Yaourt. There are other AUR tools like pacaur which can correctly install one package at a time. Regarding rolling it all into one package, I don't see much difference between that behaviour and Yaourt's current behaviour. Either way, yaourt will install everything provided by the PKGBUILD. Other AUR helpers will do the right thing, but rolling it all into one package would be throwing out a useful feature (and what I feel are self-evident packaging standards) just to work around the behaviour of broken AUR tools. So for those reasons I'd rather not split this PKGBUILD out or merge all three packages.

aelius commented on 2016-10-21 03:04 (UTC)

The structure of this PKGBUILD causes yaourt to get confused. yaourt sees hydrus, hydrus-sources, and hydrus-docs all as individual packages to be installed; these are all queued for install. The 'hydrus' package alone installs all of them, but since the other two are already queued, yaourt will go through the motion of installing sources and docs anyway. I think you should either just include docs/sources under this package, or properly separate those packages into their own PKGBUILDs.

Score_Under commented on 2016-10-06 02:40 (UTC)

As far as I can tell Hydrus doesn't use Twisted's TLS client. It starts up fine without that package, so maybe it could go in optional dependencies, but since I don't see it being used anywhere in the code I think I can get away with leaving it out of the dependency list.

cryzed commented on 2016-10-05 21:16 (UTC) (edited on 2016-10-05 21:16 (UTC) by cryzed)

You should add extra/python2-service-identity to dependencies as otherwise hydrus-client complains about it when started: > :0: UserWarning: You do not have a working installation of the service_identity module: 'No module named service_identity'. Please install it from <https://pypi.python.org/pypi/service_identity> and make sure all of its dependencies are satisfied. Without the service_identity module and a recent enough pyOpenSSL to support it, Twisted can perform only rudimentary TLS client hostname verification. Many valid certificate/hostname mappings may be rejected.

« First ‹ Previous 1 .. 7 8 9 10 11 12 13 Next › Last »