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

[Jeff Johnson]

On Apr 25, 2011, at 10:53 AM, Ryan Schmidt wrote:

>>> 
>>> FYI, this probably didn't require a revision bump. All you've done is changed *how* files are installed, but you haven't changed *what* files are installed. The files a user will get by installing doxyegn @1.7.3_3 are exactly the same as the ones they'll get by installing doxyegn @1.7.3_4. Keep this in mind for future updates so you don't make people rebuild ports unnecessarily.
>>> 
>> 
>> This is a dead-on observation and astute annalysis.
>> 
>> There is a far wider domain of application however, particularly
>> as MacPorts attempts binary packaging:
>> 
>> 	Most "builds" don't change content at all but instead adjust metadata.
> 
> Indeed, we'll have to revise our guidelines when we build and distribute binaries. We don't do that yet, though.
> 

A better policy will help considerably.

There is a fundamental design issue corollary too:

	Always associate metadata with, but not in, binary packaging.

If I knew my own RPM answer more concretely, I'd share positive suggestions.
What isn't so obvious with explicit versioning schemes (MacPorts and RPM and
many many other packaging systems share this design flaw imho) used
to determione "newer" (and in your specific MacPorts doxygen example,
that a rebuild is needed but unnecessary) comes from having specific
policy driven meanings attached to the pair of items associated in
a "version".

Since what I just said is likely totally obscure, all I'm saying in
plain speak is that this metadata

	$ port list | grep doxygen
	doxygen                        @1.7.3          textproc/doxygen

has the string "@1.7.3" as an attached upstream derived version, and has
an implied "0" as a build counter, which are perhaps the simplest
metadata items to discuss in public.

The design flaw is that -- if version+buildcounter is distributed in
packaging metadata -- one is forced to do many unnecessary "builds".

There are other means to associate metadata (like "@1.7.3") with packages
to avoid unnecessary builds and the administrative chores of defining
all possible "correct" behaviors in packaging policy. Nothing
whatsoever wrong with "packaging p[olicy" just its a chore to
do the necessary vetting and enforcement.

Other means to associate metadata "with but not in" a package
involve internal identification schemes like UUID's and distributed lookup's
to re-attach metadata (like "@1.7.3") to binary package content. Not hard,
just not what is widely used in packaging.

The design rule for "packaging" SHOULD attempt a clear boundary between
metadata and content (or you WILL have unnecssary rebuilds, which isn't
the worst solution, but isn't the best design imho).

Again apologies for what I'm sure are totally obscure comments, your analysis
was surprisingly astute, nothing more.

hth

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/7598dd89/attachment-0001.bin>