[belenix-discuss] Fwd: [belenix-notify] SF.net SVN: belenix:[420] trunk/spec_files/rpms/rpm5.spec
Moinak Ghosh
Just completed this milestone. This took a while since I was
starting from building the compiler and working out an approach
for packaging with RPM5.
This is still a work in progress since we need macros to handle
driver and SMF service installation but this is the required foundation.
I will shortly provide a bootstrap tarball that you can use to get rpm5
on OpenIndiana.
Regards,
Moinak.
---------- Forwarded message ----------
From: belenix-notify <belenix...@lists.sourceforge.net>
Date: Sun, Feb 13, 2011 at 8:42 PM
Subject: [belenix-notify] SF.net SVN: belenix:[420]
trunk/spec_files/rpms/rpm5.spec
To: belenix...@lists.sourceforge.net
Revision: 420
http://belenix.svn.sourceforge.net/belenix/?rev=420&view=rev
Author: moinakg
Date: 2011-02-13 15:12:12 +0000 (Sun, 13 Feb 2011)
Log Message:
-----------
Working RPM5 with XZ compression on OpenSolaris platform, w00t#2.
Modified Paths:
--------------
trunk/spec_files/rpms/rpm5.spec
Modified: trunk/spec_files/rpms/rpm5.spec
===================================================================
--- trunk/spec_files/rpms/rpm5.spec 2011-02-13 14:16:14 UTC (rev 419)
+++ trunk/spec_files/rpms/rpm5.spec 2011-02-13 15:12:12 UTC (rev 420)
@@ -266,9 +266,9 @@
(cd ${RPM_BUILD_ROOT}%{__usrlibrpm}
cp macros macros.tmp
- cat macros.tmp | sed 's/^%_repackage_all_erasures
1/%_repackage_all_erasures 0/' > macros
+ cat macros.tmp | sed 's/^%%_repackage_all_erasures
1/%%_repackage_all_erasures 0/' > macros
cp macros.rpmbuild macros.rpmbuild.tmp
- cat macros.rpmbuild.tmp | sed 's/^#%_binary_payload
w9.gzdio/%_binary_payload w6.xzio/' > macros.rpmbuild
+ cat macros.rpmbuild.tmp | sed 's/^#%%_binary_payload
w9.gzdio/%%_binary_payload w6.xzio/' > macros.rpmbuild
rm -f macros.tmp macros.rpmbuild.tmp)
mkdir -p ${RPM_BUILD_ROOT}%{__usrlibrpm}/%{_arch}-solaris2.11/
@@ -288,6 +288,15 @@
mv ${RPM_BUILD_ROOT}%{_libdir32}/python%{with_python_version}/vendor-packages/rpm/*.so*
\
${RPM_BUILD_ROOT}%{_libdir32}/python%{with_python_version}/vendor-packages/rpm/%{_arch64}
+%if %{build_64bit}
+mkdir -p ${RPM_BUILD_ROOT}%{_bindir32}
+(cd ${RPM_BUILD_ROOT}%{_bindir}
+ for f in *
+ do
+ (cd ..; ln -s %{_arch64}/${f})
+ done)
+%endif
+
%find_lang rpm
%if %{with_apidocs}
@@ -341,6 +350,11 @@
%rpmattr %{_bindir}/rpm
%rpmattr %{_bindir}/rpmconstant
+%if %{build_64bit}
+%{_bindir32}/rpm
+%{_bindir32}/rpmconstant
+%endif
+
%rpmattr %dir %{__rpmhome}
%rpmattr %{__rpmhome}/rpm.*
%rpmattr %{__rpmhome}/tgpg
@@ -382,6 +396,12 @@
%attr(0666, root, other) %{_docdir}/rpm-%{version}/*
%rpmattr %{_bindir}/rpm2cpio
%rpmattr %{_bindir}/gendiff
+
+%if %{build_64bit}
+%{_bindir32}/rpm2cpio
+%{_bindir32}/gendiff
+%endif
+
%dir /etc/rpm
%attr(0755, root, bin) %dir /var/lib/rpm
%rpmdbattr /var/lib/rpm/*
@@ -449,6 +469,10 @@
%files build
%rpmattr %{_bindir}/rpmbuild
+%if %{build_64bit}
+%{_bindir32}/rpmbuild
+%endif
+
%rpmattr %{__rpmhome}/brp-*
%rpmattr %{__rpmhome}/check-files
%rpmattr %{__rpmhome}/cross-build
This was sent by the SourceForge.net collaborative development
platform, the world's largest Open Source development site.
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
belenix-notify mailing list
belenix...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/belenix-notify
--
================================
http://www.belenix.org/
http://moinakg.wordpress.com/
_______________________________________________
belenix-discuss mailing list
http://mail.opensolaris.org/mailman/listinfo/belenix-discuss
http://groups.google.com/group/belenix-discuss
Joerg Schilling
> Just completed this milestone. This took a while since I was
> starting from building the compiler and working out an approach
> for packaging with RPM5.
I am nearly ready with getting back the SVR4 packages in ONNV.
How did you create your package definitions? I am asking as I still need to
find places for aprox. 1000 files that are missing from the package definitions
from build 135 - the past SVR4 package based build.
BTW: If you like to make sure that you compile on OSS bits only, you may like
to look at the last Schillix-0.7.2. OpenIndiana inherited hidden bits from
Sun's Indiana.
In that case, you need the OSS replacements that have been integrarted into
Schillix-ON, see:
http://developer.berlios.de/projects/schillix-on/
http://hg.berlios.de/repos/schillix-on
You need e.g. the K&R cpp (see:
http://hg.berlios.de/repos/schillix-on/file/69fa6d7cbcb5/usr/src/cmd/cpp)
to be able to use rpcgen(1), dtrace(1) and (as)
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Moinak Ghosh
<Joerg.S...@fokus.fraunhofer.de> wrote:
> Moinak Ghosh <moi...@belenix.org> wrote:
>
>> Just completed this milestone. This took a while since I was
>> starting from building the compiler and working out an approach
>> for packaging with RPM5.
>
> I am nearly ready with getting back the SVR4 packages in ONNV.
>
> How did you create your package definitions? I am asking as I still need to
> find places for aprox. 1000 files that are missing from the package definitions
> from build 135 - the past SVR4 package based build.
>
I do not yet have entire ON packaged using rpm5 since a few
postinstall action macros need to be created. For eg. driver
install and SMF service handling. I want to avoid any postinstall
scripting for common tasks.
So I have not yet looked at the missing file entries that you
mention.
> BTW: If you like to make sure that you compile on OSS bits only, you may like
> to look at the last Schillix-0.7.2. OpenIndiana inherited hidden bits from
> Sun's Indiana.
>
Thanks will look at Schillix 0.7.2. Closed bins need to be replaced.
> In that case, you need the OSS replacements that have been integrarted into
> Schillix-ON, see:
>
> http://developer.berlios.de/projects/schillix-on/
>
> http://hg.berlios.de/repos/schillix-on
>
> You need e.g. the K&R cpp (see:
> http://hg.berlios.de/repos/schillix-on/file/69fa6d7cbcb5/usr/src/cmd/cpp)
> to be able to use rpcgen(1), dtrace(1) and (as)
>
Thanks for this pointer. The cpp utility is a key piece.
Regards,
Moinak.
--
================================
http://www.belenix.org/
http://moinakg.wordpress.com/
Joerg Schilling
> > I am nearly ready with getting back the SVR4 packages in ONNV.
Last night, I published the first steps towards SVr4 packaging, see:
http://hg.berlios.de/repos/schillix-on
The code compiles (see http://schillix.berlios.de/pmwiki.php/Main/HowtoCompile)
and it builds packages for most of the files.
BTW: I would be interested in a timing for a "hg clone" operation from India.
I am ready after 3 minutes from my VDSL at home.
> I do not yet have entire ON packaged using rpm5 since a few
> postinstall action macros need to be created. For eg. driver
> install and SMF service handling. I want to avoid any postinstall
> scripting for common tasks.
Do you create rpm packages with similar names and content as the Sun packages?
Did you create your rpm spec files by hand or did you automate this step?
BTW: please feel free to file bugs and RFEs to the bug tracking system:
http://developer.berlios.de/mantis/set_project.php?project_id=12153
You need a Berlios account to enter bugs.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Moinak Ghosh
Responses inline ...
On Mon, Feb 14, 2011 at 11:14 PM, Joerg Schilling
<Joerg.S...@fokus.fraunhofer.de> wrote:
> Moinak Ghosh <moi...@belenix.org> wrote:
>
>> > I am nearly ready with getting back the SVR4 packages in ONNV.
>
> Last night, I published the first steps towards SVr4 packaging, see:
>
> http://hg.berlios.de/repos/schillix-on
>
> The code compiles (see http://schillix.berlios.de/pmwiki.php/Main/HowtoCompile)
> and it builds packages for most of the files.
>
> BTW: I would be interested in a timing for a "hg clone" operation from India.
> I am ready after 3 minutes from my VDSL at home.
>
Here is the timing (no other network using process was running):
moinakg@rigel:~$ time hg clone http://hg.berlios.de/repos/schillix-on
destination directory: schillix-on
requesting all changes
adding changesets
adding manifests
adding file changes
added 13196 changesets with 153454 changes to 59926 files
updating working directory
46223 files updated, 0 files merged, 0 files removed, 0 files unresolved
real 14m23.841s
user 3m20.819s
sys 0m36.636s
I have a fairly basic 2Mbps ADSL line.
>
>> I do not yet have entire ON packaged using rpm5 since a few
>> postinstall action macros need to be created. For eg. driver
>> install and SMF service handling. I want to avoid any postinstall
>> scripting for common tasks.
>
> Do you create rpm packages with similar names and content as the Sun packages?
> Did you create your rpm spec files by hand or did you automate this step?
>
I will be partly following the new naming scheme in IPS. I will
not use hierarchical names as they are too verbose and difficult
to remember. Just the last component which is the actual package
name. RPM's grouping/categorization is fine.
>
>
> BTW: please feel free to file bugs and RFEs to the bug tracking system:
>
> http://developer.berlios.de/mantis/set_project.php?project_id=12153
>
> You need a Berlios account to enter bugs.
>
> Jörg
>
Regards,
Moinak.
--
================================
http://www.belenix.org/
http://moinakg.wordpress.com/
Joerg Schilling
> > Last night, I published the first steps towards SVr4 packaging, see:
> >
> > http://hg.berlios.de/repos/schillix-on
> >
> > The code compiles (see http://schillix.berlios.de/pmwiki.php/Main/HowtoCompile)
> > and it builds packages for most of the files.
> >
> > BTW: I would be interested in a timing for a "hg clone" operation from India.
> > I am ready after 3 minutes from my VDSL at home.
> >
>
> Here is the timing (no other network using process was running):
> moinakg@rigel:~$ time hg clone http://hg.berlios.de/repos/schillix-on
> destination directory: schillix-on
> requesting all changes
> adding changesets
> adding manifests
> adding file changes
> added 13196 changesets with 153454 changes to 59926 files
> updating working directory
> 46223 files updated, 0 files merged, 0 files removed, 0 files unresolved
>
> real 14m23.841s
> user 3m20.819s
> sys 0m36.636s
>
> I have a fairly basic 2Mbps ADSL line.
This looks promising. Thank you for the test!
> > Do you create rpm packages with similar names and content as the Sun packages?
> > Did you create your rpm spec files by hand or did you automate this step?
> >
>
> I will be partly following the new naming scheme in IPS. I will
> not use hierarchical names as they are too verbose and difficult
> to remember. Just the last component which is the actual package
> name. RPM's grouping/categorization is fine.
So I asume that you did create the rpm spec files manually?
I did create the SVR4 packages (the changes and new packages since build 135)
manually. There are currently 270 files left overt that need to be introduced
into existing packages.
Regarding the naming scheme, I did introduce a new tag in the pkginfo file that
follows the IPS naming scheme:
SUNWinstall-beadmr/pkginfo.tmpl:
PKG=SUNWinstall-beadmr
SCHILY_PKGNAME="install/beadm@PKGVERS:TIME"
SCHILY_OLDNAME="SUNWbeadmr"
NAME="beadm utility (Root)"
ARCH="ISA"
VERSION="ONVERS,REV=0.0.0"
translates into:
SUNWinstall-beadmr/pkginfo:
PKG=SUNWinstall-beadmr
SCHILY_PKGNAME="install/be...@0.5.11,5.11-0.148:20110224T151211Z"
SCHILY_OLDNAME="SUNWbeadmr"
NAME="beadm utility (Root)"
ARCH="i386"
VERSION="11.11,REV=2011.02.24.16.12"
and there is
SUNWbeadmr/pkginfo.tmpl:
PKG=SUNWbeadmr
SCHILY_NEWNAME="SUNWinstall-beadmr"
NAME="beadm utility (Root)"
ARCH="ISA"
VERSION="ONVERS,REV=0.0.0"
SUNW_PRODNAME="SunOS"
SUNW_PRODVERS="RELEASE/VERSION"
with a back pointer to the new SVR4 package name.
There is a script "pkgsort" that automatically creates a list with package
names in the needed install order (pkgsort takes 7 seconds to finish).
see:
http://hg.berlios.de/repos/schillix-on/file/0fd93319a782/usr/src/pkgdefs/pkgsort
and there is "pkginstall" that installs all Schillix-ON packages in 50 seconds:
http://hg.berlios.de/repos/schillix-on/file/0fd93319a782/usr/src/pkgdefs/pkginstall
I will later introduce a wrapper that allows to work based on the IPS package
names.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Moinak Ghosh
<Joerg.S...@fokus.fraunhofer.de> wrote:
[...]>> I will be partly following the new naming scheme in IPS. I will
>> not use hierarchical names as they are too verbose and difficult
>> to remember. Just the last component which is the actual package
>> name. RPM's grouping/categorization is fine.
>
> So I asume that you did create the rpm spec files manually?
>
Yes, only for the packages that I intend to build from source.
I followed a similar mechanism using the earlier transactional Python based
package manager I had developed earlier for BeleniX on top of SVR4
packaging:
http://belenix.svn.sourceforge.net/viewvc/belenix/trunk/spec_files/ext-sources/spkg?revision=175&view=markup
http://belenix.svn.sourceforge.net/viewvc/belenix/trunk/spec_files/ext-sources/spkg_mod.py?revision=395&view=markup
http://belenix.svn.sourceforge.net/viewvc/belenix/trunk/spec_files/ext-sources/spkg_trans.py?revision=189&view=markup
http://belenix.svn.sourceforge.net/viewvc/belenix/trunk/spec_files/ext-sources/tsort.py?revision=150&view=markup
The last one is a Python based topological sort that takes approx a second
to sort 850 packages. Including the time taken to actually build
the partially
ordered map it is probably around 5 seconds in total.
One problem with SVR4 is that it does not have the concept of an "upgrade".
If I deliver a new version of a package and overwrite the older
one, it just adds
or overwrites all the files. If some file pathnames have changed it does not
automatically remove the older pathname. So both file locations remain.
In addition the latest SVR4 seems to have a subtle bug. In livecd mode if
I mount the harddisk and try to remove a package using pkgrm -R <mntpt>
it crashes somewhere in libspmi. I did not have the time or patience to
fully debug it so I used a slightly older version in BeleniX.
Regards,
Moinak.
--
================================
http://www.belenix.org/
http://moinakg.wordpress.com/
Joerg Schilling
> > I will later introduce a wrapper that allows to work based on the IPS package
> > names.
> >
>
> I followed a similar mechanism using the earlier transactional Python based
> package manager I had developed earlier for BeleniX on top of SVR4
> packaging:
>
> http://belenix.svn.sourceforge.net/viewvc/belenix/trunk/spec_files/ext-sources/spkg?revision=175&view=markup
> http://belenix.svn.sourceforge.net/viewvc/belenix/trunk/spec_files/ext-sources/spkg_mod.py?revision=395&view=markup
> http://belenix.svn.sourceforge.net/viewvc/belenix/trunk/spec_files/ext-sources/spkg_trans.py?revision=189&view=markup
> http://belenix.svn.sourceforge.net/viewvc/belenix/trunk/spec_files/ext-sources/tsort.py?revision=150&view=markup
I will have to look more closely into that....
> The last one is a Python based topological sort that takes approx a second
> to sort 850 packages. Including the time taken to actually build
> the partially
> ordered map it is probably around 5 seconds in total.
I have no idea what time I would need in case that I did write a generic
application for sorting. Going from the Bourne shell to ksh93 with it's
built-ins did go from 28 seconds to 7 seconds.
> One problem with SVR4 is that it does not have the concept of an "upgrade".
> If I deliver a new version of a package and overwrite the older
> one, it just adds
> or overwrites all the files. If some file pathnames have changed it does not
> automatically remove the older pathname. So both file locations remain.
The right way seems to first install the new release and then to remove the old
version.
A file that is no longer used has a reference count of 1 and is easily to
identify.
A file that is the same but now has a referende count > 1 for the same base
package name will stay and just remove the reference to the old package version.
For a file that differs from the old version but is the same as expected for
the new version we will just remove the related data base entry but the file
stays.
The package system will have to learn about version tags to do this correctly.
> In addition the latest SVR4 seems to have a subtle bug. In livecd mode if
> I mount the harddisk and try to remove a package using pkgrm -R <mntpt>
> it crashes somewhere in libspmi. I did not have the time or patience to
> fully debug it so I used a slightly older version in BeleniX.
I could do relatest tests in case I get more information about the constraints.
BTW: if you like to test the SVR4 packaging, you could try a test install with
the current Schillix-ON base packages:
the complete compile results from ONNV (SchilliX-ON) can now be installed
directly from the net with just a shell script that loops over pkgadd.
Find a Solaris x86 machine.
load:
http://download.berlios.de/schillix-on/packages/npkginstall
http://download.berlios.de/schillix-on/packages/pkglist.i386
http://download.berlios.de/schillix-on/packages/xz.i386
install xz.i386 either as /usr/bin/xz or as /opt/schily/bin/xz
Create an empty directory (with at least 500 MB of free space) and chdir
into that directory.
Call as root in the global zone:
path-to/npkginstall -rm -dest . <path-to/pkglist.i386>
My test results are:
8 Minutes when doing the install test on a FOKUS local machine
9-10 Minutes when doing the install test at home from VDSL
I would be inerested in the timing from India....
This should also work on Solaris 10 ;-)
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily