[packaging] Meeting next week to discuss trusted third-party repositories

[Jeff Johnson]

On Dec 20, 2008, at 12:23 PM, Denis Washington wrote:

> Jeff Johnson wrote:
>>
>> On Dec 20, 2008, at 10:02 AM, Denis Washington wrote:
>>
>>> Tortanick wrote:
>>>>> The very last thing ISVs want is yet another package format.
>>>>> - Dan
>>>>>
>>>>
>>>> I was under the impression that they didn't mind witch package  
>>>> format
>>>> providing there was a single one that they could support and be  
>>>> done with it.
>>>>
>>>
>>>
>>
>> < ... yet another package format design snipped ...>
>>
>>> If I overlooked some fundamental issues, please tell me.
>>>
>>
>> The mechanics of wrapping up {content,scripts,metadata}
>> in a container are not very hard to achieve. Your approach
>> is as good (or bad) is every other container around.
>>
>> The hardest packaging issue is semantically defining package  
>> metadata and how the
>> metadata is to be used by installers and packagers and users and ...
>
> Well, the metadata would be:
>

Good. Below are hysterical comments from well traveled pathways:

> * The package name and provider, for identification and base  
> directory identification (/opt/provider/name).

Do names/providers have to come from a registry or not?

Are you going to enforce "/opt/provider/name" prefixing for paths?
If names/provider/paths are not enforced, then how does one handle the
very predictable name/provider/path collisions that will arise?

>
> * The package version, to be able to determine if a newer version is  
> available (for updaters).

You need to make "newer" decideable. for that matter, "available" as  
well.

>
> * The package architecture, to check binary compatibility with the  
> system to install on.

architecture and abi are very different issues. nothing wrong with  
specifying them at all.

>
> * The required LSB version (and modules), for the same reason.

There is no "required" until there is a specification of "required"  
and a
mechanism for determining what is "required" (or not).
ditto for "version" and "modules" for exactly the same reasons.

>
> * The URL of an update feed file, to check for new versions (in  
> combination with the version data).

All of "URL", "update", "feed", "new", "versions", "combination" and  
"data" are not specified.

>
> * The paths of the installed files and directories, plus their  
> permission modes, for associating the files with the package, and to  
> inform the user in case files are installed outside of the "trusted"  
> directories.
>

Ditto (presumably I don't have to list all the details, but a LSB  
packaging standard will have to).

> As far as I can see, this is all metadata that is required for a  
> third-party application. I for my part wouldn't need anything else  
> at least. The only possible useful addition to this list may be the  
> package files' md5 or sha1 sums for data integrity checks, but this  
> is not a requirement. All other metadata found in other formats as  
> RPM or DEB are more of interest for base system distribution  
> maintainance as far as I can tell (for instance all package  
> relationship metadata like Requires, Replaces, Epoch etc), and don't  
> seem to be needed for self-contained third-party packages.
>
> So, for third-party packaging needs, we have a very small and well- 
> defined set of metadata IMO. I hope I haven't misunderstood your  
> definition of "defining the metadata"; correct me if I'm wrong.
>

Truly, this is a good start. No place in your suggestion have you  
mentioned "format" of packages,
and there are no API/ABI methods being proposed, nor are there any  
defacto definitions, e.g.
	just like 0install/deb/installshield/klik/rpm/klik/...

I'd suggest adopting some conventions for specifying metadata  
concretely.

Note that specification != representation, one has to avoid __ALL__
existing packaging implementations in order to hammer out packaging
metadata semantics and committing to __ANY_ representation of package
metadata that may be distributed.

But sure there's *LOTS* of defacto examples for guidance around,  
examine any existing
package manager implementation for assistance in specifying LSB  
package metadata.

But it __MUST__ be a "LSB Package" standard first and foremost and ab  
initio to
succeed imho.

73 de Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4664 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/packaging/attachments/20081220/1ebaffe3/attachment-0001.bin