spotify / dh-virtualenv

Python virtualenvs in Debian packages

Home Page:http://dh-virtualenv.readthedocs.io/en/latest/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Official xenial release

ethanaward opened this issue · comments

Is there an official xenial package for version 1.0 in the works? It would appreciated so that xenial packages using this can be effectively built on Launchpad.

I can put one up on BinTray, if that helps.

I'll look into building the package that in the PPA.

Too bad 1.0 didn't make it to Xenial

It's in jessie-backports at least. Maybe nudge the Ubuntu crowd to do the same… 🤛

It seems the 1.x package made it into zesty: http://packages.ubuntu.com/zesty/dh-virtualenv

One nice thing is the all architecture so the deb tends to install and work nicely on other codenames of ubuntu.

We're using the following to install it in some of our open source projects (internally we have our own apt server and a different solution): https://github.com/Yelp/paasta/blob/ca98932f81be0d6c94b2f5509c004822e9dae69d/yelp_package/dockerfiles/xenial/Dockerfile#L41-L44

Available options should be mentioned in the README.

Handled with 2aca30a

Just checking in, is there any reason this is pushed upstream exclusively to the Ubuntu Zesty repo and not Ubuntu All/Xenial (an actual LTS release)?

@Kyrluckechuck debian / ubuntu upstreams typically freeze packages when the LTS is released and reserve updates for bug / security fixes only. It is typical that a new release will only make it into official repositories for a new OS release occurs -- fortunately in this case it's easy to just install the newer release as above.

Pulling packages from zesty into xenial is an accident waiting to happen. You would typically add the zesty repo to the sources list, and the newer versions of all the packages in the newer distro would result in a lot of issues that will most likely leave your box unbootable at some point. If you absolutely HAVE to do hacks like this, it should be added to the repo for the oldest supported platform, not the newest. This way, the older platform shifts will not be pulled in unless forced.

Pulling an arch=all package for a tool (i.e. no other consuming packages) is perfectly safe.