Packaging for multiple Linux distros#296
Conversation
There was a problem hiding this comment.
I'm having a hard time understanding the workflow you intended for this PKGBUILD. As I picture the use of this script, you'd have to get a source tarball somehow, stick it in the same directory as this PKGBUILD, then run this. The PKGBUILD usually gets the source tarball for you though. Plus, I reckon that an arch package should be put in AUR rather than the upstream package (and it already is in AUR with the cleanly-written pybitmessage-git package)... to me one of the main points of arch is to avoid polluting upstream codebases with special packaging.
There was a problem hiding this comment.
The source tarball is generated with arch.sh, and gets put into the archpackage subdirectory of the project. When building with OBS just upload that, plus the PKGBUILD. See https://build.opensuse.org/package/show/home:motters:pybitmessage/pybitmessage-0.3.4
It would be entirely possible to pull the latest code from github, but I assume that if you're distributing source code then it's not a good idea to have it dependent upon a particular hosting service.
There was a problem hiding this comment.
Ah, ok, I see what your doing. Fair enough. Dependencies look good now. Strictly speaking, gevent is an optional dependency but it's small so I suppose it's fine to make it mandatory. I'm still not totally convinced arch users would tend to use this, but I'm hardly opposed to giving people options! Thanks.
There was a problem hiding this comment.
python2-gevent is now optional. All the packaging files and scripts are generated by a single script called generate.sh, so it's fairly easy to change things without a lot of manual editing.
There was a problem hiding this comment.
Ah, I forgot...I don't see anywhere this is doing the s|#!/usr/bin/python|#!/usr/bin/python2| fix. Am I just ignoring something obvious here too?
There was a problem hiding this comment.
I assume that Arch conforms to the free desktop specification (http://www.freedesktop.org) and so the desktop icons should appear normally.
There was a problem hiding this comment.
Is it essential that python2 be used? Does PyBitmessage not run with version 3?
There was a problem hiding this comment.
PyBitmessage has its fair share of python3 incompatible stuff. Old-style
print statements (which are slowly being migrated to logging anyway),
ConfigParser, builtins, Queue, repr, thread, xrange, old-format
exception handling, and probably something that I have missed. It shouldn't
be that much work to make it compatible after the print statements are
converted to logging messages.
There was a problem hiding this comment.
It looks like there's only one instance of #!/usr/bin/python, and that's within src/pyelliptic/README.md. The version of Python within /usr/bin/pybitmessage can be changed though.
There was a problem hiding this comment.
Funny, I didn't look where these substitutions were occurring... I only saw that they existed. src/bitmessagemain.py is already pointing to /usr/bin/env python2.7, so that's fine. The other instances of "/usr/bin/env python" should be deleted anyway, since they are never to be executed. /usr/bin/pybitmessage indeed needs to be fixed to be python2. Otherwise the package looks like it should do.
There was a problem hiding this comment.
At first this comment recommended using dirname to enforce the directory in which the script operates, but on second thought I don't see any major reason to do that. This is fine, but maybe it's worth adding a usage comment that includes the stipulation of where the cwd needs to be upon invocation.
|
I tried to manually merge this but I'm not sure what is correct. In the Makefile, one side of the conflict makes heavy use of {DESTDIR} and the other makes heavy use of {DEST_APP} and {DEST_SHARE}. |
|
I think it's safe to overwrite the older Makefile with the newer one. An advantage is that the Makefile and the other packaging scripts and files are all generated via generate.sh, which means a lot less maintenance effort. |
|
Excellent. Thank you. |
2 participants
Supported formats: deb, RPM, Arch, ebuild, PET, TXZ
The RPM dependency uses the Bitcoin SSL library. Pre-built packages are available at:
http://download.opensuse.org/repositories/home:/motters:/pybitmessage/