coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

Sure. Different Types of keywords (or tags) ... could include "Beta", etc?


Yes. Well, sorta. We do require that roles in the same MSI are versioned together. Since we anticipate many smaller packages, this won't be as silly as it may sound.

And, kindof.

On one hand, by keeping our required data separate, it makes it easier to one day abandon MSI (if things came to that). On the other hand, if it's not too hard, why not merge them. I'll let you make the call.

Although, platform, don't trust the MSI version of that... it's evil.

G

From: Eric Schultz [mailto:wwahammy@xxxxxxxxx]
Sent: Thursday, August 12, 2010 5:11 PM
To: Garrett Serack
Cc: coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: Questions, Questions, Questions

Hey gang,

One quick question regarding the MSI tables, one little more complex one  and some food for thought.

- On CO_TAGS, I understand that it holds keywords so what is the type column there for? Are there different types of keywords?

- Regarding CO_BINDING_POLICY, as Garrett said this is needed to understand which versions of the package this one replaces, particularly for SxS and .NET assemblies. To me, that assumes that each package can only contain a single assembly. Is that correct?

- Some of these columns seem to duplicate functionality already implemented in Windows Installer. Offhand, display_name, description, architecture, author_version and the entire concept of keyword tags have clear analogs in built-in MSI tables. Is this intended?

Eric



On Thu, Aug 12, 2010 at 1:20 PM, Garrett Serack <garretts@xxxxxxxxxxxxx<mailto:garretts@xxxxxxxxxxxxx>> wrote:
Hey Eric,
(you might as well post these to the mailing list so that we can keep track of them... and so others can correct me when I'm wr^H^H ... mistaken)


>> In the CO_PACKAGE table, there is an id field. What type is this field supposed to be and where does it come from? (autogen by mkPackage, autogen by previous part of CoApp toolchain or set by the developer)


>> Are CoApp package IDs globally unique? If I say I want package with ID 1, I can be safe knowing no other package from any repo will have that ID? Are these the IDs you had mentioned should be generated in a consistent manner, say with MD5 hashes of name, version, architecture and I assume the developer's public key?

I think ID was intended to be a GUID generated as an MD5 of the {name + arch + version + publickeytoken}. Let's go with that assumption right now.


>>How does name and display_name differ?

Display name I believe was cosmetic in nature so possibly "Mozilla Firefox" whereas the name would just be "firefox" .

>>What is author_version in CO_PACKAGE_PROPERTY and how is that different from version in CO_PACKAGE?

Author version may be slightly different due to the way the original project names their versioning OpenSSL for example has stuff like 0.98k ... whereas our versions must be <num>.<num>.<num>.<num> where each num is 0-65535... This is dictated by the way .NET and WinSxS assemblies are versioned.

>> -What does CO_URL correspond to and what goes in 'type'?

There are several URLs associated with things... package location, original project page, Launchpad page, that type of thing. Type is just the type of URL-I suppose we should have a canonical list of what types we use.

>> - Do CO_ROLE, CO_TAG and CO_BINDING_POLICY actually get their FK_package_id's from CO_PACKAGE_PROPERTIES? That's what the diagram shows but it doesn't really make sense to me why that'd be. :)

The FK_package_id is the foreign key for the package id... which is simply the ID field in the CO_PACKAGE table.
FK_role_id is just the ID of the CO_ROLE table.


>> - Do we just allow any string into CO_ROLE flavor or does it have to be one of the ones we've already come up with like "debugging" and "pgo"?


Yeah, flavor is pretty flexible. It's wide open at this point.

>> Can there be multiple roles of the same type but different flavor in a package? Also can flavor be null?

Hmmm. Yes, it can be null. I suppose that multiple flavors can be in the same package. Not entirely sure that's thought out all the way tho.

>> - What is the type column of CO_LICENSE for?

I'm ... not... sure...

>> - What does CO_BINDING_POLICY do?

Ah, this allows us to say what this package supersedes.  (this is a concept from WinSxS) - we can say that version "1.1.150.77" is a replacement for versions "1.1.0.0" to "1.1.150.76"

>> - What does CO_TAG and its columns hold? Keywords or some sort?
Yeah, just for keyword tagging: "editor" "browser", etc...

>> - Is CO_DEPENDENCY id a GUID or sequentially created int? Same with CO_ROLE id and CO_URL id.

Let's assume GUID. I think.

>> - Is there a need for CO_DEPENDENCY to have an FK_package_child_id? Won't that always be the package id in a given msi?

You are probably correct.

>> - CO_INSTALL_PROPERTIES: You're going to have to totally explain it cuz I've got no idea :)

At this point in time, this is just the list of symbolic links that the engine creates at the end of installation.  It's going to be more complicated in the future, but for now assume that's all this is.

Enjoy your Thursday morning :)

Eric

Garrett Serack | Open Source Software Developer | Microsoft Corporation
I don't make the software you use; I make the software you use better on Windows.