Mike Gerdts wrote: > On Mon, Apr 7, 2008 at 11:24 PM, Danek Duvall <[EMAIL PROTECTED]> wrote: >> On Mon, Apr 07, 2008 at 10:05:00PM -0500, Shawn Walker wrote: >> > > | opensolaris.source_url >> > > | A URL to the source code bundle, if appropriate, for the >> package. >> > > | >> > > | opensolaris.repository_url >> > > | A URL to the source code repository, if appropriate, for the >> > > | package. >> > > | >> > > | opensolaris.repository_changeset >> > > | A changeset ID for the version of the source code contained >> in >> > > | opensolaris.repository_url. >> > >> > I'm concerned that the above attributes aren't flexible enough to deal >> > with packages that may contain work from multiple repositories or >> > sources. >> > >> > It might better to provide a more free-form way to record this >> information. >> > >> > Also, assuming a single repository_changeset implies a certain kind of >> > source control system technology being used. Multiple changeset ids >> > may apply depending on the system. >> >> There are a number of folks who have in the past indicated interest in >> wrapping a build system around IPS, a la rpmbuild. They're the ones who >> need to chime in here and suggest what attributes they need. I'd suggest >> that until they do, we shouldn't make these part of the spec. > > Having this information can be useful beyond just building the > packages. I often times read the source when I am debugging issues - > particularly if I am writing dtrace scripts using the fbt provider. > Being able to read the exact version of the code is much more helpful > than reading something that you think is about right. There have been > several times where this leads me to pointing to exact lines of source > as part of service requests or bug reports. Sometimes it even turns > into a fix I contribute... >
I agree that having a way to easily determine/reproduce the build environment of a set of a set of packages is useful; the multiplicity of source code management systems may make this somewhat problematic across the various Solaris consolidations, since ON will use Mercurial, JDS Subversion, and others ???. For software that depends on other packages, those dependencies should be recorded; if build 79 versions of JDS were built against build 77 of ON, for example, then recording the dependency as build 77 versions of ON packages seems to make sense. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
