Somewhat, possibly more flexible

Post #47,222 by kmself 7/27/02 5:52:28 PM 7/27/02 5:56:13 PM Reply	Somewhat, possibly more flexible Debian doesn't presume an unmetered 'Net connection, just access to a Debian archive. If that's a local mirror which you refresh via CD on a monthly basis, you're down to burn time, media, and shipping costs. If you can piggyback from an unmetered connection (eg: work ;-), you're set to rock. This issue [link\|http://lists.debian.org/debian-user/2002/debian-user-200207/msg01304.html\|turned up recently] on debian-user and prompted (among others) [link\|http://lists.debian.org/debian-user/2002/debian-user-200207/msg01565.html\|this response]. Gentoo seems to be interesting to a lot of people who've gotten sick of Red Hat's RPM dependency hell. It addresses library compatibility by requiring builds on all boxes, but doesn't address cross-package compatibility AFAIU. This is something that required [link\|http://www.debian.org/doc/debian-policy/\|policy] to address. -- Karsten M. Self [link\|mailto:kmself@ix.netcom.com\|kmself@ix.netcom.com] [link\|http://kmself.home.netcom.com/\|[link\|http://kmself.home.netcom.com/\|http://kmself.home.netcom.com/]] What part of "gestalt" don't you understand? [link\|http://twiki.iwethey.org/twiki/bin/view/Main/\|TWikIWETHEY] -- an experiment in collective intelligence. Stupidity. Whatever. Keep software free. Oppose the CBDTPA. Kill S.2048 dead. [link\|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html\|[link\|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html\|http://www.eff.org/...a_alert.html]] Edited by kmself July 27, 2002, 05:56:13 PM EDT Expand All History
Post #47,252 by deSitter 7/28/02 4:19:53 AM Reply	RPM Dependency Hell Well, the few times I've knowingly risked a dependency problem, it tended to happen and left stumps and nickmarks of half-assed installs, while if I stick to the implicit dependencies I'm all right. I'm somewhat in the dark about who maintains dependency lists. -drl
Post #47,253 by pwhysall 7/28/02 4:46:29 AM Reply	It's in the packages themselves A package declares dependencies on foo, bar, and baz. Then when you install it, rpm tries to find foo, bar and baz on your system. No findee, no install. Debian fixes this in two ways. One, there is a centralised package list that you download [Yes, I know about the rpmdb package for Red Hat]. The package list contains descriptions, contents and dependency information. Two, dpkg and its front end, apt, can auto-resolve dependencies in both directions (i.e. it'll remove unused dependencies when you uninstall stuff). That this does not happen in RPM-based distros is not the fault of rpm itself - the infrastructure is there to make it work. It's just that no distro (perhaps save Conectiva, which uses apt to manage its RPM packages) uses it. All the update stuff like urpmi (Mandrake) up2date (Red Hat) and so on are hacks on top. The other benefit Debian brings is some of the most rigorous QA work in the Linux world. Packages don't hit the package lists of stable or testing if they're borked - there's a reason the unstable branch is so named :-) I've seen some true horrors in RPM packaging. The two examples that spring immediately to mind are the Acrobat reader and Real Player. Both of which install into /usr/local. Now, that's just not on - but then, I can't think of an RPM-based distro that has a [link\|http://www.debian.org/doc/debian-policy/ch-opersys.html#s10.1\|policy] that says who /usr/local belongs to. Damn, yet another discussion of Linux with me turned into a Debian advocacy session. Shame :-) Peter [link\|http://www.debian.org\|Shill For Hire] [link\|http://www.kuro5hin.org\|There is no K5 Cabal] [link\|http://guildenstern.dyndns.org\|Blog]
Post #47,271 by a6l6e6x 7/28/02 1:13:59 PM Reply	Re:discussion of Linux with me turned into a Debian advocacy Well, it just might get me to try an install again but with new Debian release. :) Alex "Television: chewing gum for the eyes." -- Frank Lloyd Wright
Post #47,288 by Brandioch 7/28/02 5:55:55 PM Reply	This is a social issue, not a technological one. The technology is in place to automagically update dependencies. We could even go the Windows way and have the app install whatever libraries it needed in the directory said app was installed in. (very very bad idea) The "problem" that Linux has is that, by social convention, apps do NOT install the SHARED libraries they rely upon. (this is a very very good idea) But this results in the "problem" of the admin (if you're installing apps, you're an admin) having to find the version of the libraries that the new app desires. There's no technological problem with install an updated library. . .. ... .... ..... You just have to FIND what .rpm or .deb or whatever HAS the library you want. And THAT requires centralized databases listing the various libraries and which .rpm or .deb contains them (and the location to download them, ideally). This issue has to be solved by PEOPLE working with each distribution INDEPENDANTLY. If someone does the work for Red Hat, that information will not, reliably, be transferable to Debian. Personally, I don't see much of a "problem" here. Well, aside from the time it has taken the OTHER distributions to come around to Debian's way of handling this. :) If you're using a distribution, PAY THE PEOPLE for the SERVICE they're providing. And ONE of the services they NEED to provide is the centralized database. If you want to do it yourself, the technology makes it very easy. You just have to take the TIME to do it. What you're paying for in a distribution is someone else spending his/her TIME accomplishing this so you can type apt-get update Now, like most social constructs, this actually gets EASIER the more it is done (if done correctly). The people writing the apps will use the same system to update their developmental systems. Which means they will require the versions that are available on the centralized databases. Which means that YOU won't have to go hunting for anything. In conclusion..... Technology will NEVER solve a social issue -and- Not all "problems" are technological "problems" :) Personally, I'd like to see Red Hat offer their service for $20/year. Or $5 per mac address. Or something like that. They should break even selling the shrink wrapped boxes and manuals. They should focus on a recuring revenue stream from constant updates and such. $60/year/system is a little steep for most home users. Also, they need to look into leveraging their LUG's. $60/mac_address/year ($5/month) would be acceptable IF they I could build my own repository and drag that to the local LUG meetings for everyone else to update off of. We have the technology. We just have to work on the social aspects -and- Figure a way to make a profit while doing so. :) (okay, so this wandered a little bit. sue me.)
Post #47,260 by static 7/28/02 9:45:57 AM Reply	I was replying to a different concern. :-) I noticed very early on that Debian had addressed that particular problem (full marks) but GenToo hasn't. I actually asked point-blank and got confirmation that GenToo's whole design is predicated on an unmetered link. GenToo actually tries to solve a different problem: local software automatically installed from source, compiled to suit the hardware. In a way, it is harkening back to the days when Unix code was normally distributed as source code, which you then built (or patched then re-built) as needed. Debian's policy is formidable, I'll grant you that. But I have to date found it too large a leap from RedHat et al, as I have expounded upon before. Then too, with one exception, I have not had dependancy problems with RPM software that I couldn't properly solve. That one exception involved RedHat's dogged devotion to SendMail, when I can immediately think of four other SMTP servers that are easier to configure and maintain. Wade, who shall stop digressing now. "Ah. One of the difficult questions."

Welcome to IWETHEY!