Make it easier to port to armhf

sokoow commented 8 years ago

Hi,

Nice tool, but I'm stuck in couple of places when trying to port to armhf. For example, some images pull from debian:sid (vlc for example), and it's not trivial on what to change to fix it for armhf (I'd change it to raspbian). Looking through sources doesn't reveal where that debian:sid is hardcoded. Also, when I change the FROM path in .subuser repo, it doesn't reflect it correctly. Help ?

timthelion commented 8 years ago

EDIT: The docker-image directory is now just the image directory.

debian:sid isn't exactly directly encoded in the source code. What is going on, is that subuser is trying to install the xpra bridge from the "default" repository, and the "default" repository is hard coded as a resource file. You can over-ride the default repository by creating a /etc/subuser/repositories.json file like so:

{"default":{"source-dir":"/home/sokoow/subuser-default-armhf"}}

This will over-ride the default repository: https://github.com/subuser-security/subuser/blob/master/logic/subuserlib/data/repositories.json

Now the "default" repository must contain the following image sources:

You can add those image sources by copying those two directories into /home/sokoow/subuser-default-armhf and then modifying the image/SubuserImagefile to use raspbian.

One thing that I'm a bit concerned about is whether the version of xpra will be new enough in raspbian. The reason why the xpra bridge uses sid, while the rest of the images are based on jessie, is that only rather recent xpra version work properly.

In terms of a larger, long term porting effort, I would love to have an official default repository that worked with armhf. So if you make it, I'll be happy to get behind it. I think that this can be accomplished by somehow telling my setup.py to generate an armhf specific wheel file, that uses a different default 'repositories.json' file. But I have yet to do any multi-arch work with python, so I don't know how exactly that will work out.

I hope this helps, and good luck! Tim

timthelion commented 8 years ago

https://github.com/subuser-security/subuser/issues/253

timthelion commented 8 years ago

Another way of implementing multi-arch support, which I had considered, and which would be easier for users and harder for maintainers, is that subuser-version-constraints could be used. That would mean that there would be an armhf branch in the normal default repository, and the architecture would be included in subuser's version string. This would be easier for users, because they woudn't have to know which architecture they were running when using subuser repository add. But it would be harder for maintainers, because they would have to manage multiple main git branches (though with git 2.5, there is a git worktree command and therefore using multiple working branches should be no harder than using multiple git repos)... But I think I might be jumping the gun a bit here. We still don't know how well subuser on other architectures will work out :D

subuser-security / subuser

Make it easier to port to armhf #274