I have some task to make linux's bootable image with my own package. This package (named starlet) is a set of .C modules + Makefile. I created the package/starlet directory and added Config.in and starlet.mk; selected in the Buildroot configuration to include my package to build target image.
So, it's works fine...
Now i'm need to build starlet's image with additional library from the zztop-dev package.
zztop-dev package is an .RPM package with set of .H and .C files to build target zztop.a (.so) libraries.
What do I need to do to install zztop-dev.RPM before building STARLET image?
Having the source code for a package stored in a .rpm file is quite uncommon. Buildroot has built-in rules to extract all the most common formats. Using an uncommon format requires you to write extraction rules on your own.
So the first question is whether you can use a more common format that Buildroot has rules for. You probably can access the source code from its original location in a source code repository (git, Subversion, whatever) or a tarball.
If you really need to extract the sources from am .rpm file, then you need to write your own custom extract commands. Look for LIBFOO_EXTRACT_CMDS in the Buildroot user manual.
But if your extract commands call the rpm command to do the extraction then you'll need the rpm tool either installed on your host machine, or packaged as a host package in Buildroot and listed as a dependency of zztop-dev. The former approach is way simpler, but it will force you to have rpm installed on every host machine where you run the build.
Related
I'm using autoconf & automake in a C project. I'd like to create a .deb package, so I have the following control.in file:
Source: myproject
Section: misc
Priority: optional
Maintainer: Paul Walker <pwalk#test.it>
Build-Depends: debhelper (>=9), autotools-dev#MORE_DEPENDENCIES#
Standards-Version: 1.0.0
Homepage: https://www.my-website.it/
...
I'd like to configure this file with autoconf since there might be MORE_DEPENDENCIES according to some configure-time flag I did set.
This control.in file sits in a stubs/ folder, after substituting the MORE_DEPENDENCIES variable, I'd also like to copy the resulting control file into the final destination folder debian/ to create the .deb package.
So essentially I'm trying to have autoconf do the following:
Include {srcdir}/stubs/ as input folder in order to substitute macros in the .in file sitting there
Configure the stub {srcdir}/stubs/control.in, substitute whatever macro is in there, generate the file {srcdir}/stubs/control with substituted macros
Copy {srcdir}/stubs/control into the final destination folder {srcdir}/debian/control
I've been looking for examples or in the official documentation but still can't find how to configure a .in file outside of the root source folder.
Regarding 'how to copy the final file to the debian/ folder' I suppose I could use a symlink ? Is there any better way?
This is a top-of-the-foodchain problem.
The Debian packaging tools are designed to be the top-level tool for building Debian packages, and the control file is supposed to stay unchanged for the entire run of a package build. You can probably fudge your way around that if you only wish to build binary packages, but then there would be no point in modifying the build dependencies because they are evaluated earlier.
The normal build process will distclean the build tree in order to record changes in the source package, then rerun configure and build. If you update debian/control at this point, the results are undefined.
If you have to update debian/control programmatically, use a separate mechanism that is not reachable from the regular package build. If you have regular releases rather than cutting packages from development versions, it might even make more sense to treat the packaging as separate.
I want to recompile a Ubuntu package to use it on Debian
https://launchpad.net/ubuntu/+source/hollywood
how can I do that please ? I'm a beginner
You need the original tar-ball for the package, and the "debian" tarball which contains the scripts and patches needed to build the package. Finding those on Ubuntu's website is really the hard part.
Given those, you could use dpkg-buildpackage (on a system comparable to your target, of course), which expects the latter untar'd in the current directory, along with the original tar-ball.
(I build my own packages with a script which stages things into this arrangement; Debian packagers use a different scheme).
I am little confused on how to create a complete binary package using rpmbuild from a project I just created (already compiled binary).
my current project contain similar format as this user (Packaging proprietary software for Linux)
Where I have
foo (binary)
data
libs
foo.sh
libs will contain all the shared libraries the project requires, and foo.sh is a script that sets LD_LIBRARY_PATH to include libs. Therefore, the user will execute foo.sh and the program should start.
I am looking at the tutorial from this site (rpm tutorial)
I understand to create a rpm I create a build area use rpmdev-setuptree
I can create a spec file use cd ~/rpmbuild/SPECS; rpmdev-newspec foo and if I got a good SOURCES folder I can build it with rpmbuild -ba foo.spec
But I have no idea how to setup the SOURCES directory. The tutorial stated (here) that I should create a tarball and place all my source file in it and put in SOURCE directory. What would be the source file in my case?
You are trying to create a RPM from binary files you have already? In that case, you can just leave the whole building stuff out of the SPEC file, and you need a SOURCE directory to keep the bundles you've got, the %prep step described below will take them from here.
In a binary package I built a while back from zip files, I did:
Heading, with name, version, description written by me/cribbed from the originals
Sources: The original places to download the Linux packages, official documentation, ...
%prep: Just unpack the different pieces, delete some redundant files, ...
%build: Nothing to do
%install: Create the relevant directories under $RPM_BUILD_ROOT by hand, copy files there by install, copy/create configuration files, ...
%clean: Blow away $RPM_BUILD_ROOT
%files: An exhaustive list of all files installed.
This required a few iterations to get right. Afterwards I followed the upstream package by rebuilding my RPM (conveniently I had everything packaged up in a SRPM, where the Source part was kind of a misnomer...)
Without packaging system we have (A) source code, which can be translated/compiled to (B) binary code.
In case of debian/ubuntu packages we have (1) source code, (2) source package - dsc file and (3) binary package - deb file. How is it that (2) source package related to (1) and (3)? Why do we need it? And, the most important question: what is the workflow generating (2) and (3) from (1)?
The workflow usually goes approximately like this:
Someone not affiliated with Debian writes some source code and posts it as a package on the web, for example, splint-3.1.2.tar.gz
Someone at Debian downloads the source code, and writes
A set of patch files to make the source build on Debian and conform to Debian guidelines. Run
curl -s 'http://archive.ubuntu.com/ubuntu/pool/universe/s/splint/splint_3.1.2.dfsg1-2.diff.gz' | gunzip -dc | less
to see this for the example package.
A textual metadata file describing the package—this is the .dsc file and debian/control file. “DSC” is an acronym for Debian Source Control.
Binary .deb packages are built for each architecture from the original upstream source code with the Debian-specific patches applied. Here is one such file. The Debian Binary Package Building HOWTO explains the format of these files and how to inspect them.
The .dsc file is not used for build logic, it is more for metadata. However many tools along the way require it. For example, the Build-Depends: field is used to install required build dependencies.
It's actually much more complicated than that. The idea behind Debian packages is that they contain all the information needed to buld a page. Usually, the source is modified to include a debian directory that includes a control file describing the dependencies of that package and other packages that it interacts with (e.g, breaks, replaces, provides virtual package). A rules file explains how to build and install the package. There are also descriptions of how to package since a single source package can become many binary packages (e.g., foo-utils, libfoo0, libfoo-dev). debuild actually reads this information, does the compilation, and produces the binary packages. A subtlety: if foo uses libbar-dev, I may not actually know/care what version of the libbar binary package I use. pbuilder runs debuild in a clean environment so there is no chance of compiling against things you have not explicitly specified.
Consult the Debian New Maintainers' Guide for details.
I need a non-stripped version of libpthread.so for debugging. How can I compile it from source code? Host is Linux 2.6.
If you're on an RPM based system, use rpm -qf .../libpthread.so to find out which package installed the file (if that doesn't produce a result, the .so file is probably a link; then run the command on the file the link points to).
If you have the package name, search for the "source package". How this works depends on the distribution you use. For openSUSE, you must add the Source Repository using Yast. After that, you can install the source package which will give you some entries under /usr/src/packages. To build the package, go to /usr/src/packages/SPECS and run rpmbuild with the pthread.spec file as parameter.
When the build suceeds, edit the .spec file and change it so it doesn't strip the symbols.
Alternatively, look if there is a *-debug package (replace "*" with the name of the package) and install that. It should contain the version of the library with the symbols.