[77613] trunk/dports/textproc/doxygen/Portfile

[Jeff Johnson]

On Apr 25, 2011, at 11:46 AM, Rainer Müller wrote:

> On 2011-04-25 16:43 , Jeff Johnson wrote:
>> You might want to think through what "build" policy SHOULD apply
>> if/when you attempt binary packaging. There are many reasons for
>> rebuilding and version bumps and metadata dependency adjustments
>> involved with packaging.
> 
> I guess if we want to ship binaries we would have to revise a lot of
> other things in regards of revision bumps. For example, there will be a
> new policy for soname/compatibility version changes as that would
> require new ports (or subports, slots, etc.) to avoid breaking existing
> binaries.
> 

What the policy SHOULD be is no where near as important as getting the
QA in place for detecting problems in binary distribution soonestly.

> Such things would be handled different in a source or a binary
> distribution. So by the time we are able to produce binaries we will
> come to the point where we will have to decide if we want to distribute
> binaries only or keep source based installs.
> 

Yep. This is what has been the bottlenect to MacPorts binary packaging
all along.

And in fact -- because of bundles and frameworks and DMG's -- there
really hasn't been any need for "binary packaging" because of what
already exists on Mac OS X.

But the motivation towards binary packaging is purely efficiency and
quality control:

	Why should I (and end-luser) spend all this time building from source if
	I can just download working binaries?

The answer to that question is what is driving MacPorts towards binary
packaging imho. And that answer is by no means as simple as the AppStore model
that is working so well for Apple.

73 de Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4645 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110425/c86a795f/attachment.bin>