Building debian packages and package management with incremental modifications
 

I have no prior experience with building debian packages, but as a first point I would like to build source and binary packages for a few development tools that we plan to use at our office. We upgrade to the latest version from source, but I would like us to be able to move them between machines. The general mechanisms have become clear I think, but there are a few fine points that I need to understand better.

I would like to know how to proceed when two installations from source normally modify the same file by appending to it. For example, both gcc and gdb modify /usr/share/info/dir, which if I understand correctly is for the emacs info system. This is not critical for me, and I guess I can --force-overwrite during installation, but there can be other cases. May be some installation will desire to modify start-up scripts or something similar. Can debuild and friends capture such incremental changes? From what I understand it tracks changes on the directory and file level in a temporary location.

Another question I have is, what will happen during uninstall of packages that have overwritten the files of other packages during installation. Say by --force-overwrite. Are the conflicting files backed up, do they get restored from the old packages, do they get removed, or does dpkg refrain from proceeding any further? In light of the question from the previous paragraph, how can incremental modification to a common configuration file be rolled back during uninstall? What must be done when building the package? For example my /usr/share/info/dir file.

Any pointers or hints are welcome.

This is probably a good place to start: http://forums.debian.net/viewtopic.php?f=16&t=38976

Always backup your critical data.

Regards

Welcome to LQ.
Avoid that in the first place :
Different packages must have different versions for easy upgrade / downgrade.

In that way you will not overwrite any files.


*** All files will be deleted at uninstall,
and a new package will have to be installed to replace the files.
Overwriting : Not considered a correct install method.

-

Thanks. And thanks to both of you for responding.

I read the tutorials and know that overwriting files of other packages is not recommended (and even may be against the official policy if you plan to upload the package.) I understand that linux uses the file system as catalogue and files are used for isolation in the system.

But if software installations from source have to do incremental changes for the likes of /usr/share/info/dir, what do the package maintaners use to perform the changes? Understandably they may need to do more intelligent things when removing the package from the system if they append/insert inside "structured" files in this manner. Or do these files get explicitily filtered out when building the package archive?

# 4

1) I'd guess there is an easy way to exclude files in /usr/share/info/***.

2)
Besides that : You can still apply different version numbers to any package.
Example : g++-4.6 http://packages.debian.org/wheezy/g++-4.6
* The major version is "4.6.3", and the minor version / the build number is "14".
I.e. any new build must have a new build version :
In that way you can either upgrade or downgrade a package with # dpkg -i <?> :
No overwriting of any files / No conflicts at install.

-

In all honesty, I will have to dwell on this a bit. If I understand the naming scheme correctly, the name of the software is "g++-4.6", the version is "4.6.3". In other words, "g++-4.6" and "g++-4.5" are separate threads as far as dpkg is concerned, because the name strings don't match exactly. Then the developers have to place relationships in the control file of the package to say that g++-4.6 replaces g++-4.5.

Still, to summarize from the documents and from your answers:

1. If you need to change/add entries in shared structured files, don't. Place instructions for the actions that need to be performed manually after installation and let the user do the maintenance.
2. If you have to upgrade some system file with specific version (that is not available from packages), either state in the control file that you supercede the other packages and the package manager will remove them, or state in the control file that it is safe to overwrite the file, but do so at your own risk.

Correct me if I am wrong.
For 1, is it possible that "make install" computes some changes to configuration files by interrogating the environment? If so, what would the package do?
For 2, I wonder what happens when a package is uninstalled that has "replaced" files that are dependencies of other packages.

I will read the manuals to investigate this in all cases. I just put the questions here in case someone can quickly summarize what the limitations are.

And in principle, even if there are mechanisms for scripted actions after installation, it seems to me that you can never be sure what aspects debuild will capture, unless you are confident you know the install procedure. Unless you can tell debuild to perform the build in a separate directory, archive this directory and the makefile produced by configure, and run "make install" against the archive contents when you do "dpkg -i".

No. Not a good example.
You can have all versions of g++ (g++-4.4, g++-4.5, g++-4.6, g++-4.7)
installed at the same time. No conflicts.
They all use unique locations for <other files>.

My understanding was that your question was about a certain package.
I.e. one and only one package name. ( And basically the same version.)
Different build versions can then be selected from different build numbers.
Which is an easy thing to enter in the control file.

-

Yes, in that case it would be ok.

I meant conflicts from different packages. I was not clear enough.