Hi,

Few days ago was released news about SourceJuicer availability.
I don't see so many submitted packages in SJ and probably I know why it
is.
For example I want to start working on few packages for submit to SJ but
I can not start working on this because there is no package with
pkgbuild tool in /rel or even /dev IPS repositories.

Next thing: if I remember correctly pkgbuild is tool which should
provide very simillar way for build package to rpm based way.
I spend a lot of time on building rpm packages (few years .. in some
days I've build even tenths or something close to hundreds packages per
day). I see on SJ example page which suggest that pkgbuild environment
does not provide some basic macros environment.
On http://jucr.opensolaris.org/help/spec_file I see in point 4.2:

%prep
rm -rf %name-%version
%setup -q -n nano-%version

rpm based %setup macro performs "rm -rf %name-%version" by default and if 
pkgbuild
provides the same base macros set this example is incorrect/misleading.

Next .. section 4.3: in this case instead:

---
%build
export CFLAGS="%optflags"
export LDFLAGS="%{_ldflags}"
./configure --prefix=%{_prefix}                 \
            --bindir=%{_bindir}                 \
            --mandir=%{_mandir}                 \
            --infodir=%{_infodir}               \
            --sysconfdir=%{_sysconfdir}         \
            --enable-all
make
---

should be:

---
build
%configure \
            --enable-all
%{__make}
---

rpm %configure macro automatically adds using all above parameters (and few 
more).
If pkgbuild does not provides %configure and %__make macros it should be fixed.

Using %{__make} instead plain "make" in case rpm allows make package build more
or less parallel on build nviroment level without touching spec file by
add in ~/.rpmmacros line like:

%__make         make -j <mum>

Above (my) example is more flexible and provides even shorter form.

Next part of point 4.3:

---
%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
rm -f $RPM_BUILD_ROOT%{_infodir}/dir
---

it should be rather:

---
%install
rm -rf $RPM_BUILD_ROOT
%{__make} install DESTDIR=$RPM_BUILD_ROOT
rm -f $RPM_BUILD_ROOT%{_infodir}/dir
---

Next point: example in 4.6:

---
%files
%defattr (-, root, bin)
%dir %attr (0755, root, bin) %{_bindir}
%{_bindir}/*
%{_infodir}/*
%dir %attr(0755, root, sys) %{_datadir}
%dir %attr(0755, root, bin) %{_mandir}
%dir %attr(0755, root, bin) %{_mandir}/*
%{_mandir}/*/*

---

First: I know that traditional/"normal" Solaris package has listed
in files list all directories .. but IMO it is bad habit.
IMO if we want to start working on some new way of packaging we should drop 
this habit.
Base directories hierarchy should be only in some core distribution package .. 
and nowhere else.

But this is less important. More important it is using attributes "as it is" 
after %install
stage in build directory prefix.
IMO %files section should be written in way which which will allow
completely predict ownership and attributes of files and directories
listed in %files without performing test build.
If we will use this kind of rule it will be even possible write some tool which 
will allow
audit/check %files section without performing test build.

If it will be used above example should look more like:

%files
%defattr (644,root,bin,755)
%attr(755,root,bin) %{_bindir}/*
%{_infodir}/*
%{_datadir}/*
%{_mandir}/*/*

I've just looked on my private packages repository on nano.spec. Below some 
parts of my spec file:

%prep
%setup -q
%patch0 -p1
%patch1 -p2

%build
autoreconf --copy --force
%configure \
        --enable-all
%{__make}

%install
rm -rf $RPM_BUILD_ROOT
install -d $RPM_BUILD_ROOT{%{_desktopdir},%{_pixmapsdir}}

%{__make} install \
        DESTDIR=$RPM_BUILD_ROOT

install %{SOURCE1} $RPM_BUILD_ROOT%{_desktopdir}
install %{SOURCE2} $RPM_BUILD_ROOT%{_pixmapsdir}

%find_lang %{name}

rm -f $RPM_BUILD_ROOT%{_infodir}/dir

%clean
rm -rf $RPM_BUILD_ROOT

%post
[ ! -x /usr/sbin/fix-info-dir ] || /usr/sbin/fix-info-dir -c %{_infodir} 
>/dev/null 2>&1

%postun
[ ! -x /usr/sbin/fix-info-dir ] || /usr/sbin/fix-info-dir -c %{_infodir} 
>/dev/null 2>&1

%files -f %{name}.lang
%defattr(644,root,root,755)
%doc AUTHORS BUGS ChangeLog NEWS README THANKS TODO UPGRADE doc/nanorc.sample 
doc/faq.html
%attr(755,root,root) %{_bindir}/*
%{_datadir}/nano
%{_desktopdir}/nano.desktop
%{_mandir}/man[15]/*
%{_infodir}/*info*

Some comments and questions related to above example and OpenSolaris:
- autoreconf does not work in OpenSolaris (there is no package which provides
  /usr/bin/aclocal .. simple autoreconf fails by lack this tool which should
  come with latest version automake package).
  Simple .. automake 1.10.x which comes with OpensSolaris is broken [1].
  Clarification: above my example uses autoreconf because %patch0 patches 
configure.ac file,
- %post and %postun rpm scripts should be replaced by some actions scripts in 
case OpenSiolaris.
  Q: do we have any actions script for update/regenerate on install/uninstall 
stage %{_infodir}/dir index file?
- what about language dependent files like gettext *.mo files in case 
OpenSolaris?
  (in above example files collected by "%find_lang %{name}" macro and inserted 
in
  %files list by "-f %{name}.lang" %files parameter).
  Q1: do we have any special language dependent attributes on IPS level package 
description level?
  Q2: What about %doc attribute?
- OpenSolaris install scrip still handles only one (first) directory and 
executing
  "istall -d /foo /bar" creates only first (/foo) directory:

tkloc...@kloczek:~# install -d /foo /bar
directory /foo created
tkloc...@kloczek:~# ls -ld /foo /bar
ls: cannot access /bar: No such file or directory
drwxr-xr-x 2 bin bin 2 2009-03-26 11:30 /foo

  IMO it will be good ASAP fix/extend OpenSolaris install script for make 
porting
  spec files from Linux easier.

[1] I found another (IMO) bug in autoconf/automake package dependences:

tkloc...@kloczek:~# pkg uninstall SUNWgnu-automake-19; pkg uninstall 
SUNWgnu-automake-110
Creating Plan /pkg: Cannot remove 
'pkg:/[email protected],5.11-0.109:20090305T192726Z' due to
the following packages that depend on it:
  pkg:/[email protected],5.11-0.86:20081204T035913Z
  pkg:/[email protected],5.11-0.109:20090305T202740Z

Creating Plan |pkg: Cannot remove 
'pkg:/[email protected],5.11-0.109:20090305T192724Z' due to
the following packages that depend on it:
  pkg:/[email protected],5.11-0.86:20081204T035913Z
  pkg:/[email protected],5.11-0.109:20090305T202740Z

Why automake packages are required by gcc? automake/autoconf should be not 
run-time requirement. This package
is necessary only when you need to rebuild autoconf/automake/libtool/gettext 
files.
This packages should be only listed in build stage requirements and/or in some 
meta package dependencies
which install whole development environment .. you don't need automake when you 
want to use gcc.
Next thing .. in dependencies should be listed only latest automake version 
(not for both).

BTW1: what about build stage dependencies ? (Buildrequires and Buildconflicts 
rpm tags)
BTW2: why pkg does not accept multiple package names in install/uninstall 
parameters?
Bug ? fracture ? or should I create RFE for this?

(After discuss above I'll make all necessary bug reports/RFEs for above on 
defect.opensolaris.org)

Tomasz
-- 
Tomasz Kloczko
Senior System Administrator, Tiscali UK Ltd

_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to