deb/rpm packages

[alanfranz]

Hello,
I've used su-exec and I like it since it's smaller than gosu, but most distributions don't package it (yet).

I could setup a build system for deb and rpm packages, so that those could be uploaded on github directly and pulled from there via curl/wget.

Would you be interested in such a contribution?

[ncopa]

Hi,

Thank you for this. I think I would be more interested in getting the deb into debian repository and the rpm into fedora.

I suppose a build system with recipies for dep and rpm would be a step in that direction.

[alanfranz]

I understand, but I won't help with that, I'm sorry. Upstream packaging
guidelines have killed more than one developer :-)

I'll contribute a packaging system (which surely won't be ok for upstream
merging), then you can choose what you'd like to do.

On Mon, Apr 18, 2016 at 2:46 PM, Natanael Copa notifications@github.com
wrote:

Hi,

Thank you for this. I think I would be more interested in getting the deb
into debian repository and the rpm into fedora.

I suppose a build system with recipies for dep and rpm would be a step in
that direction.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#3 (comment)

[neg3ntropy]

Is there a static binary somewhere in the meantime?

[alanfranz]

@soulrebel which distro do you need? I did the packaging example for Ubuntu Trusty, I haven't created a PR back yet, but I can add others in the meantime (actually there's one test that fails and I don't know why).

[alanfranz]

PR #4 was opened.

[blaggacao]

I also would prefer a statically linked binary: it has a nice use case for embedded systems, where basically nothing is present. I'm working with buildroot for some containers.

[neg3ntropy]

@alanfranz Packaging is nice when it's done upstream and you can just apt-get (or whatever) stuff. The next best thing, especially for dockers is a wget oneliner that works on all distros.

[alanfranz]

@soulrebel one thing does not imply nor exclude the other.

I'd say: feel free to contribute a pull request that statically compiles the binary, without hijacking a totally different PR for which I invested some of my personal time, even though you don't need such approach.

By the way, I host a lot of repositories of self-built software that works fine with apt-get. Pushing things upstream in distributions is very useful, but usually it's an extremely slow and painful process.

Example
https://github.com/alanfranz/apt-current

You'll find both repositories and .deb files under "Releases". I find it very useful in docker contexts.

[javabean]

For your convenience, I have compiled binaries for amd64 (base OS: Ubuntu 16.04), i386 (base OS: Debian 8) and armhf (Raspbian 8) at https://github.com/javabean/su-exec/releases
Usage: curl -fsSLR -o /usr/local/bin/su-exec https://github.com/javabean/su-exec/releases/download/v0.2/su-exec.$(dpkg --print-architecture | awk -F- '{ print $NF }')
You should of course never trust me and compile your own binaries! :-)

[alanfranz]

@javabean surely I won't trust you, don't worry:

$ file ./su-exec.amd64 
./su-exec.amd64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=d9d132c8452b2f7b86c7bfe88f11e1824096f321, not stripped

this issue is for DEB/RPM packaging. Somebody asked for statically linked binaries. You provided dynamically linked binaries! What for?