9

What I've done so far

  • I downloaded the source of an official deb-package from the ubuntu-repositories.
  • I applied a patch.
  • Ran configure and make successfully.
  • Tested the program.

What I'd like to do

  • I'd like to create a deb package from that using all the information (dependencies etc) from the old package.

My question is (They are closely related)

  1. Is there an easy (=mostly automated) way to do that?
  2. Can I just copy the binaries into the old deb file?
  3. Will my changes be overwritten once the original package gets updated in the repos?
  4. If so, how to avoid that?
  5. Is there a way to mark it as an "alternative" version that satisfies all the "incoming" dependencies of the original package?

Additional info

  • I run Ubuntu 9.04, 32bit, I do not care about others archs/versions at the moment.
  • The package in question is compiz-gnome.
  • The change is very minor and doesn't add any dependencies.
3
  • The questions are clearly so closely related, that a seperate discussion of each of them would not make sense.
    – Kim
    Aug 18, 2009 at 13:32
  • Edited question as suggested.
    – Kim
    Aug 18, 2009 at 13:33
  • + 1 Nice question
    – joe
    Aug 18, 2009 at 13:38

5 Answers 5

3

I found the following guide on the Ubuntu forums for rebuilding the network manager package here

Re: how to patch the source of a deb

Quote: Originally Posted by cord

I want to basically rebuild the network manager package with a custom patch of sorts to test something. So I want to: 1. get the source code for the ubuntu "version" of network manager

Code:

sudo apt-get source network-manager

Quote: 2. patch it with my patch The source files will be downloaded to the working directory. See this for more information.

Quote: 3. make a deb file that I can install in place of the current network manager.

Execute Code:

dpkg-buildpackage -rfakeroot -uc -b
in the directory created.

Also found this article : Debian New Maintainers' Guide Chapter 6 - Building the package


As for your changes being lost by an update from the official repositories I'm not sure. You could always just send your patch back upstream to the compiz-gnome package maintainers or create your own repository for the updated package.

2
  • 2
    One way to avoid getting your private package clobbered is to add an entry to the top of debian/changelog with a higher version number, then build your package. Aug 18, 2009 at 14:06
  • 1
    The patch will in all likelyhood not be accepted upstream, since it has been available for quite some time now. Creating my own repo seems overkill for the 20-lines change. Maybe I'll just try and see what happens. Thanks for your answer.
    – Kim
    Aug 18, 2009 at 14:08
5

The procedure I use is this:

Get the source (via apt-get src).

Apply a patch, or do whatever needs changing.

run debchange --nmu and type in a description of the change you made. This will auto-incremement the version number so that the system will not try to "upgrade" your custom package back to the standard one.

Run debuild.

Enjoy your deb files.

4

If you download sources from official site, than there should be package itself available via apt. So you cat just download ready package, modify it and pack again:

apt-get download your_package
dpkg -x your_package_vesion.deb your_package_folder/
... making changes in your_package_folder/ ...
# extract all needed controles/scripts from existing deb to new
dpkg -e your_package_vesion.deb your_package_folder/DEBIAN
dpkg -b your_package_folder/ new_package_vesion.deb

Source with details: http://sysadm.pp.ua/linux/deb-creation-edit.html

3

The answer to #3 and #4 is that you should put the package in hold status once you've installed your version. This tells the Debian package management system to "hold" any future changes to this package, in effect lets you manage the package manually.

From the Debian FAQ:

7.11 What is meant by unknown, install, remove, purge and hold in the package status?

These "want" flags tell what the user wanted to do with a package (as indicated either by the user's actions in the "Select" section of dselect, or by the user's direct invocations of dpkg).

Their meanings are:

  • unknown - the user has never indicated whether he wants the package>

  • install - the user wants the package installed or upgraded

  • remove - the user wants the package removed, but does not want to remove any existing configuration files.

  • purge - the user wants the package to be removed completely, including its >configuration files.

  • hold - the user wants this package not to be processed, i.e., he wants to keep the >current version with the current status whatever that is.

7.12 How do I put a package on hold?

There are three ways of holding back packages, with dpkg, aptitude or with dselect.

With dpkg, you have to export the list of package selections, with:

dpkg --get-selections * > selections.txt

Then edit the resulting file selections.txt, change the line containing the package you wish to hold, e.g. libc6, from this:

libc6 install

to this:

libc6 hold

Save the file, and reload it into dpkg database with:

dpkg --set-selections < selections.txt

With aptitude, you can hold a package using

aptitude hold package_name

and remove the hold with

aptitude unhold package_name

With dselect, you have to enter the [S]elect screen, find the package you wish to hold in >its present state, and press the =' key (or H'). The changes will go live immediately >after you exit the [S]elect screen.

Note: People have found issues with the aptitude hold command, so imho you should prefer the dpkg command to hold the package. Alternatively, you could hold the package via the Synaptic package manager GUI interface (Package > Lock Version). My preference is to use dpkg because it has worked well for me.

You already have a good answer for the rest so I'll not venture my opinion on those.

1
  • Thanks for the additional info! I think I have everything covered now. :)
    – Kim
    Aug 18, 2009 at 18:17
0

Well, it comes down to recompilation. If you don't want a full debian approved package creation environment (the right way)I've tended to use checkinstall for quick and dirty package creation (the easy way) - its not the debian recommended way, but its a lot simpler than the other way. configure then make, and substitute makeinstall with checkinstall. Then install your new package with sudo dpkg -i

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .