[90234] trunk/dports/devel/lua-luahpdf/Portfile

[Ryan Schmidt]

On Mar 26, 2012, at 10:35, Clemens Lang wrote:
> On Mon, Mar 26, 2012 at 05:35:47AM -0500, Ryan Schmidt wrote:
>> Exactly. The buildbot will not rebuild the package unless you increase
>> the port's revision.
>> 
>> r90234 changed the files that the port is supposed to install: it adds
>> examples. But because she did not increase the port's revision, the
>> buildbot did not rebuild the package. The package on the packages
>> server therefore does not contain the examples. The port's revision
>> needs to be increased, so that the buildbot will rebuild the package
>> so that it contains the examples.
> 
> But isn't it a perfectly fine strategy (for whatever reasons), to update
> parts of a Portfile without increasing the revision when planning to
> increase the version shortly after anyway? We've seen the buildbot
> doesn't rebuild the package and thus only gets the new (or removed)
> files with the version update and users don't see the Portfiles for
> another 30 minutes. While there is a possibility users are seeing a
> "inconsistent" version of a port (and the probability increases the
> longer the time between the commits) it isn't very high and acceptable
> imho.
> 
>> Any user who later asks to install the port might receive that
>> pre-compiled archive. So it is important to increase the revision if
>> what you've done will affect the contents of the port, regardless how
>> few seconds have passed since your last commit.
> 
> What we want is users having the binary archive matching their Portfile,
> so if there's no or low chance the user might already have the new
> Portfile (or even see the Portfile in it's intermediate state at all)
> imho there is no need to have the binary archive rebuilt.
> 
> In the end all thoese mails aren't worth the effort anyway, because we
> only support the most recent version of a port, effectively making this
> a non-issue.

I think we both understand how things work but are talking past one another. Below I'll outline the specific sequence of events that occurred and the resulting consequences, to hopefully make things clearer.

Note that at the moment the negative consequences I envisioned are largely theoretical, because there aren't actually any binary packages of lua-luahpdf, because its dependency libharu didn't state what license it's under (so we make the safest assumption: that it's not distributable). But it is important to update one's ports under the assumption that binary archives will be produced, because even if they aren't right now due to license issues in dependencies, hopefully those license issues will be resolved in the near future. For example, I fixed libharu's license just now:

https://trac.macports.org/changeset/91242

So now the next time a change is committed to the lua-luahpdf port, an archive will probably be produced.



Here is the order of events:



2012-02-27 03:12:48: Andrea updated the port to version 1.1:

https://trac.macports.org/changeset/90230

In response, the buildbot built this version:

http://build.macports.org/builders/buildports-snowleopard-x86_64/builds/5220

Any users who had a version earlier than 1.1_0 installed will be shown this new version when they "sudo port selfupdate" and "port outdated" and can upgrade to it.

Theoretical: If this port had been distributable, the buildbot would have noticed that no archive for 1.1_0 existed on the packages server yet, and would have uploaded this archive to the packages server as lua-luahpdf-1.1_0.darwin_10.x86_64.tbz2.



2012-02-27 03:36:30: Andrea modified the post-destroot block to also install the examples, without changing the version or revision:

https://trac.macports.org/changeset/90234

In response, the buildbot built this version:

http://build.macports.org/builders/buildports-snowleopard-x86_64/builds/5223

Any users who had not yet updated to 1.1_0 and who still had a version earlier than 1.1_0 installed will be shown this new version when they "sudo port selfupdate" and "port outdated" and can upgrade to it. But any users who already updated to 1.1_0 within the past ~24 minutes will not know that a new version with examples was subsequently made available and will not learn about it until r91223 is committed 4 weeks later.

Theoretical: If this port were distributable, the buildbot would have noticed that an archive for 1.1_0 already existed on the packages server, and would not have changed it. Any users installing or upgrading to 1.1_0 on a system for which we build binaries (currently Snow Leopard x86_64) anytime during the 4 weeks between 2012-02-27 03:12:48 and 2012-03-26 01:46:39 will get the original pre-built 1.1_0 archive which does not contain the examples.



2012-03-26 01:46:40: Andrea increased the revision:

https://trac.macports.org/changeset/91223

In response, the buildbot built this version:

http://build.macports.org/builders/buildports-snowleopard-x86_64/builds/5879

Any users who had a version earlier than 1.1_1 installed will be shown this new version when they "sudo port selfupdate" and "port outdated" and can upgrade to it.

Theoretical: If this port were distributable, the buildbot would have noticed that no archive for 1.1_1 existed on the packages server yet, and would have uploaded this archive to the packages server as lua-luahpdf-1.1_1.darwin_10.x86_64.tbz2.