Weekly Edition
Return to the Distributions page
| |||||||||||||
Distribution quotes of the week
My package made it into Debian-main because it looked innocuous enough; no
one noticed "locusts" in the dependency list.
-- xkcd
I like minimal server installs, a lot. --nobase tastes like candy to me. They don't get many updates, it's easy to read though what updates are needed. Easy to test that things won't break when there is an update. They're just lovely. If my wife had said no when I asked her to marry me, I'd have married a server with a minimal install.
-- Mike McGrathYes, I understand this is just reality, it's no ones fault but when I decide to take my minimal install and add something, I just want to add those packages and no more. So the sysadmin in me cringes when I try to install kvm, libvirt, and python-virtinst and see alsa-lib, libogg, and esound (among others) pulled in. As if this server will ever make a sound of any kind. (Log in to post comments)
Distribution quotes of the week Posted Sep 30, 2010 1:58 UTC (Thu) by ldarby (subscriber, #41318) [Link]
Haha, I use Slackware and laugh at your automated dependency resolution.
Distribution quotes of the week Posted Sep 30, 2010 16:52 UTC (Thu) by rvfh (subscriber, #31018) [Link]
So you compile all of it by hand?
Distribution quotes of the week Posted Oct 3, 2010 1:10 UTC (Sun) by dmag (subscriber, #17775) [Link]
> So you compile all of it by hand?
Yes, mostly.
I use Slackware too. For a complicated program (like ffmpeg), I might try to find slack binaries. (Every time you run into a technical complication, there's usually a business model behind it.)
But the vast majority of the time, I compile from scratch. It's not complicated: Just "./configure && make && make install" will work out of the box 95% of the time. The remaining 5% of the time, I might spend 10 minutes tracking down a handful of required libraries. I'm talking about fairly complex things like Lua, Ruby, PHP-FPM, node, postgres, mongodb, redis, etc.
Of course, I work mainly with CLI and daemon apps. I agree that most GUIs would be a nightmare to compile this way. For GUIs, I run Ubuntu.
Distribution quotes of the week Posted Oct 9, 2010 13:50 UTC (Sat) by nix (subscriber, #2304) [Link]
> fairly complex things like Lua
What? Lua is tiny and trim, and by design has *no* dependencies at all beyond ISO C: it doesn't even use regexes because that would require dragging in a regex matcher. (Some of the modules have more dependencies, but they're separate.)
USE flags alternative for binary distributions? none? Posted Sep 30, 2010 9:37 UTC (Thu) by amtota (guest, #4012) [Link]
The problem described is solved by source based distributions like Gentoo and its USE flags. Unfortunately, this is not suitable everywhere, and has its own management costs.
Some of my clients will simply not consider anything but RHEL or equivalent.
I really wished there were a similar solution for binary distros.
I guess you could have XXXpackage-3.4.5 and XXXpackage-minimal-3.4.5 and let the sysadmin choose between them. Not sure how well debs and rpms deal with virtual dependencies though, and that also introduces a large burden on the distributor to build those specific package versions, and some may want minimal+this-special-dependency... Not an easy problem to solve.
USE flags alternative for binary distributions? none? Posted Sep 30, 2010 10:49 UTC (Thu) by epa (subscriber, #39769) [Link]
Another way to solve the problem would be to load some libraries dynamically, that is, at run time. Then the dependencies could be relaxed so that the esound library is not needed; it wouldn't be loaded unless you had configured your KVM to make a bong sound for every virtualized disk access. (Yes, I'm completely making up this nonsense example.)
However, what about the user who does want sounds from their hypervisor? It would not be acceptable to install the package, relying on the package manager to make sure the dependencies are set up, and then get a runtime error because a library is missing. The answer is to have 'capability' packages which serve to pull in the necessary stuff. This doesn't mean building two versions of a program (there is a single build, with the runtime library loading mentioned above) but making empty packages which indicate the necessary dependencies.
For example the kvm-with-sound package depends on kvm, but also esound. Or, if the dependency chain is a bit longer, kvm-with-sound depends on X-server-with-sound, which in turn requires esound. But someone who just installed kvm wouldn't pull in any of that stuff.
In dynamic languages, perhaps, this is a bit easier to imagine than it would be for C programs, where we are used to choosing a fixed set of library requirements at compile time. Very often a Perl module, for example, will say something like 'if you want to use the optional http support, this library requires libwww-perl to be installed'. A Linux distribution packaging the library will include a hard dependency on libwww-perl, even though it is in fact not required for many uses. Better to make a virtual package Foo-with-http-support which pulls in the base Foo library and also libwww-perl.
Gentoo's USE flags control the required libraries at compile time. As you say, this has its own costs. I think a runtime approach would be easier to manage, at the cost of slightly more complexity.
USE flags alternative for binary distributions? none? Posted Sep 30, 2010 12:24 UTC (Thu) by i3839 (guest, #31386) [Link]
This lack of runtime library loading has bugged me for years, it's very
annoying.
USE flags alternative for binary distributions? none? Posted Sep 30, 2010 18:31 UTC (Thu) by elanthis (guest, #6227) [Link]
Unfortunately, developers are generally lazy. Myself included, in many instances. If it comes down to "easier way to code things" and "silencing a handful of picky users," developers are going to take the easy route, make any optional dependencies compile-time configuration instead of run-time, and never look back.
However, a part of this (I think) is that library developers (and the GNU toolchain) do not make it particularly easy to make a dependency a runtime component.
Imagine, for instance, if your ALSA code could look something like:
if (alsa_enabled()) {
No extra boilerplate. No dlopen() calls. No tables of function pointers. All of that crap hidden away for you automatically. At init time (before main even starts), the dependency libraries do their own dlopen()s and set up the function tables. You've got the *_enabled() functions just to check if the library was successfully opened.
With a bit more effort, you can even make the interface versioned, and be able to check if some particular version or higher was loaded, and switch your sets of function calls appropriately.
In other words, imagine if you had GLEW for all libraries instead of just OpenGL.
This would not be hard to build, I think. Some definition files (which can easily be automatically generated for simple libraries), a small bit of public domain loader code, and some updates to the linker(s) to mix in the loader code from the definitions instead of directly linking to the libraries if requested.
Without such a standardized system in place, it's up to the library developers to make this easier. Split your libraries into two: the dynamic part and a static loader/wrapper. Let your library's init function return some kind of E_NOTAVAILABLE message if the library can't be loaded. It's not difficult to build this kind of thing at all, especially if your library's API is already cleanly designed.
Application developers can implement their own wrappers, but it's not a smart approach to expect app developers to constantly implement and re-implement wrappers for libraries which are rarely hard-dependencies of a framework. Audio, for instance, is never 100% mission critical to any app that isn't explicitly and solely an audio-related app (like a sound recorder). Even in that case, codec libraries are almost never 100% mission critical, and those at least can be made optional.
USE flags alternative for binary distributions? none? Posted Oct 1, 2010 9:52 UTC (Fri) by epa (subscriber, #39769) [Link]
Yes, that's what I had in mind. Support for optional libraries must be automatic and just as easy as linking them in unconditionally. Otherwise it won't get used.
USE flags alternative for binary distributions? none? Posted Oct 1, 2010 12:23 UTC (Fri) by guus (subscriber, #41608) [Link]
It is not so hard to make it work exactly like you suggest.
One could take the header files of say ALSA, add __attribute__((weak)) to all function declarations, and turn all the declarations into empty functions. Except for alsa_enabled(), this function should try to dlopen() libalsa, and if succesful return true. A program that might want to use ALSA should #include these modified headers. The program will be compiled succesfully with only a slight increase in size due to the empty functions. When alsa_enabled() is called, and libalsa is available, the linker will overwrite all the weak entries in the symbol table with links to the real ALSA functions.
I have implemented such a scheme succesfully in the past.
USE flags alternative for binary distributions? none? Posted Oct 2, 2010 21:35 UTC (Sat) by jengelh (subscriber, #33263) [Link]
>Imagine, for instance, if your ALSA code could look something like:
> >if (alsa_enabled()) { >also_some_function(); >also_other_function(); >}
With the lazy resolving libdl defaults to, this is already possible I believe. The only real showstopper is that libasound.so.2 is listed as DT_NEEDED in the program's ELF headers. One needs to just remove that. If the program desired alsa at some point, it need only dlopen libasound with RTLD_GLOBAL. Oh and alsa_enabled() looks like
dlopen("libasound.so.2", RTLD_NOLOAD) != NULL;
USE flags alternative for binary distributions? none? Posted Oct 18, 2010 15:13 UTC (Mon) by i3839 (guest, #31386) [Link]
DT_NEEDED can be prevented with the --no-add-needed linker flag.
locusts Posted Oct 1, 2010 15:02 UTC (Fri) by ssam (subscriber, #46587) [Link] debian are taking action to prevent this happening again.mingetty (1.07-2) unstable; urgency=high * Critical security patch: Fix unsafe chroot call. (Closes: #597382) * Checked dependencies for locusts. (Closes: http://xkcd.com/797/) -- Paul Martin pm@debian.org Sat, 25 Sep 2010 01:51:12 +0100http://packages.debian.org/changelogs/pool/main/m/mingetty/mingetty_1.07-3/changelog#versionversion1.07-2 spotted by http://www.jwiltshire.org.uk/content/2010/09/30/locusts/
|
|||||||||||||