A binary package-based system with own patches?

I’m increasingly getting an urge to expanding my hackings into other parts of kde, as to actually fix the small things that annoy me myself. There is only one problem though; I am very happy with the updated packages the kubuntu team supplies, and especially with my small laptop being my only available system, keeping a constantly complete self-compiled environment is something I don’t want to do.

So I’m wondering, maybe there is a middleway? Maybe there is a way I can for example get the source for the plasma package, hackety-hack up a small feature patch, send the patch off to review, commiting and whatnot, and while all this is happening, be able to keep these few patches in my own system easily, even with all the other parts of the system being based on packages.

For the apps that I regularly hack on (ark and kiten) I actually have placed empty placeholder packages in the system and compile them myself, but for larger system packages I also want the various improvements and settings that the packagers supply. So what say you, planeteers? Are any of you keeping custom patches on your package-based system? (source-based distros do not count)


19 Responses to “A binary package-based system with own patches?”

  1. Roberto Alsina Says:

    That’s almost trivial with Arch Linux.

    Yes, you would need a patched PKGBUILD for the specific patched packages you want, but it’s probably the simplest packaging standard for linux.

  2. Trever Fischer Says:

    I just adjust my LD_LIBRARY_PATH, KDEDIRS, PATH, and other variables to point to /opt/ in my .zshrc. Then I install things there. For example, I’ve got KDE4 built daily by kde-svn in /opt/kde4. My system still has the normal fedora KDE4 packages which supply any missing modules I don’t compile.

  3. Jonathan Thomas Says:

    It’s quite easy with Kubuntu too. You can get the latest Kubuntu packaging with “apt-get source packagename”. This will download the source package that the app lives in. These are divided by kde module (kdegraphics, kdemultimedia, etc)

    The Kubuntu and Debian packages use the quilt patch system for patch management. Here’s a quick how-to for adding your patch to quilt:

    ln -s debian/patches patches (This makes it easier to apply patches at the top level)

    quilt pop -a (apply all current patches)

    quilt new add_ark_mindreading_support.diff (Create a new quilt patch)

    quilt add affectedfiles (add the files affected by your patch here)

    patch -p0 < yourpatch (Now you actually patch the files)

    quilt refresh (This generates the patch by automagic)
    quilt pop -a (This unapplies all patches, including your new one)

    remove the symlink you created in your first step, and you should be ready to build your package.

    To do that, install the devscripts package and do the following in the root of the source tree:

    debuild -us -uc

    That will build unsigned packages for that kde module, which you can then install with dpkg.

    If you need to modify your patches, just follow up to the quilt pop -a stage and you can work directly in the source tree.

  4. Jonathan Thomas Says:

    Er, that first quilt pop -a should be a quilt push -a.

  5. AhmedG Says:

    Yeah, I have to agree Arch really shines when it comes to mixing self-compiled packages with binary-repo packages. But the steps Jonathan gave are the next best thing. You might want to put that into a quick pyqt app if you have a limited set of things you do.

  6. Simon Schmeißer Says:

    You might want to give openSuse a try. They a system called BuildService where you can sign up, create a private repository and then link in other packages plus your personal patch. Whenever something about the base package changes your private package will automatically get rebuild (on their server). You just have to add that repo to your yast/yum/smart/apt-rpm and be happy. There is even a svn-like commandline tool for uploading patches, so you don’t need to use the website at all.

  7. Jakob Petsovits Says:

    @Jonathan Thomas: That’s a cool howto, I hope it’s easy to find this on the Kubuntu wiki too 😉

  8. Oded Says:

    i regularly rebuild packages for my needs on my systems – as Jonathan said this can be really easy. I personally never got the hang of Debian/Ubuntu build system, but on rpm based systems its rather easy (maybe not as easy as quilt, which looks pretty cool):
    – get your own source tree and edit it as you like
    – you can build the binaries and test them by installing to ~/.local or something.
    – when youre happy, make clean then get the source rpm for the package you want to change and install it (as a user, in your own rpm build tree)
    – rpm -bp SPECS/package.spec
    – diff -u BUILD/packagename-version your-source-tree > SOURCES/your-patch-file.patch
    – edit the SPECS/package.spec to add your spec file
    – rpm -ba SPECS/package.spec
    – install the resulting package.

    Of course, with all packaging systems you have to redo the process when a new upstream package is made available.

  9. Will Stephenson Says:

    Simon is right – here are a few additional details.

    Overview: http://en.opensuse.org/Build_Service

    * You can build .debs for a range of recent distros as well as RPMs there.
    * You can maintain your modified packages in a personal project
    * You can use a simple XML file to insert patches to an ‘upstream’ package (http://en.opensuse.org/Build_Service/Tips_and_Tricks#_link_and__aggregate)
    * Or you can directly edit the specfile and its deb equivalents; changes are stored as a diff
    * Since you’re only making changes relative to an upstream package, your packages are automatically synced with changes to the upstream packages
    * Dependent packages in your repo are also rebuilt

    For example, I maintain a small project of KDE 4.1 and 4.2 packages built in debug mode, so I get kDebug output from users who have problems. It’s a single line change to our kde4-filesystem package to not build in release mode, but it causes kdelibs and kdebase packages to be generated. If you register for a look-see, check out https://build.opensuse.org/project/show?project=home%3Awstephenson%3Akde4-kdebug

  10. Diego. Says:

    Like Oded I find comfortable with Fedora “custom packages” management. You have your “rmpbuild” folder where all your experimentations are kept. You can easily retrive any src.rpm from Fedora Package Database / Koji:
    When you have the src.rpm (you can also download it with yumdownloader) you just have to “rpm -Uvh” it, add your patch, modify the .spec and “rpmbuild -ba”.

    N.B.: “rpm -ba” doesn’t work anymore, the command is “rpmbuild -ba”.

  11. Lure Says:

    Just adding to Jonathan Thomas’s comment: you can also use Ubuntu’s PPA to perform the build for you. Side effect of using PPA is that you can share your improvements with other Kubuntu users that may be interested.

    More info is here:

  12. sandsmark Says:

    I third the archlinux recommendation (and smile a bit at Jonathan’s “simple” guide :p).

  13. Khashayar Says:

    +1 for PPA. It’s easy as pie.

  14. Peter Says:

    The rpath/rbuilder/conary based distributions are designed around that problem space:



    sadly I haven’t found the time to really plunge into Weasel. http://www.weasel.iz.rs/

  15. mike Says:


  16. Manabu Says:

    You can do that relatively easy with Zero-install (see the link in my nick).

    The problem is that there is no kde feeds for zero install yet. You would need to do at least the feeds for the program that you are modifying and for all the programs that depends uppon that one (because system packages can’t depend upon zero-install packages, but zero-install packages can depend uppon system packages).

    There is deb2zero that automaticaly gets an binary debian package and transforms it in an zero install feed. But it don’t have yet any apt-like routine to parse all the dependencies, so you will have to make that manualy, one at a time, like in slackware. But don’t mis-understand: zero install has dependency solving for it’s feeds, but not in the creation step (well, no package system has that).

    Well, if you really came so far, it is very easy to pach any of these programs, have multiple versions of the same program running at the same time, rollback to an previous version, publish your modified binary for others quickly to test, etc. The problem is realy the lack of pre-made zero-install feeds.

  17. Manabu Says:

    PS: some programs may not have two versions run simultaneously (plasma may be one of those). But you can still have multiple conflicting versions “instaled” (cached).

  18. G2g591 Says:

    Arch has something vaguely similer to PPAs , its called AUR and it is widely used (as opposed to PPA’s which , a few months ago when I used buntu), anyone can upload their own package

  19. sunshine-fl-Tutoring Says:

    I’m very pleased to find this web site. I want too to thank you for ones time for this
    fantastic read!! I definitely really likedd every bit of
    it and i also have you book marked to look at new things iin youir

Comments are closed.

%d bloggers like this: