So many formats, So few packages

[Jeff Johnson]

On Apr 11, 2011, at 5:48 PM, Jordan K. Hubbard wrote:

> 
> On Apr 11, 2011, at 1:43 AM, Rainer Müller wrote:
> 
>> On 2011-04-07 22:03 , Jeff Johnson wrote:
>>> Does MacPorts have a well-defined and documented means of attaching the "new uid's" to
>>> ports?
>> 
>> Can you explain that a bit more? I know what a UUID is, but how are they
>> being used in Mac OS X binaries or where can I read up on that?
> 
> I don't know what Jeff is doing with UUIDs (probably something unnatural ;-) ) but I can say something about how they're used in Mac OS X.   They're basically signed in to binaries using the codesign(1) command (see -i flag) and uniquely identify that binary from the perspective of ongoing continuity.  Let's say, for example, that the binary has some keychain items associated with it.  The UUID ties the application to the keychain items such that when you update the binary, as long as you use the same identity, the updated version of application FOO version BAR can still use the keychain items (without an authorization prompt) from FOO version BAR - 1.   That's not the only thing UUIDs are used for, but it's probably the easiest scenario to explain.
> 

The scheme that you are describing requires a binding of a UUID used as an identifier.

OTOH, that's harder to retrofit onto existing MacPorts build elements because
of the need to carry around the UUID as an identifier only

Make 4 choices
	admin authority => "http://macports.org"
	some conventional prefix "yadda yadda" if you wish
	which content related digest, likely just the integrity checks pre-existing in Portfiles
	UUIDv3 or UUIDv5
and you (being MacPorts) are done defining a "public" identification scheme.

CHange your mind, diddle up different strings, announce, and no tool
breaks because the form of UUID as 128 bits remains constant.

This would be a public identification scheme, permitting others to participate
under the same admin authority, presumably "http://macports.org" as a no-brainer choice.

WHich was the nature of my "unnatural" question:

If MacPorts is willing to devise a "public" identification scheme
by making the 4 choices I've mentioned, I will happily/gladly
fit that into RPM.

If not, I can/will devise my own "public" scheme, essentially what I described
with something like a "/pacports/" hieracrhy.

UUID is the next UID, and only "nobody" is there.

73 de Jeff
	
> - Jordan
> 
> 
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

-------------- 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/20110411/6012f083/attachment-0001.bin>