In the project pandoc, Paths_pandoc is imported in Shared.hs. Paths_pandoc.hs is located in dist/build/autogen/. How is it generated and what does it do for pandoc.
It's a file that is generated by Cabal.
When you specify Data-files: in your .cabal file for your project, those files will be copied to a good location for "data files" on your system when you run cabal install. On Windows, this might be "C:\Program Files\Something" and on Linux it might be "/usr/share/something" (At least when you do a --system install).
Your code needs to know where the files were copied to, so Cabal generates that special module, which contains variables for the install paths that were used to copy the data files, so that your code can find the installed data files.
The module does also contain other information that Cabal provides for you, but the primary purpose of the module is what I just described.
See this blog post for more information.
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 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...)
In short: This question is basically about telling Linux to load the development version of the .so file for executables in the dev directory and the installed .so file for others.
In long: Imagine a shared library, let's call it libasdf.so. And imagine the following directories:
/home/user/asdf/lib: libasdf.so
/home/user/asdf/test: ... perform_test
/opt/asdf/lib: libasdf.so
/home/user/jkl: ... use_asdf
In other words, you have a development directory for your library (/home/user/asdf) and you have an installed copy of its previous stable version (/opt/asdf) and some other programs using it (/home/user/jkl).
My question is, how can I tell Linux, to load /home/user/asdf/lib/libasdf.so when executing /home/user/asdf/test/perform_test and to load /opt/asdf/lib/libasdf.so when executing /home/user/jkl/use_asdf? Note that, even though I specify the directory by -L during link, Linux uses other methods (for example /ect/ld.so.conf and $LD_LIBRARY_PATH) to find the .so file.
The reason I need such a thing is that, of course the executables in the development directory need to link with the latest version of the library, while the other programs, would want to use the stable version.
Putting ../lib in the library path doesn't seem like a secure idea, not to mention not completely correct since you can't run the test from a different directory.
One solution I thought about is to have perform_test link with libasdf-dev.so and upon install, copy libasdf-dev.so as libasdf.so and have others link with that. This solution has one problem though. Imagine the following additional directory:
/home/user/asdf/tool: ... use_asdf_too
Which gets installed to:
/opt/asdf/bin: use_asdf_too
In my solution, it is unknown what use_asdf_too should be linked against. If linked against libasdf.so, it wouldn't work properly if invoked from the dev directory and if linked against libasdf-dev.so, it wouldn't work properly if invoked from the installed location.
What can I do? How is this managed by other people?
Installed shared objects usually don't just end with ".so". Usually they also include their soname, such as libadsf.so.42.1. The .so file for development is typically a symlink to a fully-versioned filename. The linker will look for the .so file and resolve it to the full filename, and the loader will then load the fully-versioned library instead.
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.
My machine has lua-5.1.4 installed (from source) but does not have lua.pc. What is the development package to download for lua 5.1.4?
I am new to this myself, so please bear with me while I explain what is 'lua.pc'. If you think some of the information here is incorrect, please make full use of the edit button.
lua.pc or any file with pc for an extension is a file that goes into either /usr/local/lib/pkgconfig/ or /usr/lib/pkgconfig directories. It is a text file containing different fields such as Description etc., information that is used by the make install process. The default installation of lua does not install the lua.pc file. That is because it is the 'normal' package. However, the development package contains this file. The development package creates additional dynamic links (for shared libraries etc.) that are needed during installation of other software where these shared libraries may be dependencies. For more information, read here and here.
Update: lua.pc is present in the etc/ folder within the source tarball.
The lua.pc is in the source tarbal, in the etc folder