Hello Rony, Glad to hear it was useful to you. If you need any further help, just ask away.
About your questions: 1) Usually 32-bit packages are separate and named as such according to the machine architecture they're intended for. The "Architecture" tag is different on the RPM file to indicate where it should be installed. For instance, you can have a MozillaFirefox-36.0-1.i586.rpm package and a MozillaFirefox-36.0-1.x86_64.rpm. These CANNOT co-exist on the same machine. You must install the appropriate one for the machine architecture. You may also see cases where there are 32-bit VERSIONS of libraries under 64-bit systems. These are intended to run 32-bit code on 64-bit systems only. They may co-exist on the same machine. Example: libusb-1_0-0-1.0.19-2.1.2.x86_64 libusb-1_0-0-32bit-1.0.19-2.1.2.x86_64 You can, however, create sub-packages from the same SPEC. But these are not meant to be multiple-architecture packages, only subsets of the files. For example, you can have an ooRexx and ooRexx-devel packages, one with the binaries, and the other with include files created from the same SPEC. 2) Yes, RPM offers a mechanism for dependencies. This is implemented via the "Requires:", "Conflicts:" and "Obsoletes:" tags found in the SPEC file. For each one, you may declare a either a package name, or a package name, an operator (=, <, >, >=, <=) and a version string. >>> "Rony G. Flatscher" <[email protected]> 25/06/15 12:45 >>> Dear Erico, thank you *very* much indeed for your information and pointers! In due time (in about two weeks, when things get a little bit calmer around here, ie. summer semester ends) I will try to read through in order to create an rpm installer for the DBus external function package for ooRexx. Maybe two little questions: * Should there be two different packages, one per 32-bit and one per 64-bit, or is it possible/advisable to create one package only that contains both, the 32- and the 64-bit libraries? * Can one check for dependencies (e.g. on a minimum ooRexx version) and if not installed have an automated installation of the prerequisite(s)? Again, thank you very much for your information! Cheers ---rony On 24.06.2015 06:22, Erico Mendonca wrote: > Hello Rony, > Sure, I can give you some pointers on RPM packaging. I've been doing that > daily for the last decade :) > > A good place to start is this neat little series of articles from IBM > DeveloperWorks: > > http://www.ibm.com/developerworks/linux/library/l-rpm1/index.html > > I also have a little 30-odd page basic RPM packaging tutorial I wrote for a > customer, I could maybe turn it into an article if you're interested. > > After you cut your teeth on the basics, SUSE's Build Service is a very good > resource on learning good practices. I usually say their checks are so damn > pedantic you'll come out hating the thing and being eternally grateful to it > at the end... :P > > http://build.opensuse.org > > > > It's free to use. You can inspect, clone any of the packages available and > tinker with them under your home directory. > > Here are some Build Service guidelines from the SUSE community: > https://en.opensuse.org/openSUSE:Build_Service_Tutorial > https://en.opensuse.org/openSUSE:Build_Service_cross_distribution_howto > > About your specific questions: > - RPM provides a set of macros that are common among distros. They should do > the trick for some of your problems, like %{_libdir} which should resolve to > "/usr/lib64" on 64-bit systems, and "/usr/lib" on 32-bit systems. %{_bindir} > resolves to "/usr/bin" usually. Also, the preferred placement for binary data > under Linux is "%{_datadir}/<program>", like "/usr/share/<program>. Check our > approach to this problem on ooRexx.spec: > > https://build.opensuse.org/package/view_file/devel:languages:misc/ooRexx/ooRexx.spec?expand=1 > > The macros are defined in the /usr/lib/rpm/macros file. SUSE defines a few > more useful macros to simplify some common tasks: > https://en.opensuse.org/openSUSE:Packaging_Conventions_RPM_Macros > > - RPMBuild (the one who interprets the SPEC file) uses a "mirrored" approach > when building a package. Basically, you have a "sandbox" where you must > create the desired directory tree, and place the files here as you would on a > real system, including symbolic links. It's called a "build root" > ($RPM_BUILD_ROOT). This process falls under the %install tag. All the files > which shall be included in the final package must be listed under the %files > tag. Whenever you install this package on a system, RPM keeps track of which > files are part of each package, and removes them automatically when you > remove the package. So, no need to remove them manually. > > - RPM offers many script hooks for each phase of installation and > uninstallation of the package: %pre, %post, %preun, %postun, etc. > > I hope I have been clear enough in the lines above. If you have any > questions, just mail me. > > > >>>> "Rony G. Flatscher" <[email protected]> 23/06/15 12:13 >>> > Hi Erico, > > On 23.06.2015 16:21, Erico Mendonca wrote: >> Don't forget: >> https://build.opensuse.org/package/show/home:PerryWerneck:pw3270/ooRexx >> >> and >> >> https://build.opensuse.org/package/show/devel:languages:misc/ooRexx >> >> Don't think it could be easily integrated with Jenkins, though. > interesting, thank you very much for this pointer! > > One question, seeing that you have been active and so supportive for ooRexx > packaging: what would be > involved for someone who has no clues (like me) how packaging works, to learn > exactly that: how to > package for Suse (and maybe for other Linux-based systems)? > > Currently, I have ooRexx scripts that do the installation that work along the > lines as follows: copy > the files to "/opt/someDirName", determine the ooRexx bitness and > symbolically link the appropriate > shared library to "/usr/lib". In addition, if there are executables link them > symbolically to > "/usr/bin". Uninstalling via the Rexx installation script does the same in > reverse order (remove the > symbolic links and finally the '/opt/someDirName'. > > What would be needed to achieve the same using Suse's packaging scheme, is > there some > nutshell/cookbook description/tutorial for that. > > The reason why I am asking is the preparation of a DBus-ooRexx library for > which such a Rexx > installation script exists. However, it would be much nicer would it be > possible to use the Suse > (and maybe the other distro's) package manager to install, update and remove > such a library. > (Eventually doing the same for BSF4ooRexx would be another intent.) > > Would you have any pointers, hints? > > TIA, > > ---rony > > ------------------------------------------------------------------------------ > Monitor 25 network devices or servers for free with OpManager! > OpManager is web-based network management software that monitors > network devices and physical & virtual servers, alerts via email & sms > for fault. Monitor 25 devices for free with no restriction. Download now > http://ad.doubleclick.net/ddm/clk/292181274;119417398;o > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
