Re: When stability is pointless
Sam Kuper wrote: With apologies for cross-posting. Dear all, I have copied below the text of a blog post* I wrote a few minutes ago, because it addresses an issue in Debian and Debian-derived distros that I've encountered several times, and which no doubt many people encounter frequently. If you want Windows, Red Hat or Ubuntu, you know where to find them. For those of us living in the real world, there's Debian. signature.asc Description: OpenPGP digital signature
Re: When stability is pointless
Sam Kuper [EMAIL PROTECTED] writes: A number of comments missed my main point, which was: When 'stable' packages don't work, or are inadequately documented, it's a pain because the upstream developers (who are otherwise often the first port of call for help and documentation) may no longer support the version of the software that the stable package installs. I'm still missing your point here. The example you gave was _not_ of a stable package not working, it was a stable package that didn't conform to documentation for a *different* more recent version of the package. What you appear to want is for upstream developers or package maintainers to make sure that all the features of the latest release of a package are fully documented not only for that release, but also for previous releases. You seem to be overlooking the fact that _new_ features are _new_ exactly because they aren't present in _old_ versions of a program. So, unless there's some detail I've missed here, there already exist individual and community solutions to your problem - install it yourself from source, or make and share a backported .deb. Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
Dear all, I'm grateful for your comments on this thread. I've learned about a few parts of the Debian system I wasn't aware of before (volatile/sloppy) and have been pleased to see a range of perspectives, including from upstream of the distro. A number of comments missed my main point, which was: When 'stable' packages don't work, or are inadequately documented, it's a pain because the upstream developers (who are otherwise often the first port of call for help and documentation) may no longer support the version of the software that the stable package installs. It's this support/usability gap that I feel needs addressing in a more concerted way when distros take on the commitment of accepting a package. In my original post, I made some vague suggestions about how that might be done, and I'd ask any upstream or downstream maintainers reading this to consider their relationships with their counterparts, and whether modifications to the package acceptance/maintenance procedures might improve those relationships and mitigate the gap I've referred to. If so, I'd encourage you to propose those amendments to procedure, for the community's consideration. (And finally, I'm sorry to have taken so long replying - it's been a busy period for me...) Many thanks to all who've read or replied to this thread*, Sam *Aside from the troll Robert Caruso, who I hope for all our sakes has finally managed to spell unsubscribe and remove himself from the debian-user list.
Re: When stability is pointless
On Wed, Nov 12, 2008 at 12:13:42AM +, Sam Kuper wrote: When 'stable' packages don't work, or are inadequately documented, it's a pain because the upstream developers (who are otherwise often the first port of call for help and documentation) may no longer support the version of the software that the stable package installs. If a 'stable' package doesn't work, blame the upstream developer for releasing a non-working package. Whatever the problem, it wasn't considered 'release-critical' or it wouldn't have made it into stable in the first place. Those of us who run 'stable' run it because things don't change much. If you want more recent packages, run testing or unstable (or experimental if you want). Read the debian policy manual (package debian-policy). On a debian system, your first port-of-call for help is this the bug tracking system. There are various ways to access the list of bugs for a package. You can google site:lists.debian.org to see if the problem has alread been discussed, and if not, post a good question to this list. doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
On Wed, Nov 5, 2008 at 5:40 AM, Nate Duehr [EMAIL PROTECTED] wrote: It is very common for software developers to plow ahead without thinking much about the versions the distros provide. You may want to contact them and see how they would expect users to use their software effectively. It's likely: They won't care. I think that in may cases, this is an unfair characterisation. I'm biased though, I'm an upstream maintainer. I hardly ever hear from the distributions, despite the fact that the software I maintain is installed on over 99% of Linux machines (according to Debian popcon, about 99.8%). The sole exception is Debian (hi, Andreas!). I'm pretty sure the reason here is, once again, manpower. The distibutions include thousands of packages and so the staff who are paid to look after the distribution hardly have any time at all to interact with the upstream comunities, at least on average. The distributions need to figure out where to spend their staff time, and it unsurprisingly most of it goes on high-priority things like glibc, Apache, and the kernel, as you say. Regarding documentation though, I guess the situation is easier in my case; all the documentation that is available for findutils ships in the source tarball, so users always have access to a full set of documentation relevant to the software they are using (they may need to install a separate -doc package, but that's a whole other flamewar). James. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
On Wed, Nov 05, 2008 at 02:41:52AM +, Sam Kuper wrote: Hi Doug, Thanks for your comments. 2008/11/5 Douglas A. Tutty [EMAIL PROTECTED]: Or, are you saying that you are trying to implement a psad recipe from the internet that doesn't apply to the version of psad supplied in Ubuntu? Essentially correct. But not just any old set of psad instructions: the instructions provided on the psad website and in the developer's book on Linux firewalls. In other words, pretty much the most comprehensive set of instructions I could find. http://packages.ubuntu.com/psad http://packages.debian.org/psad And for older history: http://archive.debian.net/psad As you can see, the Ubuntu package is maintained by the Masters of the Universe. That is to say: it is basically a copy of the package from Debian Testing (or is it Unstable) close to the time of the release. For all Ubuntu is based on Debian, I don't think it follows debian policy. The policy manual says, basically and among other things, that installing a package should result in that package working out-of-the-box in some fashion only needing tweaking by the sysadmin. Define working (or tweaking). My experience with some packages in Etch suggest that Debian sometimes has problems like this too. Examples, please? Bug numbers? What I mostly expect the distribution to do for me are the manual script you find in HOWTOs. You should not need to install a set of packages. That is why we have dependencies. You should not need to guess a long command-line. If there is still a need for one it should be scripted by the package maintainer or at least documented in README.Debian . I have not heard of psad before. So I decided to just check that package and see what it is about. I didn't have time to actually set it up. One this that I could see in the README.Debian was that I need to edit syslog.conf myself. This makes sense if I use sysklod . But it's silly if I have a shiny new Lenny system with rsyslog. Result: http://bugs.debian.org/504567 . I hope somebody actually picks it up. Yes, this is a small thing. I could do it myself. But why should I bother? Why should the 362 users of the package (http://qa.debian.org/developer.php?popcon=psad ) bother do the same thing over? I've never used psad but I would be very surprised if the problem you experienced were to happen were you running Debian Stable. You may be right. Perhaps I should go back to Debian Stable. But one of the reasons I switched to Ubuntu was to minimise the gap between a package being deprecated by its developer and deprecated by its maintainer, in an effort to avoid precisely the sort of problem I outlined in my post. Since Ubuntu is based not on Debian Stable but on (I think) Unstable, I don't know how one can consider any Ubuntu release to be stable. Ubuntu has LTS (Long-Term Support) releases, which roughly translate to Stable. And they are released roughly as often as Debian stable versions are released. -- Tzafrir Cohen | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il || a Mutt's [EMAIL PROTECTED] || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
Johannes Wiedersich (2008-11-05 11:31 +0100) wrote: Sam Kuper wrote: Ubuntu has LTS (Long-Term Support) releases, which roughly translate to Stable. Yes, but IIRC it is still based on debian sid. Ie. it never transitioned debians unstable - testing - stable queue. IIRC it just means that the developers made a commitment to extend security support. (I hope someone will correct me, if I'm wrong) That's correct. Ubuntu's LTS (long-term support) releases are stable in the sense that they don't change and are supported (i.e., security and some bug fixes) for longer time than regular releases. In that sense they are roughly similar to Debian stable. But, as you said, Ubuntu's LTS releases are still based on Debian Sid and the development and testing process does not differ (in essence) from Ubuntu's regular releases. Perhaps they freeze a bit earlier but it's still tied to the 6-month cycle and not release when it's ready thinking. In that sense LTS releases are no more stable than any Ubuntu release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
Johannes Wiedersich wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Sam Kuper wrote: 2008/11/5 Douglas A. Tutty [EMAIL PROTECTED]: Or, are you saying that you are trying to implement a psad recipe from the internet that doesn't apply to the version of psad supplied in Ubuntu? Essentially correct. But not just any old set of psad instructions: the instructions provided on the psad website and in the developer's book on Linux firewalls. In other words, pretty much the most comprehensive set of instructions I could find. So what do you think that debian can do about it? For most packages I know, debian includes the correct version of the documentation. For git, as an example, the documentation at /usr/share/doc/ always corresponds to the version of git installed on the system and is upgraded along with git. (No need to search the web;-) ). Of course this is only possible, if the license of the documentation matches that of the software (ie. is free). If it is important for you for special cases, there is also backports.org from which you could install newer versions of certain software without compromising on stability for the rest of your system. For all Ubuntu is based on Debian, I don't think it follows debian policy. The policy manual says, basically and among other things, that installing a package should result in that package working out-of-the-box in some fashion only needing tweaking by the sysadmin. Define working (or tweaking). My experience with some packages in Etch suggest that Debian sometimes has problems like this too. Just report a bug and the problem has a chance to get fixed for lenny. I've never used psad but I would be very surprised if the problem you experienced were to happen were you running Debian Stable. You may be right. Perhaps I should go back to Debian Stable. But one of the reasons I switched to Ubuntu was to minimise the gap between a package being deprecated by its developer and deprecated by its maintainer, in an effort to avoid precisely the sort of problem I outlined in my post. I think this shows the point where you misunderstand how debian works: There are three levels any package can reach: - unstable/sid: frequently updated from upstream, latest software - testing: software has been tested some time and should contain less changes and bugs than unstable - stable: software has been extensively tested to work. It is rather unfrequently updated (about 1.5 years between releases) and hence you get a 'stable' system to work with. Pick whichever suits you. You obviously can't have stable software and frequent updates at the same time... It is also impossible to predict the right level of stability for everyone and for every package... ... or to predict which version of a package will be featured in a book or in some other documentation... ;-( Since Ubuntu is based not on Debian Stable but on (I think) Unstable, I don't know how one can consider any Ubuntu release to be stable. Ubuntu has LTS (Long-Term Support) releases, which roughly translate to Stable. Yes, but IIRC it is still based on debian sid. Ie. it never transitioned debians unstable - testing - stable queue. IIRC it just means that the developers made a commitment to extend security support. (I hope someone will correct me, if I'm wrong) Sorry to mix up in your discussion, but I hope sharing my experience will benefit you. I've been using debian since potato and must say that it has a genius versioning system. Actually there are 4 levels for packages, you've missed experimental. So I do use the stable version on my servers and the testing on my notebook or desktop. It works just great. I should admit that k/ubuntu has much better configurable or configured desktop settings, but being derived from unstable it has still problems, though the programmers/developers there swear that their software (k/ubuntu) is fine. I've tested kubuntu for over a month now and there are such small problems that finally broth me back to lenny for desktop. I think the ubuntu problem is really deriving it from unstable, but I hope they know what they are doing. From my point of view this is simply not relyable for production use I mean for getting a job done. I spent about 2 days to make it work for me and still there are some things that do not work like they should. So I don't see any difference between lenny (debian testing) and k/ubuntu. From my point of view debian testing has the advantage, that at some point in time it becomes stable which means that you can use this for other few years and don't have to change anything. If you miss a package, like I do with few packages, I download the code, compile, install, test, debug until it's working. then I make a deb package, install and forget about having troubles with it. It's just great. regards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject
Re: When stability is pointless
On Wed, Nov 05, 2008 at 12:58:15PM +0200, Teemu Likonen wrote: Johannes Wiedersich (2008-11-05 11:31 +0100) wrote: Sam Kuper wrote: Ubuntu has LTS (Long-Term Support) releases, which roughly translate to Stable. Yes, but IIRC it is still based on debian sid. Ie. it never transitioned debians unstable - testing - stable queue. IIRC it just means that the developers made a commitment to extend security support. (I hope someone will correct me, if I'm wrong) That's correct. Ubuntu's LTS (long-term support) releases are stable in the sense that they don't change and are supported (i.e., security and some bug fixes) for longer time than regular releases. In that sense they are roughly similar to Debian stable. But, as you said, Ubuntu's LTS releases are still based on Debian Sid and the development and testing process does not differ (in essence) from Ubuntu's regular releases. Perhaps they freeze a bit earlier but it's still tied to the 6-month cycle and not release when it's ready thinking. In that sense LTS releases are no more stable than any Ubuntu release. Hmm.. that is not entirely correct. Ubuntu has generally two sections with respect to quality: main and universe (multiverse is the universe of restricted). Packages in main are maitained by the Ubuntu developers. They should get security updates for the promised time (e.g: 18 monthes for a standard release, longer for a LTS version). Packages in the universe, such as psad, don't get that guarantee. Thus if you're in Ubuntu and want to keep a fully-supported system, keep universe out of your apt sources (or at least: avoid normally installing software from there). Just as you should avoid installing software from backports.org if you want a fully-supported Debian Stable system (though maybe non-free would be a better analogy). -- Tzafrir Cohen | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il || a Mutt's [EMAIL PROTECTED] || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Sam Kuper wrote: 2008/11/5 Douglas A. Tutty [EMAIL PROTECTED]: Or, are you saying that you are trying to implement a psad recipe from the internet that doesn't apply to the version of psad supplied in Ubuntu? Essentially correct. But not just any old set of psad instructions: the instructions provided on the psad website and in the developer's book on Linux firewalls. In other words, pretty much the most comprehensive set of instructions I could find. So what do you think that debian can do about it? For most packages I know, debian includes the correct version of the documentation. For git, as an example, the documentation at /usr/share/doc/ always corresponds to the version of git installed on the system and is upgraded along with git. (No need to search the web;-) ). Of course this is only possible, if the license of the documentation matches that of the software (ie. is free). If it is important for you for special cases, there is also backports.org from which you could install newer versions of certain software without compromising on stability for the rest of your system. For all Ubuntu is based on Debian, I don't think it follows debian policy. The policy manual says, basically and among other things, that installing a package should result in that package working out-of-the-box in some fashion only needing tweaking by the sysadmin. Define working (or tweaking). My experience with some packages in Etch suggest that Debian sometimes has problems like this too. Just report a bug and the problem has a chance to get fixed for lenny. I've never used psad but I would be very surprised if the problem you experienced were to happen were you running Debian Stable. You may be right. Perhaps I should go back to Debian Stable. But one of the reasons I switched to Ubuntu was to minimise the gap between a package being deprecated by its developer and deprecated by its maintainer, in an effort to avoid precisely the sort of problem I outlined in my post. I think this shows the point where you misunderstand how debian works: There are three levels any package can reach: - unstable/sid: frequently updated from upstream, latest software - testing: software has been tested some time and should contain less changes and bugs than unstable - stable: software has been extensively tested to work. It is rather unfrequently updated (about 1.5 years between releases) and hence you get a 'stable' system to work with. Pick whichever suits you. You obviously can't have stable software and frequent updates at the same time... It is also impossible to predict the right level of stability for everyone and for every package... ... or to predict which version of a package will be featured in a book or in some other documentation... ;-( Since Ubuntu is based not on Debian Stable but on (I think) Unstable, I don't know how one can consider any Ubuntu release to be stable. Ubuntu has LTS (Long-Term Support) releases, which roughly translate to Stable. Yes, but IIRC it is still based on debian sid. Ie. it never transitioned debians unstable - testing - stable queue. IIRC it just means that the developers made a commitment to extend security support. (I hope someone will correct me, if I'm wrong) HTH, Johannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkRddUACgkQC1NzPRl9qEUttwCfb9JuckVBEmb8oQpWnuXn7DnN TqwAn2tzxsMOQWRoRjkk4Pc50bf2u7lo =bU4g -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
Hi, On Wed, Nov 05, 2008 at 01:26:31AM +, Sam Kuper wrote: When stability is pointless === Many Linux distributions (and other software environments too) use package managers to facilitate the installation, upgrading and uninstallation of software packages as needed. At least, that's the idea. Debian acknowledges this problem and we have 2 special archives: volatile volatile-sloppy You do not seem to use these. Please check: http://people.debian.org/~osamu/pub/getwiki/html/ch03.en.html#debianarchivebasics http://www.debian.org/volatile/ (Also if you need new feature, backports.org is place to use.) Why have package managers? -- Are package managers necessary? Well, no. What We need this to keep consistency, ... One way of managing software is simply to install individual software programs/libraries as needed, and allow each item to handle its own updating or uninstallation (or even just leave that to the user to do manually). Within stable Debian and security updates and volatile, this is supported. I do not know what you mean by manually, though. That's pretty much how Windows handles things. Not really. We know some softwares works on security updated system. ... An example -- Here is my scenario. I have a server running Ubuntu 8.04 LTS: a stable, recent release of a Debian-based Linux distribution. I wish to install a security-related program called psad (short for Port Scan Attack Detector) on that server. However, the stable package of psad for Ubuntu 8.04 turns out to house version 2.1 of psad. That wouldn't bother me, except that… I can't set it up! This is Ubuntu problem. Please ask them. The reason I'm having difficulty setting it up is that the documentation on installing psad refer not to version 2.1 but to version 2.1.4, which requires setting up differently to 2.1. Debian usually supply NEWS or README.Debian to adress these issue. I have to say Documentation is generally weak point on Debian. ... Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
* Osamu Aoki [EMAIL PROTECTED] [2008 Nov 05 06:05 -0600]: Why have package managers? -- Are package managers necessary? Well, no. What We need this to keep consistency, ... One way of managing software is simply to install individual software programs/libraries as needed, and allow each item to handle its own updating or uninstallation (or even just leave that to the user to do manually). Within stable Debian and security updates and volatile, this is supported. If the OP would like to do things manually, I invite him to try Slackware as there is no default package manager (or a very minimal one that will install and remove packages but not much more). Packages are little changed from their upstream release and if there are conflicts between packages, well the system administrator gets to figure that out. I do not know what you mean by manually, though. See Slackware. ;-) - Nate -- The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true. Ham radio, Linux, bikes, and more: http://n0nb.us/index.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
Are package managers necessary? Well, no. What We need this to keep consistency, ... One way of managing software is simply to install individual software programs/libraries as needed, and allow each item to handle its own updating or uninstallation (or even just leave that to the user to do manually). Within stable Debian and security updates and volatile, this is supported. If the OP would like to do things manually, I invite him to try Slackware as there is no default package manager (or a very minimal one that will install and remove packages but not much more). Packages are little changed from their upstream release and if there are conflicts between packages, well the system administrator gets to figure that out. I do not know what you mean by manually, though. See Slackware. ;-) It seems to me the cleanest form of manual package management is still the old DOS style. All the files of a single program lies in one directory and to uninstall the program would just involve a simple removal of the directory. If I recall correctly a few years ago, there exist a distro that was produced entirely for this kind of pkg philosophy. -- In Liberty Koh Choon Lin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
Koh Choon Lin wrote: It seems to me the cleanest form of manual package management is still the old DOS style. All the files of a single program lies in one directory and to uninstall the program would just involve a simple removal of the directory. If I recall correctly a few years ago, there exist a distro that was produced entirely for this kind of pkg philosophy. There exists one now, but I'm not sure if it's the same one: http://www.gobolinux.org/ -- Bell Labs Unix -- Reach out and grep someone. Eduardo M KALINOWSKI [EMAIL PROTECTED] http://move.to/hpkb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
On 11/05/08 07:25, Koh Choon Lin wrote: [snip] It seems to me the cleanest form of manual package management is still the old DOS style. All the files of a single program lies in one directory and to uninstall the program would just involve a simple removal of the directory. That works only in relatively simple systems with no maze of complex shared libraries. That works well in DOS, and pretty well in Windows, where you rely on the Windows API, or bring your own shared DLLs. It even works to a degree in Linux on systems where packages have extremely low granularity. But Debian purposefully creates highly granular binary packages so that people can decide to install only what they want. -- Ron Johnson, Jr. Jefferson LA USA I won't have to worry about putting gas in my car, I won't have to worry about paying my mortgage. Peggy Joseph, on why she loves Obama -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
Koh Choon Lin writes: It seems to me the cleanest form of manual package management is still the old DOS style. All the files of a single program lies in one directory Each with its own copy of all its dependencies, including libc and all other libraries it calls and all the programs and daemons it uses such as dbus and hal. Sure. And then when there is a critical update to libc or some other widely-used thing you get to upgrade every package on your system, one at a time, as the maintainers get new packages ready. You have the fun of downloading each of those dependencies hundreds of times and finding space for them all. Why not give each package its own kernel while you are at it? -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: When stability is pointless
Please remove me from this chain of nonsense Robert Caruso President/Owner Mitigation Online Consultants 818-501-1520 Main Office 818-501-1524 Direct Office 310-709-7157 Cell 310-997-3677 Fax [EMAIL PROTECTED] www.mitigationonlineconsultants.com AIM: robmodelinla -Original Message- From: John Hasler [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 05, 2008 6:01 AM To: debian-user@lists.debian.org Subject: Re: When stability is pointless Koh Choon Lin writes: It seems to me the cleanest form of manual package management is still the old DOS style. All the files of a single program lies in one directory Each with its own copy of all its dependencies, including libc and all other libraries it calls and all the programs and daemons it uses such as dbus and hal. Sure. And then when there is a critical update to libc or some other widely-used thing you get to upgrade every package on your system, one at a time, as the maintainers get new packages ready. You have the fun of downloading each of those dependencies hundreds of times and finding space for them all. Why not give each package its own kernel while you are at it? -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
On Wed, Nov 05, 2008 at 09:25:24PM +0800, Koh Choon Lin wrote: Are package managers necessary? Well, no. What We need this to keep consistency, ... One way of managing software is simply to install individual software programs/libraries as needed, and allow each item to handle its own updating or uninstallation (or even just leave that to the user to do manually). Within stable Debian and security updates and volatile, this is supported. If the OP would like to do things manually, I invite him to try Slackware as there is no default package manager (or a very minimal one that will install and remove packages but not much more). Packages are little changed from their upstream release and if there are conflicts between packages, well the system administrator gets to figure that out. I do not know what you mean by manually, though. See Slackware. ;-) It seems to me the cleanest form of manual package management is still the old DOS style. All the files of a single program lies in one directory and to uninstall the program would just involve a simple removal of the directory. How do you uninstall gdm? Remove the directory gdm? The directory gnome-base? The directory gnome? Would you be surprised that your GNOME setup is suddenly broken? There is indeed gobolinux that implements this. And as you can see, this concept is simply not popular even though it has been around for a long time. -- Tzafrir Cohen | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il || a Mutt's [EMAIL PROTECTED] || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Caruso wrote: Please remove me from this chain of nonsense To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] ;-) Johannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkRuw0ACgkQC1NzPRl9qEULkwCfdPzBDJMofInAI0KzahIzy0Qs UYkAnRRPymuLsoqihQt5iyZd7oUt9Zha =HQhA -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
John Hasler wrote: Koh Choon Lin writes: It seems to me the cleanest form of manual package management is still the old DOS style. All the files of a single program lies in one directory Each with its own copy of all its dependencies, including libc and all other libraries it calls and all the programs and daemons it uses such as dbus and hal. Sure. And then when there is a critical update to libc or some other widely-used thing you get to upgrade every package on your system, one at a time, as the maintainers get new packages ready. You have the fun of downloading each of those dependencies hundreds of times and finding space for them all. Why not give each package its own kernel while you are at it? I don't think he meant something like chroot env. What he means is build with unique --prefix, what I exactly do for testing purposes. If the test is ok then I package with dpkg-buildpackage or similar. regards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
When stability is pointless
With apologies for cross-posting. Dear all, I have copied below the text of a blog post* I wrote a few minutes ago, because it addresses an issue in Debian and Debian-derived distros that I've encountered several times, and which no doubt many people encounter frequently. It's an issue which seems, to judge by forum posts and mailing list requests, to generate a fair amount of traffic and expenditure of effort, but which has not really been tackled in a co-ordinated way as far as I am aware. Consequently, I've written this piece (which is intended for a general audience) in order to raise awareness of the issue, and to seek a co-ordinated effort to tackle it. Yours respectfully, Sam Kuper *URL: http://www.sampablokuper.com/blog/2008/11/05/when-stability-is-pointless/ When stability is pointless === Many Linux distributions (and other software environments too) use package managers to facilitate the installation, upgrading and uninstallation of software packages as needed. At least, that's the idea. Why have package managers? -- Are package managers necessary? Well, no. One way of managing software is simply to install individual software programs/libraries as needed, and allow each item to handle its own updating or uninstallation (or even just leave that to the user to do manually). That's pretty much how Windows handles things. It works OK if it isn't crucial that your programs aren't able to communicate with each other beyond basic, operating system level mechanisms like cut-and-paste. If your programs depend on each other, however, you'd be in trouble if you removed a piece of software that another piece depended on, or installed a piece without installing its dependencies, etc. Linux distributions usually have many pieces of software that are inter-dependent. A package manager can keep track of those dependencies and can, for instance, inform a user about to uninstall a piece of software of which other packages will be affected by this. That's important, because otherwise the user might accidentally disable something crucial. Package managers can also make upgrading software, to take onboard the latest security patches, trivial, requiring only one or two commands in order to automatically upgrade all the packages on an entire system for which upgrades are available. I haven't investigated the historical origins of package management, so I can't claim to know the original reason why package managers came to exist. But I can state from experience that package managers, when they work well, make life easier than it would otherwise be for system administrators running Linux systems with interdependent packages. Stability - Package managers facilitate stability. Given the foregoing, this should come as no surprise. Yet in the context of many Linux distributions, stability means something more specific than the colloquial reliable, consistent sort of meaning that the term normally implies. Stability, in the context of these distributions, means unchanging, except with regard to security. One such distribution is Debian. Through the magic of package managers, Debian maintainers maintain multiple packages of each original software item they want to make available to users. The reason for the multiple packages is normally to achieve stability. The stability is achieved by packaging a version of the original software that has been tested sufficiently to warrant confidence in its security: it is not known to compromise systems on which it runs (except in cases where it may do so by explicit design). This stable package is then offered to users for, typcially, many years, and is not altered in any way except if a security flaw is discovered in it. Only if a security is found will the package be modified: to patch the flaw. Meanwhile, the maintainer will keep an eye on new versions of the original software. When the maintainer thinks a new version is worth packaging, she may package it as an unstable package to begin with, and then subsequently a testing package. If, as the release of a new version of Debian is approaching, the testing package meets sufficient criteria indicating its suitability for being regarded as stable, then it, too, is marked as stable for that new release of Debian, and is thereafter treated as described above. As such, Debian may have multiple packages for the same piece of software: stable packages for current and old versions of Debian, and unstable and/or testing packages. Usually, each of these packages will be based upon a different version of the original software. In a hypothetical case, the stable package for the current Debian stable release might contain version 3.1 of the original software (perhaps with security patches, as described above); the previous Debian stable release might have packaged version 1.0 of the original software. The current testing version of Debian might package version 3.9
Re: When stability is pointless
On Wed, Nov 05, 2008 at 01:26:31AM +, Sam Kuper wrote: [snip long preamble] Sometimes, stability lets you down. My perception is that the greatest problems with the system of stability practised by Debian and other Linux communities arise when the upstream developer has not maintained the documentation for earlier versions of the software he has written. This leads to a disconnect between users reliant on package managemers and interested in dependability, and developers interested in making software that is faster, more fully featured, or otherwise different from the earlier versions of their software. An example -- Here is my scenario. I have a server running Ubuntu 8.04 LTS: a stable, recent release of a Debian-based Linux distribution. I wish to install a security-related program called psad (short for Port Scan Attack Detector) on that server. However, the stable package of psad for Ubuntu 8.04 turns out to house version 2.1 of psad. That wouldn't bother me, except that??? I can't set it up! The reason I'm having difficulty setting it up is that the documentation on installing psad refer not to version 2.1 but to version 2.1.4, which requires setting up differently to 2.1. The developer's recommendation is that I upgrade to a more recent version, but two questions arise: If Ubuntu is supplying documentation on how to set up psad for a version different than the psad binary they supply, then that is a Ubuntu bug. Or, are you saying that you are trying to implement a psad recipe from the internet that doesn't apply to the version of psad supplied in Ubuntu? For all Ubuntu is based on Debian, I don't think it follows debian policy. The policy manual says, basically and among other things, that installing a package should result in that package working out-of-the-box in some fashion only needing tweaking by the sysadmin. I've never used psad but I would be very surprised if the problem you experienced were to happen were you running Debian Stable. Since Ubuntu is based not on Debian Stable but on (I think) Unstable, I don't know how one can consider any Ubuntu release to be stable. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
Hi Doug, Thanks for your comments. 2008/11/5 Douglas A. Tutty [EMAIL PROTECTED]: Or, are you saying that you are trying to implement a psad recipe from the internet that doesn't apply to the version of psad supplied in Ubuntu? Essentially correct. But not just any old set of psad instructions: the instructions provided on the psad website and in the developer's book on Linux firewalls. In other words, pretty much the most comprehensive set of instructions I could find. For all Ubuntu is based on Debian, I don't think it follows debian policy. The policy manual says, basically and among other things, that installing a package should result in that package working out-of-the-box in some fashion only needing tweaking by the sysadmin. Define working (or tweaking). My experience with some packages in Etch suggest that Debian sometimes has problems like this too. I've never used psad but I would be very surprised if the problem you experienced were to happen were you running Debian Stable. You may be right. Perhaps I should go back to Debian Stable. But one of the reasons I switched to Ubuntu was to minimise the gap between a package being deprecated by its developer and deprecated by its maintainer, in an effort to avoid precisely the sort of problem I outlined in my post. Since Ubuntu is based not on Debian Stable but on (I think) Unstable, I don't know how one can consider any Ubuntu release to be stable. Ubuntu has LTS (Long-Term Support) releases, which roughly translate to Stable. However, I think this is perhaps missing the point. Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
Hello, Sam Kuper wrote: Hi Doug, Thanks for your comments. 2008/11/5 Douglas A. Tutty [EMAIL PROTECTED]: Or, are you saying that you are trying to implement a psad recipe from the internet that doesn't apply to the version of psad supplied in Ubuntu? Essentially correct. But not just any old set of psad instructions: the instructions provided on the psad website and in the developer's book on Linux firewalls. In other words, pretty much the most comprehensive set of instructions I could find. For all Ubuntu is based on Debian, I don't think it follows debian policy. The policy manual says, basically and among other things, that installing a package should result in that package working out-of-the-box in some fashion only needing tweaking by the sysadmin. Define working (or tweaking). My experience with some packages in Etch suggest that Debian sometimes has problems like this too. So far I can understand, Etch is not yet stable. I've never used psad but I would be very surprised if the problem you experienced were to happen were you running Debian Stable. You may be right. Perhaps I should go back to Debian Stable. But one of the reasons I switched to Ubuntu was to minimise the gap between a package being deprecated by its developer and deprecated by its maintainer, in an effort to avoid precisely the sort of problem I outlined in my post. Since Ubuntu is based not on Debian Stable but on (I think) Unstable, I don't know how one can consider any Ubuntu release to be stable. Ubuntu has LTS (Long-Term Support) releases, which roughly translate to Stable. However, I think this is perhaps missing the point. Sam hth, Jerome -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
On Wed, Nov 05, 2008 at 11:48:05AM +0800, Jerome BENOIT wrote: Define working (or tweaking). My experience with some packages in Etch suggest that Debian sometimes has problems like this too. So far I can understand, Etch is not yet stable. Etch is so stable, it will soon be old-stable. I think you're thinking Lenny. :) Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When stability is pointless
It is very common for software developers to plow ahead without thinking much about the versions the distros provide. You may want to contact them and see how they would expect users to use their software effectively. It's likely: They won't care. Open-source suffers from not having the rest of what is typically seen in a company making commercial software... a team of documentation writers, a support staff to answer questions, people reviewing changes to see if they're sane from a user's perspective, user-interface standards and people to check them... all those nice things your dollars pay for. The open-source software eco-sphere is dense with applications, but very shallow. It never gains much depth of quality. Certain major applications with paid people taking care of them (the kernel, Apache, MySQL, etc) all are much better than the average quality level. Nate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
