[oi-dev] package manifest "build" proposal follow-up

[Michael Keller]

after a helpful discussion on #oi-dev and trying to make some example manifests for different package distributors, I would like to change the following things:

- build.yourself : remove because it works for spec files, but for opencsw it works sometimes, sometimes not. (no discussion that opencsw doesn't do ips anyway please)

- build.wiki : remove because it's to specific about the technology/service the site is using


instead of build yourself which might be a problem to provide anyway, it should be more something like

- build.configuration
or
- build.info

which can be:

- a spec file where the options are shown
- build systems output or the interesting peaces of it 

Because it depends on the type of binary / tool / language those information and it's usefulness will vary. At the end it's the package maintainer who should know best whats important because he/she did solve the problems building it.



Another problem I was pointed to is, that the packages distributors source repositories might change or some parts of the url. That is the case when the latest version is in the trunk and there is no option for a versioned checkout. This affects build.configuration | build.info  and build.this.

Thats a real problem but its up to the distros to fix that. they can use urls which will be redirected or resolved on their systems. so not really "our" problem.


also something like - build.pkgsource would be more easily understandable then build.this for developers...



Another useful debatable identifier could be

- build.bugs

but that could be also be a link or text on the url referenced by build.notes ...


so the "current" namespace would be:


( unique for each package )

- build.configuration or build.info : URL to maintainer choosen informations regarding the build configuration

- build.pkgsource : URL to the build systems source used building the package (single file url, svn, hg or a url which is resolved on time by the package distrubutor)

- buid.notes : an URL referencing notes specific to the package ( infos, bugs etc. )



( similar for all packages using the same build system version )

- build.buildpkg : an IPS URL of the packaged build system itself

- build. setup: an URL referencing a page how to setup the IPS packaged build system which includes all steps from installing it via build.buildpkg or any other way up to packaging the build


( same for all packages )

- build.welcome : an URL referencing a welcome page of the package distributors targeted to package builders





There is a "problem" including the studio compilers into build.buildpkg . But that could be handled by providing a setup script within that package and informations how to call that after downloading the non distributable parts. That informations (download url and setup instructions) would be given on the url referenced by build.setup .



About the "build" name itself:  we could ask Oracle/SUN if they feel ok with that (and the proposal etc.). But I opt against using a "domain"-name like prefix. It also should not include a reference to a specific distribution (e.g. openindiana) . 

"build" is much more standard as "pkg" and "info". It's Suns fault that they didn't include it firsthand. And if we could take it, why not? they have alway the option to introduce a "build-oracle"...



There were also opinions for a single url to the build system. so the user should have to look up where to get the build system itself, how to setup it etc. . For SFE in the current state that would make sense :-) . But it shouldn't be like that. The most important thing is that if the setup is followed step by step the user will have a usable system. Without searching for the next missing bits of informations. If a package distributor can't provide that, then it's empty.

build.buildpkg might be redundant given that the url to it could/should be also in build.setup.  

But, at least it should be "reserved" so it could be used later when there is a standard how build systems are installed and called. build.buildpkg would then provide a way to automate some things further.


Thanks for reading. Hope you've some thoughts too.

  Michael