Mailing List Archive
tlug.jp Mailing List tlug archive tlug Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Re: [tlug] Well now I'm hosed - Dapper/Edgy died
- Date: Thu, 18 Jan 2007 14:05:40 +0900
- From: "Stephen J. Turnbull" <stephen@example.com>
- Subject: Re: [tlug] Well now I'm hosed - Dapper/Edgy died
- References: <7d27112b0701162207w4aeacb84v1d33976e44c40172@example.com> <45ADDC23.10504@example.com> <e28811080701170113k32d123f3x202010e79b6ef6f7@example.com> <45AE29A4.8060003@example.com> <20070117151936.97fb65b8.godwin.stewart@example.com>
Dave writes: > Dapper/Edgy died Undoubtedly Edgy Eft just molted, and is hibernating until spring arrives. Then you'll meet again. :-p Godwin Stewart writes: > Dave, I know this comment doesn't help you, but your current > predicament with circular dependencies is the main reason I cannot > abide package-based distros. The problem isn't packages, which can easily be source-oriented, as several have pointed out. It's dependencies themselves. What Lusers want is automation, and what they desperately want to avoid is thinking about their system(s).[1] Luser-oriented distros therefore *require* all prequisites for almost all features, and in practice don't really support "recommend" or "suggest". This requires careful testing to avoid deadlocks, because it turns out to be impossible in practice to avoid versioned prerequisites. Apparently it is the case that a small amount of testing will remove almost all deadlocks, because Luser-oriented distros never have easy ways to break them (at least not that are documented in the error messages delivered by package managers). This kind of setup is amenable to binary packages, which are also very attractive to Lusers because they're relatively fast to install. The problem, of course, is that if the automation fails, you're hosed; there's little support for non-distro-developers to resolve problems. AutoConfuse[tm] is basically a framework for implementing distros (eg, GNU itself) that are source-based, with a diametrically opposite approach to prequisites: if a prerequisite isn't present, then the relevant feature will not be available in the package as built. This is an excellent way for someone who wants to run a really tight ship to function, because configure scripts normally allow you to request features, and will stop and tell you to install prerequisites for requested features. At that point you decide whether to do this or to back off on the feature request. The problem with this approach (at the pure AutoConfuse level) is that things that really should be automated (eg, fetching and building prerequisite packages) aren't. What Debian (and its derivatives) are doing is to build more intelligent dependency analysis into the PMS. Unfortunately, they aren't building display features into it. (What I have in mind is gitk from the Git version control system.[2]) I'm not sure what Red Hat and Microsoft's Linux division do; I suspect that they have some analytical tools but mostly depend on careful testing against the release-in-progress. What Gentoo and the *BSDs do is to start from the AutoConfuse strategy and work forward, providing automatic download and build for prerequisite packages. Gentoo's portage is especially nice because the USE flag system allows you to specify general characteristics of the system that you want (eg, USE="-GNOME" to avoid the Generally Not Operable Multimedia Environment), in a config file for defaults while overriding them on the package install command line when you want. (It's possible to do this in many cases with the pkgsrc-style makefiles, but Gentoo makes it a *documented* feature.) I think this latter approach is more robust in general, except that the USE flag implementation isn't going to scale much farther as it is. (Too many use flags, too ill-defined, often not implemented in any given package.) The main thing that prevents this from being the obvious way to go is that it's not very compatible with binary packages, which is going to continue to be desirable for people with lower-end systems.[3] Footnotes: [1] N.B. This doesn't mean that Lusers are unintelligent or lazy; it is often a rational choice to be a Luser. For example, if you are bucho or torishimariyaku, it's atarimae. ;-) [2] Sad, isn't it? The kernel developers can work out those graphs in their heads; it's Lusers in dependency-deadlock that really need these tools. *Usually* "dpkg purge --force <erroring-package>" will work, but sometimes it's more complex than that. A visualization of the dependency graph would really help. [3] I gave a student with a 1.5GHz Celeron system and 256MB of RAM an Ubuntu live CD; it took 45 minutes just to start OOo's Write. She's suddenly not very eager to use Linux....
- References:
- [tlug] Well now I'm hosed - Dapper/Edgy died
- From: Dave Gutteridge
- Re: [tlug] Well now I'm hosed - Dapper/Edgy died
- From: Sigurd Urdahl
- Re: [tlug] Well now I'm hosed - Dapper/Edgy died
- From: Evan Monroig
- Re: [tlug] Well now I'm hosed - Dapper/Edgy died
- From: Dave M G
- Re: [tlug] Well now I'm hosed - Dapper/Edgy died
- From: Godwin Stewart
Home | Main Index | Thread Index
- Prev by Date: [tlug] Concerning circular dependencies in package based distros
- Next by Date: Re: To package or not to package (Was: [tlug] Well now I'm hosed - Dapper/Edgy died)
- Previous by thread: Re: [tlug] Well now I'm hosed - Dapper/Edgy died
- Next by thread: Re: [tlug] Well now I'm hosed - Dapper/Edgy died
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links