Skip to content

make syncplay packageable#30

Merged
daniel-123 merged 1 commit intoSyncplay:masterfrom
blaenk:packageable
Dec 28, 2013
Merged

make syncplay packageable#30
daniel-123 merged 1 commit intoSyncplay:masterfrom
blaenk:packageable

Conversation

@blaenk
Copy link
Contributor

@blaenk blaenk commented Dec 18, 2013

This is just an idea I guess, but I tested it and it works both with regular sudo make install as well as the package that I created. Fixes #28

There's now a marker in the client and server that is just # libpath which gets substituted in the makefile with sed to site.addsitedir with the path to the syncplay module files, effectively adding the syncplay module files in whatever/lib to the files that python searches for during an import.

So yeah, I tested it and it works fine on its own (i.e. regular sudo make install). All I do on my own end with the arch package is yet again run sed to replace python with python2 in the client and the server. This is expected/common in arch packages for python programs.

I tried to change as little as possible. I had to add ${PREFIX} to each of the path variables because the arch package needs some way to specify the prefix at which to install the stuff. This is otherwise empty (if the user doesn't specify it) so it should be of no consequence to anyone else.

A last minor note is that I do the replacement with sed after the file has been copied to its installation, to preserve a pristine copy in the source directory.

EDIT: Forgot to mention that I also mkdir -p some directories that hadn't been before. I suppose they weren't mkdir -p'd before because these directories are normally present, but the packaging system on arch does the installation within a chroot environment, where these directories don't exist, so the mkdir -p is necessary and of course of no consequence to anyone else if they already do exist.

daniel-123 added a commit that referenced this pull request Dec 28, 2013
@daniel-123 daniel-123 merged commit 801ae8d into Syncplay:master Dec 28, 2013
@blaenk
Copy link
Contributor Author

blaenk commented Dec 29, 2013

Cool thanks.

Is there a roadmap or even vague ETA on when the next version of SyncPlay will land with this fix? Even if it's just another RC. The reason I ask is because packages for my system make a distinction between git-sourced and version-releases, and I was intending to package the version release primarily, since I'm not sure how you guys treat the master branch (i.e. if it's much less stable, prone to breaking, etc.).

@Et0h
Copy link
Contributor

Et0h commented Dec 29, 2013

We try to keep the master branch relatively stable. There are a few bugs which I expect we'll want to fix before releasing the next RC - how long it'll take depends on how much time people have. Could you just package your own fork?

@blaenk
Copy link
Contributor Author

blaenk commented Dec 30, 2013

It's hardly a pressing matter enough to package my fork; I was merely curious, not pressuring.

I think what I'll do for now is package a git-sourced version (which like I said is normal in this system) and when the next RC is released I'll create a package for that as well.

@blaenk
Copy link
Contributor Author

blaenk commented Jan 11, 2014

So far I have created an archlinux package sourced from git, syncplay-git, meaning it'll always get the latest source and build from that. Once the next version is released that incorporates these changes, I'll create a release-version of the package, so that ultimately there will be two: syncplay and syncplay-git.

@blaenk
Copy link
Contributor Author

blaenk commented Feb 22, 2014

Now that RC4 was released I've published a package for syncplay (i.e. non-git sourced).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

python version disambiguation

3 participants