Management of conflicting packages is sub-optimal.

[Robert Bruce Park]

I just had a case where two silos contained unity8, and they were both published so close to one another that the mechanism that prevents conflicting packages from publishing wasn't able to trigger.

The way it currently works is, the publish job will check if the package version at the destination has changed since the local package version was built, and will block publication if it sees that. But since they were both published so close in time, the first-publish one didn't land in destination before the second publish job ran. So the second publish job had no way to know that the first was already published.

I guess the only way to fix this is to develop some kind of publication lockfile, such that if one silo publishes one package, another silo can't publish.

For example, the publish job could check for the presence of ~/silos/ubuntu_vivid_unity8.lock file before publishing, and then only publish if no such file exists. If it doesn't exist, the publish job would create it and then continue with publishing. The file could then be removed by the merge job.

It's important that such a lock file be specific to distro, series, and package name, because eg you can publish the same package to utopic and vivid without conflict, or to ubuntu and rtm... it's only a conflict if they both try to publish to vivid at the same time.

[Robert Bruce Park (robru)]

Ah, the new silo dirty logic means one silo publishing unity8 will created a file named unity8_is_dirty in any other silo containing unity8, so the publish job just needs to grow a check for dirty files and refuse publication in that case.