On Wed, Apr 30, 2008 at 6:04 PM, Stephen Hahn <[EMAIL PROTECTED]> wrote:
> (So this response is further along, and seems timely to send...)
Thanks for this.
> 5. Author vs upstream. Author seems easier to understand.
> List-valued is fine, but I believe that means we'll need
> primary_author. Shawn gave an example of multiple upstreams, but
> I have to confess I wasn't convinced--either the immediate author
> wants to be treated as an originator, or they will refer to
> themselves as the maintainer.
Ah. Let me clarify.
It all depends on how how the "maintainer" intends to package a piece
of software.
For software that is comprised of multiple components, but placed in a
single package, there could be multiple upstream sources.
So, as an example, let's say I package TurboGears [1] as an all-in-one
package (all the components from various sources) since it requires
very specific versions of other components to operate and they may be
patched or conflict with the current versions of those components
available.
I know the argument here is that you could still package all those
components separately -- yet I know many software authors that combine
software from multiple sources into a single package (in the Windows
world anyway).
Or, as another example, what if it's as something as simple as a
"desktop wallpaper package" with graphics from various artists. Each
artist is a different upstream source.
As for Author vs. Upstream; if you want to call upstream "Author" in
this case, I have no problem with that in general.
*However*, I think it is useful to be able to indicate Author and
Maintainer separately.
As an example, there is an Adventure Game Runtime engine I maintain a
Linux port of. I share the same codebase with the author, and I have
no right to claim that I am the "author" of the software. I'm merely a
maintainer.
Does that help at all?
> 6. Version in description. In the original draft, I made a point
> about keeping the version out of pkg.summary, but allowing it in
> pkg.description. As I hint at in #3 above, the summary string
> is expected to be used by all browsing/reporting interfaces for
> human consumption. The intent is to confine those humans'
> expectations about upgrade to the sequences of versions in the
> relevant FMRIs. So the expected per-package browsing display is
> pkg.summary and the version portion of the FMRI.
>
> info.author_version, which would contain the author's
> conventional version for the package, seems useful to me, too.
I completely agree with this. RedHat attempted to come up with a
versioning scheme to make this clear, and failed in my view.
For example, when they decided to ship mod_perl just before it became
2.0, they chose to ship it as 1.99_09 -- the _09 being their "patch
level."
Being able to know the exact corresponding "author" version that the
package was derived from can be immeasurably helpful.
> 10. Package to SCM linkage. Since we don't have
> consolidation-spanning packages, these should be easier than the
> ARC linkage--some changeset must have produced this version of
> the package. It's probably obvious, but this data is needed for
> software maintenance, whether you do much of the analysis
> yourself or interact with some support provider. The terms,
> "repository" and "changeset", apply to Subversion as well; we
> could use "revision", but publishers using non-changeset oriented
> schemes are probably using tags, branches, or freezepoints.
> ("scm" seems opaque.)
Like Bart, I'm concerned about multiple SCM sources needing to be
referred to for a single package.
Maybe for Sun this isn't the common case, but I'd think it very
possible for 3rd parties.
> 12. license as attribute. The license action is currently needed
> because it delivers a payload, but the point on filtering is
> important. We need to discuss whether we need pkg.license and
> to change "license" to "meta ... type=license ...".
What about packages that are multi-licensed?
> 14. Icons. I'll need more use cases/justification of why these need
> to be actions. (How would you identify different icon sizes and
> types?) My preference is to make this kind of information a URL
> tag/attribute, and move responsibility to the client. (Since
> every published file has a URL, that's not as big a deal as it might
> appear...)
I'd agree. Although there is an interesting possibility here that I
haven't seen considered:
Since ips can retrieve single files from a repository for a package,
would it be possible to refer to an icon by its filehash within the
package and then expect the client to just ask for that single file?
Similar to how emails refer to images in attachments using
"cid:attachment" ?
> 15. Additional tags. Yes, we need to attach tags as packages get
> through additional assessments. What's less clear is whether
> some of these are, in fact, Solaris or Sun only--like Section 508
> (USA accessibility law)--or of broader interest.
>
> com.sun,assessment.section508
> com.sun,assessment.open-source
> [info.arc_url]
>
> where each of these carries a URL or identifier (potentially only
> of use to the publisher).
Which brings up another interesting thing. How to prevent third party
packages from using another authority's tags?
Could we perhaps require that namespace related items require a
publisher "certificate" of some sort and then those attributes are
only valid when signed by them?
I know there's many pitfalls there, but it's just a thought...
Cheers,
--
Shawn Walker
"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
[1] http://turbogears.com/about/
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
