| |||||||||||||
Partially distributed distributionsPartially distributed distributionsPosted Feb 8, 2008 18:44 UTC (Fri) by JLCdjinn (guest, #1905)Parent article: LCA: Disintermediating distributions
Over the past two weeks, I have periodically encountered a crashing bug in VIM. I am running Kubuntu 7.10, and I run the update manager whenever it indicates that there is a pending update. This is a specific case of a general problem. There are many situations in which I would like to manually maintain the artifacts of a package on my system. I might want to do this in order to fine tune a package, such as the Linux kernel; when I want to test a bug fix, such as with KDE as described by Richard_J_Neill above; or when I want to actively develop a particular piece of software in the context of my overall system. Certainly, these cases are far from mutually exclusive. In order to do this cleanly, I need support from the distribution. I need a way to flip a switch in the package management system, which would tell the distribution that I will provide the dependencies filled by a particular package. I need the distribution to provide me with sufficient information that I can faithfully fill those dependencies. And then I need a way to relinquish control to the distribution, when I no longer need to closely control a particular package. It would be great if I could link any findings to both a distribution issue tracking system as well as any upstream issue tracking system. To what degree do distributions provide this functionality now? How much documentation about this functionality exists? For example, on Debian- or Ubuntu-based distributions, how could I install a custom Linux kernel without getting in the way of the package management system? Having this ability might help us move in the direction suggested by Mr. Waugh, if I understand his intent.
(Log in to post comments)
Partially distributed distributions Posted Feb 8, 2008 22:03 UTC (Fri) by magnus (subscriber, #34778) [Link] I wish there was a "get source" command in the package manager, that would download the source for a package configured exactly the same way as the installed package was configured. The package would be flagged as "customized" in the package database. You could then experiment with different patches, code changes etc and when you're done either revert back to the original package or keep your custom changes. It could also support automatically generating patches to send to the distributor or upstream (in case you managed to fix a bug), creating custom binary packages etc. I think something like that would help a lot to reduce the barrier between users and developers. Does any distribution already have such a system?
Partially distributed distributions Posted Feb 9, 2008 1:59 UTC (Sat) by tzafrir (subscriber, #11501) [Link] 'apt-get source' has been here for a while. Debian also has now 'debcheckout', but this is more for the package maintainer's version control system. You can certainly build your own package and install it. apt considers also locally-installed packages.
Partially distributed distributions Posted Feb 9, 2008 14:49 UTC (Sat) by alextingle (guest, #20593) [Link] $ apt-get source PACKAGE $ sudo apt-get build-dep PACKAGEThen, once you've made your change / applied the patch / whatever... $ dpkg-buildpackage -rfakeroot -b...and hey-presto, your very own fixed package.
Partially distributed distributions Posted Feb 10, 2008 15:55 UTC (Sun) by Lennie (subscriber, #49641) [Link] Also you can use apt-pinning to get a newer version for Debian (Ubuntu ?) testing or even experimental. If you add the other 'version' of the distribution (like Debian testing) to your /etc/apt/sources.list and specify which package you want to upgrade in /etc/apt/preferences (that's the pinning-part). It will automatically upgrade any dependencies as well. This way you can test a newer version and even go back to the distrbution original version from for example Debian-stable very easily. If you created a patch for a package (if you did the apt-get source, dpkg-source -x; dpkg-buildpackage), don't forget to change the version-number in the debian/control file, tag your initial or organisation at the end of the existing version number with a 1 or 2, etc. so you can upgrade the package later. And other way to upgrade a package is to add only the source lines to your /etc/apt/sources.list and do a apt-get source, dpkg-source, dpkg-buildpackage. You might need to change the debian/control-file to specify a different version number as dependency or install that first. On upgrade (apt-get -u dist-upgrade) or even update of your distribution it will automatically upgrade your packages, etc. if needed.
Partially distributed distributions Posted Feb 10, 2008 16:03 UTC (Sun) by Lennie (subscriber, #49641) [Link] And I forgot to mention the apt-get build-dep command. Which will install the build-dependencies of the package.
apt-get build-dep: better than sliced bread? Posted Feb 22, 2008 7:24 UTC (Fri) by goaty (guest, #17783) [Link] Have you ever tried apt-get build-dep on a fresh install that doesn't have any build tools installed? It will pull in the entire build system: gcc, header files, everything, with one command! With a fast disk and a fast network it is insanely pleasurable. Kids growing up in the Age of APT may never realise that building stuff used to be *hard*. It's lucky there are other operating systems around for them to use and understand what pain means.
Going upstream Posted Feb 9, 2008 2:00 UTC (Sat) by JoeBuck (subscriber, #2330) [Link] For relatively simple, self-contained programs that you invoke from a terminal, it's not hard to experiment with upstream versions. The key point is that the familiar (at least to developers) configure, make, make install sequence installs programs into /usr/local by default, which is an area that distros don't touch. Alternatively, you can built it in a special place, to make it easy to blow away whenever your distro fixes the problem.So, if you want the upstream vim, download the source tarball, and do tar jxf vim-7.1.tar.bz2 cd vim71 ./configure --prefix=/usr/local/vim71 make sudo make install You now have built the upstream vim and installed it in /usr/local/vim71/bin, without disturbing your distro's vim. (You will of course need to have the appropriate development tools installed).
Partially distributed distributions Posted Feb 17, 2008 21:48 UTC (Sun) by muwlgr (guest, #35359) [Link] Of course you could build your own kernel, pack it into proper .deb file and install it by dpkg. Just run "aptitude install kernel-package", then "man make-kpkg".
|
|||||||||||||