LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Debian
User Name
Password
Debian This forum is for the discussion of Debian Linux.

Notices

Reply
 
Search this Thread
Old 01-09-2013, 07:06 AM   #1
simeon_z
LQ Newbie
 
Registered: Jan 2013
Posts: 9

Rep: Reputation: Disabled
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.
 
Old 01-10-2013, 12:20 AM   #2
ukiuki
Senior Member
 
Registered: May 2010
Location: Planet Earth
Distribution: Debian
Posts: 1,027

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

Quote:
Originally Posted by simeon_z View Post
...configuration file be rolled back during uninstall?...
Always backup your critical data.

Regards

Last edited by ukiuki; 01-10-2013 at 01:10 AM.
 
Old 01-10-2013, 12:51 AM   #3
knudfl
LQ 5k Club
 
Registered: Jan 2008
Location: Copenhagen, DK
Distribution: pclos2014, Slack14.1 DebWheezy, +50+ other Linux OS, for test only.
Posts: 13,543

Rep: Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509
Welcome to LQ.
Quote:
what will happen during uninstall of packages that have overwritten
the files of other packages during installation. Say by --force-overwrite.
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.

-
 
Old 01-10-2013, 04:41 AM   #4
simeon_z
LQ Newbie
 
Registered: Jan 2013
Posts: 9

Original Poster
Rep: Reputation: Disabled
Quote:
Welcome to LQ.
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?
 
Old 01-10-2013, 04:59 AM   #5
knudfl
LQ 5k Club
 
Registered: Jan 2008
Location: Copenhagen, DK
Distribution: pclos2014, Slack14.1 DebWheezy, +50+ other Linux OS, for test only.
Posts: 13,543

Rep: Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509
# 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.

-
 
Old 01-10-2013, 07:00 AM   #6
simeon_z
LQ Newbie
 
Registered: Jan 2013
Posts: 9

Original Poster
Rep: Reputation: Disabled
Quote:
In that way you can either upgrade or downgrade a package with # dpkg -i <?>
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".
 
Old 01-10-2013, 10:51 AM   #7
knudfl
LQ 5k Club
 
Registered: Jan 2008
Location: Copenhagen, DK
Distribution: pclos2014, Slack14.1 DebWheezy, +50+ other Linux OS, for test only.
Posts: 13,543

Rep: Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509Reputation: 2509
Quote:
Then the developers have to place relationships in the control file
of the package to say that g++-4.6 replaces g++-4.5
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.

-
 
Old 01-10-2013, 11:42 AM   #8
simeon_z
LQ Newbie
 
Registered: Jan 2013
Posts: 9

Original Poster
Rep: Reputation: Disabled
Quote:
They all use unique locations for <other files>.
Yes, in that case it would be ok.

Quote:
My understanding was that your question was about a certain package.
I meant conflicts from different packages. I was not clear enough.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Request for help on Debian package management system. rupeshforu Linux - Newbie 1 12-23-2012 09:57 PM
How Debian package management works MTK358 Linux - General 11 06-29-2010 02:00 PM
Package Management tool doesn't see installed packages (FC1) pekkerhed Fedora 5 06-04-2004 03:56 PM
building optimized deb-src packages (debian/rules) Rounan Debian 1 02-17-2004 12:03 PM
Debian package management markus1982 Linux - Distributions 12 02-16-2003 06:44 AM


All times are GMT -5. The time now is 06:01 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration