Weekly Edition
Return to the Distributions page
| |||||||||||||
Camp KDE: Using Slackware to investigate KDE 4The lack of automatic dependency resolution in Slackware's package management system is seen by some as a fatal problem for the distribution. But Vincent Batts came to Camp KDE to point out some advantages of Slackware's laissez faire attitude toward dependencies when testing a rapidly changing set of packages under development, like, for instance, the early state of KDE 4. The flexibility of being able to easily build packages based on the KDE source code and install them as needed, while being able to back out as problems arose made it easy for him to investigate the changes that came with KDE 4. ![[Vincent Batts]](/images/2011/campkde-batts-sm.jpg)
Batts said that when KDE 4.0 was released, he was firmly happy with 3.5, and not yet willing to switch. He was, however, curious about the new KDE world, and wanted to "see what I might be missing". In trying to check it out, he was regularly breaking his systems, which is a Linux user's right, he said, but that breakage led him to using Slackware to make it easier to manage his KDE 4 investigation. KDE 4 brought a lot of new dependencies, which he found much easier to manage with Slackware as opposed to a packaging system like RPM that does dependency handling. Slackware has a "simplicity in component handling and upgrades" that is lacking in other systems. You can use RPM and the --force option to install package without their dependencies, or to override other requirements, but it can lead to various problems that can be difficult to recover from. For Slackware, though, there is a "managed set of packages", with most dependencies already available in the base system, and "everything plays nicely together". That sounds like the situation with most distributions, but Batts pointed out some significant differences, as well. Slackware packages are not much more than a tarball and a shell script. There are no domain-specific languages and no "automagic" in the package management system. As he was building the KDE 4 code, if he ran into a dependency that he didn't have, he got the source, built it in the canonical way, and easily turned it into a Slackware package using the following commands:
$ make install DESTDIR=`pwd`/tmp
$ cd tmp
$ makepkg -l y ../pkg_name.tgz
$ sudo upgradpkg --reinstall ../pkg_name.tgz
One can also use explodepkg to unbundle the package, fix any problems in it, and then makepkg/upgradepkg to recreate and reinstall the package. In working with the early KDE 4 packages, Batts got "good at rendering systems useless", but was able to fairly easily return the system to a known state. It is one of the benefits of not having a dependency chain, he said, because you can try things out, then back them out as needed. To do that, Batts recommended having a local mirror or DVD of the Slackware release, then you can roll back any changes on a running system. From the top of the Slackware tree, a simple:
# upgradepkg --reinstall */*.t?z
will reinstall all of the packages from the release, overwriting any that
appear in the core set and have been changed. A
"slackpkg clean-system" will then remove any packages that
are not part of the core set, essentially resetting the system back to the
"just installed" state.
One of the attendees asked about how KDE was to work with as an upstream and Batts seemed to be pretty happy with the project. He likes that you can get tarballs of each of the major subparts of KDE without having to get a tarball for each individual program. For example the KDE education tarball has all of the applications that make up that piece (e.g. KStars, Marble) which one can then subdivide into Slackware packages as they are built if that's desirable. The dependencies have greatly increased with KDE 4, but "it is still pretty manageable", he said. One of the reasons that GNOME was removed from the Slackware core several releases ago was that the dependencies got out of hand: "Try to build GNOME from source, it will be instructive", he said. It was interesting to hear one of the oft-heard weaknesses of Slackware turned on its head in Batts's presentation. While dependency tracking and handling can be useful—very useful at times—there are times when it can just get in the way. When choosing a distribution to use, it may make sense to look at Slackware, especially for systems that will be undergoing rapid, pervasive changes. (Log in to post comments)
Camp KDE: Using Slackware to investigate KDE 4 Posted Apr 7, 2011 13:06 UTC (Thu) by mrshiny (subscriber, #4266) [Link]
So, basically, for people who are trying to make new packages, not having to play by the rules of package dependencies gives you a freedom to try things quickly, and if stuff is broken, you maybe don't have to care right away.
A bit like how since Javascript isn't strongly typed, if you haven't finished refactoring all the functions you can still try out some changes.
But when the time comes to make a real package for non-packagers to use, surely nobody else wants to go through this hassle.
Camp KDE: Using Slackware to investigate KDE 4 Posted Apr 7, 2011 23:25 UTC (Thu) by dag- (subscriber, #30207) [Link]
It's funny how he indicates that using --force can lead to problems one cannot easily recover from.
Well, without dependency tracking, you pretty much have the same problems as using --force all the time, only thing is that you don't know what problems you might have until you run into them.
It's like blindfolding, it gives you peace up to the moment you start walking around. As long as you don't hit anything, you're fine !
I guess he hates spending time doing proper packaging and prefers to debug those problems by himself. If that's what you like, great. Some people compile all their stuff with their own compile flags and they are happy with that. It doesn't mean it is a smart or pragmatic solution for anyone else.
Camp KDE: Using Slackware to investigate KDE 4 Posted Apr 7, 2011 23:41 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the way most packaging systems work is that if you stay within the system, things work fairly well, but if you only partially work outside the system you end up working not only against the technical problem, but also against the packaging system itself.
so if you are straying too far from the base, it can be easier to work completely without the packaging system than trying to work around it all the time (and especially, preventing it from being "helpful" in ways that break your system)
Camp KDE: Using Slackware to investigate KDE 4 Posted Apr 8, 2011 0:31 UTC (Fri) by magila (subscriber, #49627) [Link] FWIW I've found that the Paludis package manager used with Exherbo/Gentoo is pretty good at allowing the kind of experimentation described in the article. In particular via the "cave import" command.
Camp KDE: Using Slackware to investigate KDE 4 Posted Apr 11, 2011 10:27 UTC (Mon) by roblucid (subscriber, #48964) [Link]
Yep. I've recovered RPM based systems using the chroot environment using a different distro's Live CD, which I just had to hand. I think it was glibc & ldd which I managed to screw up. Usually when ppl claim something is hard to do with rpm(8), it's because they couldn't understand the man page or lacked the stamina to find the right piece.
openSUSE supported installing both KDE3 & KDE4, thought it was best to experiment with KDE4 under a different username to avoid trouble going back to KDE 3.5, which the packaging without dependency solution also fails to address.
|
|||||||||||||