Retaining old package versions in the Ubuntu PPA?

[Daniel Bryan]

Hey everyone,

We were excited about the v0.17.0 release, but we've been burned pretty badly by this bug:

https://groups.google.com/forum/#!topic/salt-users/OAC8vK5Qpas

Not having properly coloured output for broken states makes a deployment a whole lot harder.

Obviously small issues like this will always exist in a "dot-O" release; I'm wondering whether there's been any talk of keeping old package versions available in the PPA repository?

It's generally good practise with any large project to avoid the dot-O for a mission critical system; even with very large and stable projects like Postgres there's good reason for it.

I'm not terribly familiar with how LaunchPad works, but is this something the Salt project would be able to do, without having to resort to different package names like "salt-minion-v0.16.4"? I've seen at least a few examples in my Debian days of pinning to a package version like so:

sudo apt-get install apache2=2.2.20-1ubuntu1

I'm happy to volunteer any help or resources the community would need to make this possible. I think as projects become large, mature and widely deployed, this is very much needed, and it'd be a pity to have to sacrifice the flexibility and speed of the PPA releases by maintaining our own package repository.

Cheers.

[Sebastien Douche]

On Fri, Oct 11, 2013 at 12:13 AM, Daniel Bryan <danb...@gmail.com> wrote:
> Obviously small issues like this will always exist in a "dot-O" release; I'm
> wondering whether there's been any talk of keeping old package versions
> available in the PPA repository?

Hi,
use pinning:
https://help.ubuntu.com/community/PinningHowto


--
Sebastien Douche <sdo...@gmail.com>
Twitter: @sdouche / G+: +sdouche

[Daniel Bryan]

> On Monday, October 14, 2013 8:21:20 PM UTC+11, Sebastien Douche wrote:

> On Fri, Oct 11, 2013 at 12:13 AM, Daniel Bryan <danb...@gmail.com> wrote:

>> Obviously small issues like this will always exist in a "dot-O" release; I'm

>> wondering whether there's been any talk of keeping old package versions

>> available in the PPA repository?

>

> Hi,

>use pinning:

>https://help.ubuntu.com/community/PinningHowto

Pinning only works if the old version is still in the package repo.

    $ sudo apt-cache madison salt-minion

    salt-minion | 0.17.4-1quantal | http://ppa.launchpad.net/saltstack/salt/ubuntu/ quantal/main amd64 Packages

    salt-minion |   0.10.1-3 | http://au.archive.ubuntu.com/ubuntu/ quantal/universe amd64 Packages

          salt |   0.10.1-3 | http://au.archive.ubuntu.com/ubuntu/ quantal/universe Sources

          salt | 0.17.4-1quantal | http://ppa.launchpad.net/saltstack/salt/ubuntu/ quantal/main Sources

Quite a few times now, we've seen "patch releases" break code (i.e. states)

that was working robustly[1].

Whether or not our existing broken, the semantics of a patch release don't seem

to apply lately.

The release notes [2] for 0.17.4 are length and it's not clear how to determine

which parts have an impact on changing working behaviour.

I'm consistently impressed by how quickly Salt development progresses, and how

stable the releases are in general, but these breaking patch releases are

becoming a real pain. We've been tempted to set up our own apt mirror so that

we can control the uptake of a new release, but we'd prefer to avoid this.

Has there been any further thought into keeping previous releases in the

package repo? If there are technical obstacles to this, what would it take to

get it done?

Thanks,

Daniel

[1] Case in point from 0.17.4: https://github.com/saltstack/salt/issues/9400

[2] http://docs.saltstack.com/topics/releases/0.17.4.html

[Corey Quinn]

On Dec 22, 2013, at 6:06 PM, Daniel Bryan 

Pinning only works if the old version is still in the package repo.

...which Launchpad doesn't support. 

w quickly Salt development progresses, and how

stable the releases are in general, but these breaking patch releases are

becoming a real pain. We've been tempted to set up our own apt mirror so that

we can control the uptake of a new release, but we'd prefer to avoid this.

You SHOULD be doing this, regardless of which config manager you're using. 

Upstream does occasionally break; that's why in mature prod environments new releases of mission critical software are vetted prior to introduction. 

Has there been any further thought into keeping previous releases in

package repo? If there are technical obstacles to this, what would it take to

get it done?

Talk to Launchpad. 

--Corey

Thanks,

Daniel

[1] Case in point from 0.17.4: https://github.com/saltstack/salt/issues/9400

[2] http://docs.saltstack.com/topics/releases/0.17.4.html

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Daniel Bryan]

Well that's pretty decisive then. Guess it's time to set up a stable apt mirror :)