On 10/12/07, Dermot McCluskey <dermot.mccluskey at sun.com> wrote:
>
> Enhancements we are already considering:
> - support parallel builds (not just make -j, but building several spec files
> in parallel)
> - optionally installing to, and resolving dependencies from, a prototype area
> (instead of "/", eg possibly with zones or FUSE-type file system)
> - interactive debugging
> - optionally include/exclude source patches from command-line
> - spec-file "lint" (eg warn about missing defaults)
> - support Solaris 8 & 9
> - better macro support (eg multi-line macros)
> - missing RPM features (eg "%if foo == bar")
> - "exclude" modifier in %files (eg "%{_libdir}/* %exclude *.a")
>
Inputs below
- some of these might be already present that I am not aware of.
- couple of them are not true feature enhancements but better
defaults, stricter error checks.
[1] Mechanism to provide dependency information in the OR form.
OSOLgtk2 OR CSWgtk2 OR SUNWgtk2
[2] If defattr is not present, pkgbuild sets the ownership to the
person building the package. On installing the package, the system
folder permission changes to normal user. This is not desirable. Spec
author should be forced to provide defattr for every package instead
of assuming such a default.
[3] If base dir for a package is not provided, "/" is assumed even if
all the files are getting installed into /usr. There is no indication
(error/warning) regarding such choice of BASEDIR. The tool can check
the pkginfo and the proto files and flag a warning if "/" has been
used when all the files are under "/usr"
Infact it would be nice if the spec author is to mandatorily provide
inputs for SUNW_Pkg, SUNW_ProdVers and SUNW_BaseDir, since suitable
default cannot be assumed.
[4] There is already a well defined convention for setting the
ownership/permissions for /usr, /usr/bin, /usr/lib, /usr/share, etc.
It would be nice if the tool can check if the %files section has the
right details for ownership/permissions and flag a warning. The rules
against which it checks can either be fixed (hard coded) or can be
from a user configurable file where user can provide a rules in a
pre-defined format.
[5] A mechanism to create a suggested %files section, since the tool
can figure out the list of files that are not installed. This tends to
be one of the common error that newbies post.
[6] ("exclude" modifier listed in the enhancements considered is probably this)
In some of the build/packaging related discussions that I have
followed up, one of the weaknesses that is mentioned about pkgbuild
style of package creation vis-a-vis ON style is that pkgbuild does a
"make install" whereby the files to be installed is decided by the
upstream software author and not the person creating the package. The
pkgbuild tool doesn't inherently provide a good control with respect
to this.
This point has its merit. One way to address this is by supporting
something like %files-exclude section that will list files that are
not to be installed.
The pkgbuild tool is not to throw any errors if files exist under
${RPM_BUILD_ROOT} that are not packaged but are present in the files
exclude list.
Addendum: Allowing the spec author to specify a <file-name> under
%files section. This <file-name> specified can have exact list of
files to be installed (something like the install file in ON)
[7] Enhancements to spectool. If the tool can be enhanced to mine the
data better and cover all the paths it would be very nice. Currently I
am not sure if it recognizes multiple packages in a single spec file.
It does not identify all the fields of the spec file.
[8] Some inline commenting inside the tool would help other people
debug/enhance the tool. Currently there are hardly any comments in the
code.
(I am not a perl guy, otherwise I would have pitched in).
regards
Shiv
