Brian Gupta wrote: > I am moving this discussion to install-discuss. (Please remove > opensolaris-discuss from any replies). > > On 5/17/07, Bart Smaalders <bart.smaalders at sun.com> wrote: >> Brian Gupta wrote: ... >>> * Must support source packages. (With all dependency info, >>> allowing an install or upgrade via source). >> Why? Does this make sense for large environments like a kernel? >> Wouldn't it make more sense to point someone at an hg server? > > I think it does. Let me try and articulate why. 1) Packages can be > delivered on media, you are suggesting baking in a dependency on a > network service. 2) There is an expectation that source packages are > supported. (outside the Solaris community) 3) ON and the kernel aren't > really packaged as tightly as they could be. (Opinion) >
With respect to each of your points above: 1. We could deliver a pre-populated hg repository on media; by doing that instead of just a collection of source packages, you'd give people a simple, immediate connection back to the project(s) from whence the sources came, which seems more valuable both to users and the project than a static package. 2. Expectations are an interesting question, and often change over time. The reliance on source packages in other communities I'd partially ascribe to lack of good distributed source management tools when those communities were in their formative stages. Inertia takes hold from there. 3. Granularity of packaging of any component seems entirely tangential to the question of source packages. ... > > Also, I have noted many responses claim that the current packaging > system supports everything I have listed. Clearly my understanding of > what is included in the current packaging system is flawed. I am only > aware of the following metadata: > It's the standard, SVR4-designed set, but others can be added, as we have for various Solaris product purposes. > PKG Defines the package's name, abbreviation. It should be > alphanumeric, no number as first character > NAME Full name of the package. Provide a clear, concise and complete > information about your package > ARCH Describes what sort of architecture is associated with the > package. Maxim 16 alphanumeric characters > VERSION The version of the package. 256 max ASCII characters. Can not > begin with left parenthesis > CATEGORY Used to describe what it is the category of that package. > Possible values: system or applications Those are the recommended basic ones; you'll see others. > DESC Text that describes the package. Use a real description about this > package > PSTAMP The time/date when the package was released Time it was built, actually, not released. > EMAIL The email address of the author of the package > BASEDIR Defines where the software package will install, under what > slice the package will go Directory, not slice. Slices may or may not correspond to directories. Dave
