Hi Shawn, On Sun, 2009-05-24 at 14:13 -0500, Shawn Walker wrote: > > I'm working on adding support for IPS source packages > > in pkgbuild. As discussed earlier[1], the source packages > > will live in a separate repository (which can technically > > be the same repository). I propose adding the following > > meta data: > > > > source packages: > > > > set name=info.source_pkg_type value=pkgbuild > > set name=info.pkgbuild_version > > value=<version of pkgbuild that created the pkg> > > You have a generic name for the tool that built the package, so it seems > logical to have one for the tool that built it as well. > > Perhaps, info.source_pkg_type_version instead of info.pkgbuild_version?
Fine. > > binary packages: > > > > set name=info.source_pkg_server value=<http://url/to/src/ips/server> > > Instead of server, I'd prefer this be: > > info.source_pkg_repo OK. > Also, remember that it isn't necessarily http :-) Yeah, that was just an example. It's actually whatever is set in the PKGBUILD_SRC_IPS_SERVER env variable. > Right now, we support http and https, and eventually the client will > support file:// as well (we already do for publication). > > > set name=info.source_pkg_fmri value=<full fmri of the source package> > > Couldn't there be multiple source packages for a single binary package? No. The source package includes everything referenced in the spec file, and the spec file itself, and one binary package can only be built from one spec file. If a hypothetical build system can have more than one source packages per binary package, they can list multiple values for source_pkg_fmri. > > set name=info.source_pkg_type value=pkgbuild > > > > The source package itself will include the following: > > > > /usr/share/src/<package name>-<package version>/ > > <package name> will be problematic here unless it is escaped. For > example, a package might be named "developer/tool/exuberant-ctags", > which escaped would be 'developer%2Ftool%2Fexuberant-ctags'. That's a good point. I'm leaning towards keeping the package name and converting the /-s to directories so if you have a large number of source packages installed, they are neatly organised. It's not so nice to deal with esc%61%70ed names from the command line. > Also, instead of '-<package version>', I would use the same format that > the FMRI class already provides. As an example: Thinking about this again, source packages belonging to different versions of the same upstream package will have the same name, so you can only install 1 version at any time. If you need to know the version, you can always find out with pkg list or pkg info. Which means I can omit the version altogether and make life easier. > developer/tool/[email protected],5.11-0.111:20090418T200135Z > > ...which, escaped is: > > developer%2Ftool%2Fexuberant-ctags%405.7%2C5.11-0.111%3A20090418T200135Z > > Doing things that way would allow you to easily parse package FMRIs and > get their directory paths just by doing: > > f = > pkg.fmri.PkgFmri("developer/tool/[email protected],5.11-0.111:20090418T200135Z", > > None) > path = f.get_dir_path() > > > By default, the source packages will be called > > src/<binary package name> > > unless there's a better suggestion. > > I wouldn't do that for the same reasons David mentioned. I'd suggest > appending or prefix "source" or "src" to the name (with a leading or > trailing slash respectively), so: > > src/developer/tool/exuberant-ctags Isn't this exactly what I have above? > source/developer/tool/exuberant-ctags > > or: > > developer/tool/exuberant-ctags/src > developer/tool/exuberant-ctags/source > > The other question I have is how you will deal with binary packages that > come from a single or multiple source package? Each spec file has a Name tag, which is the name of one of the binary packages it defines. For example, in gcc.spec, you may define the following packages: developer/tool/gcc library/gccruntime The Name will probably be "developer/tool/gcc", so the source package for both binary packages will be "developer/tool/gcc-src". Laca _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
