Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Debian

Debian Woody Nearing Release 297

Posted by timothy from the long-time-comin' dept.
willybur submits word of this Debian Planet story on the upcoming release of its next stable version. The article says: "According to Anthony Towns (our beloved Release Manager), woody is nearing release. All but three RC base bugs are fixed now, and the bugsquashing party is working through the RC bugs in standard. It's not all good news though. The bad news is that this means we're probably releasing soon, and that of the hundreds of less important packages with RC bugs (eg, bugzilla, craft, crossfire-{client,server}, epic4, fvwm95, gmc, gnome-admin, intuitively, kdepim, moon-lander, tkdesk, wine, and xosview) will be getting randomly ripped out of testing ... Check the stuff that's important to you and get it fixed before it's too late." Says willybur: "See the announcement on debian-devel-announce."
This discussion has been archived. No new comments can be posted.

Debian Woody Nearing Release More

Debian Woody Nearing Release

Comments Filter:

  • Better Late (Score:2, Insightful)

    by Aknaton ( 528294 )
    Of all the Linux distributions out there, I think that I like Debian the best. I also really like the fact that they are more concerned with quality then being there with the newest toys on the block.

    • If the inclusion of archaic, bug-ridden software is your idea of "quality", then I concur. Postgresql 6.5 is definitely a quality-laden release, the later versions just implement useless features such as "stability".

      maru
  • I'm hoping they're serious about changing to a much shorter development cycle. 2.2 was out of date enough when I installed it over a year ago.
    • I ran early 2.4 kernels- you didn't miss anything, let me tell you. Nothing good that is.

      No, I meant Debian 2.2

    • Re:About time too (Score:4, Interesting)

      by Shiny Metal S. ( 544229 ) on Saturday February 16, 2002 @07:36PM (#3019904) Homepage
      I'm hoping they're serious about changing to a much shorter development cycle. 2.2 was out of date enough when I installed it over a year ago.

      You should've installed Woody then. Most of the time you have three versions to choose from: stable, testing/frozen and unstable. When you need a system which will not ever crash after years of heavy load, use stable. If you want more decent software, use testing. If you want the newest versions of software from yesterday, use unstable. It's Good Thing because you have a choice, so don't complain that you're not forced to use the latest untested software, it's up to you. And remember that unstable Debian is usually more stable than any other distro.

  • All I can say is this: I *seriously* hope we're using at least the 2.0 kernel.
    • All I can say is this: I *seriously* hope we're using at least the 2.0 kernel.

      2.2.20 AFAIK. It's a rock solid kernel.

  • Why is it... (Score:1, Funny)

    by Nameles ( 122260 )
    ...that every time I download and burn a Linux distro, the next version appears within 8 hours - 3 days?

  • big news (Score:1, Funny)

    by seanw ( 45548 )

    Debian is being released soon!

    in other news, hell has recently frozen over.

  • In other news... (Score:1, Offtopic)

    by MBCook ( 132727 )
    Duke Nukem Forever has gone gold, hell froze over, and I got a date ;) Seriously though, good from them. It will be nice to have magazines that compare linux distros compare woody vs. redhat, not potatoe (which is woefully old) to redhat.

  • foo (Score:3, Informative)

    by Anthony Boyd ( 242971 ) on Saturday February 16, 2002 @07:49PM (#3019948) Homepage
    Expected major upgrades, by the time woody releases, include GLibC 2.2, GCC 3.0, XFree86 4.1 and Perl 5.6. Linux kernel 2.4 is judged not to be mature enough to be a default for most architectures at this time, but you can install a 2.4 kernel from Debian after completing your installation. It's also likely that the debconf package will be used in nearly all the packages which need to prompt in the maintainer scripts.

    I think Debian needs a 2.4 kernel as the default if Debian is going to shake its image as hopelessly outdated. For instance, even now you can apt-get up-to-date packages, but most people don't go beyond the defaults. As for me, I go beyond a little: I like to get security patches. Love those. But I'm wary of upgrading other things -- I've tried a KDE 2.1 to 2.2 upgrade that really made my system screwy, and a SuSE 2.4.10 kernel upgrade to 2.4.14 that lost my ext3 functionality. Of course I fixed these things, but I'm wary now. It took time, which is valuable to me. Even with Debian, you can apt-get yourself into trouble. So as someone on the sidelines (well, maybe more than that, I've done a lot of Debian installs), I would encourage the Debian folks to either reconsider the default install, or actively plan for a 3.1 (or even 3.0.1) release that will happen soon after 3.0.

    • Re:foo (Score:3, Informative)

      by Daniel ( 1678 )
      For instance, even now you can apt-get up-to-date packages

      That's talking about an entirely different thing: to install up-to-date packages, you have to put unstable (or testing) in sources.list, and deal with the issues that arise from that.

      The 2.4 kernels will be *in woody*, distributed on woody CDs, and available in the same way as the rest of the woody software. They just weren't planned to be the default kernel, although I've also heard rumors that some install disks are being built around 2.4.

      Daniel
      • That's talking about an entirely different thing: to install up-to-date packages, you have to put unstable (or testing) in sources.list, and deal with the issues that arise from that.

        That's nearly a non-issue, now that you can pick and choose which packages to install from which distros, by editing /etc/apt/preferences.

        man 5 apt_preferences

        • Re:foo (Score:2)

          by Daniel ( 1678 )
          Ehh. stable/unstable mixes are not supported or encouraged, at least not by me :) If you're adventurous, sure, do it and file bugs against packages whose dependencies are wrong.

          But most people should stick with stable. If stable is too out-of-date, the proper solution is to release more often.

          Daniel
  • if you have a recent version of apt, and you put the following lines into /etc/apt/prefences it will get unstable packages when there is no testing version.
    --- begin cut here ---
    Package: *
    Pin: release a=unstable
    Pin-Priority: 50
    --- end cut here ---

    enjoy,

    -- p
    • damn, i posted this before but i misspelled preferences, so to be clear:
      if you have a recent version of apt, and you put the following lines into /etc/apt/preferences it will get unstable packages when there is no testing version.
      --- begin cut here ---
      Package: *
      Pin: release a=unstable
      Pin-Priority: 50
      --- end cut here ---

      enjoy,

      -- p

  • So does alien work reliably yet? (Score:3, Interesting)

    by Nailer ( 69468 ) on Saturday February 16, 2002 @07:59PM (#3019984)
    From discussion with Debain users (and time spent administering Debian boxed at my workplace) Debian's rpm support doesn't work that well for anything apart from large self-contained statically compiled packages. The problem being that the Linux Standards Base [linuxbase.org] will probably be considered the definition of what a Linux distro is in a couple of years (and is starting to be used as a yardstick these days). Yes Debian ostensibly supports the LSB via alien, but how well?

    The distributions which put initscripts in nonstandard places have had to change, those install packages into /opt have had to change, and if they haven't, they've been looked upon negatively (and rightly so) for their lack of standards support. So how well does alien work, and would you use it to install some, or even most software on your system? A standardized packaging system is useful for more than just closed source apps - its useful for every open source app maintainer that's tired of maintaining different sets of packages for Red hat, Suse, Debian, Mandrake, Connectiva, and every other distro out there. Theoretically, the KDE people (for example) should only have to release one set of packages per OS. Doing otherwise wastes a great amoutn of time that could be used elsewhere.

    And yeah, I'm a Red Hat user who has posted a non 100% supportive comment about Debian in a Debian release news item. /me waits for the inevitable negative moderations from people who disagree with what I'm saying but can't voice their own opinions and repond maturely.

    • Re:So does alien work reliably yet? (Score:4, Interesting)

      by Jay Carlson ( 28733 ) on Saturday February 16, 2002 @08:33PM (#3020107) Homepage
      Note that the LSB specifies the version [rpmdp.org] of the RPM file format in the book Maximum RPM [rpmdp.org]. That's version 3. Let me repeat that; the LSB standard RPM package format is version 3. So now that RH is shipping v4 RPMs, a lot of other people are too, and those packages are simply not compliant with the LSB.

      More broadly, the LSB did not intend to give RedHat the power to define standard Linux. You shouldn't let RedHat define the standard either.

      • RPM 3.05 will happily install any RPM in existence.

        Red Hat didn't join the LSB for a couple of years precisely to avoid these inevitable (and completely unjustified [well you didn't provide any supporting arguments]) accusations. They lost out on few things too - eg, initscript directories (and thank god, rc.d/init.d sucks). Everyone has (and has already often made) concessions towards the LSB, Red Hat, Debian, SuSE or otherwise.

        • I don't care what a particular implementation of RPM will install. The implementation is not standardized. I care about the format. Let me demonstrate to you that v4 RPMs exist:

          nop@family-values:/tmp$ wget ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i3 86/RedHat/RPMS/ash-0.3.7-2.i386.rpm

          [...]

          nop@family-values:/tmp$ od -t x1 ash-0.3.7-2.i386.rpm | head -1
          0000000 ed ab ee db 04 00 00 00 00 01 61 73 68 2d 30 2e

          You will note the "04 00" after the magic number. Is this accusation still unjustified?

          The place I first saw these in the wild was source RPMs. In several cases, I've gotten SRPMs that I could not extract due to version mismatches. (Extraction of SRPMs is not a LSB issue, however.)

          I'm not complaining that Red Hat was not a good player in the LSB standardization process; I've no reason to think otherwise. I'm complaining about the attitude that "interoperability with Red Hat" is an important goal for Debian or other distros. It's more important to interop via standards, not testing against a perceived market leader.

          • I see your point, and agree with it. But lack of RPM 3 packages in Red Hat doesn't excuse the same error in Debian. I don't think `interoperability with Red Hat' is a goal, and if anyone does, they are wrong. If the LSB went with debs, initscripts in /sbin/init.d and all software in /opt, that's what I'd want out of Red Hat, Debian, and everyone else. But they didn't - they spent a great deal of time deciding on these issues, inclduing a standard package format and people should move towards that packaging system (if you want suggested / recommended dependencies, then add it to rpm).
    • I've never had any problems using alien to install rpms in over 3 years of using Debian.

      I've not installed too many rpms though....

    • Debian and Standards (Score:5, Interesting)

      by castlan ( 255560 ) on Saturday February 16, 2002 @10:23PM (#3020421)
      It seems that you misunderstand - Alien works great, it makes RPMs, DPKGs, and TGZs interchangeable. Your problem comes from the fact that Redhat RPMs (like Debian DPKGs and Slackware TGZs) also contain control information, effectively shell scripts that rely on the filesystem of the intended distribution. Since Redhat and Debian (all releases) use differnt locations for e.g. their rc.X files (initscripts), the control information isn't portable.

      The Linux Standards Base is a fairly useful effort, but it includes the Linux Filesystem Hierarchy Standard [pathname.com], which seems to be what you intended to take Debain to task for. AFAIK, the RPM standard is specified only in the FHS, and not directly in the LSB. So you meant "Debian supports the FHS via alien..."

      The FHS is full of good intentions, but unfortunately the reality falls far short. DJB has a number of valid criticisms [cr.yp.to] that are as of yet not addressed by the LSB, or more accurately, the FHS. While I tend to think that standards are a good thing, I don't think that you should ignore convention in favor of provably flawed standards, so the FHS is not as desireable as I once felt. Without regard to the benefit of the FHS, I will argue that Debian supports it, in fact the Debian Project has made FHS support a specific requirement [debian.org] in their official policy manual.

      The part of the FHS that you seem to be missing, is that while RPM is the official packaging format of the FHS, that doesn't mean that Redhat is automatically compliant. Rather, the standard RPM format is that defined in the publication Maximum RPM, and Redhat has continues development of their RPM format since that time. That means that the average RPM distributed with Redhat is not FHS compliant. Offical standard RPMs are handled by Debian via Alien flawlessly, and likely by Redhat and SuSE as well.

      More importantly, the "Maximum RPM" RPM format isn't the most important feature of the FHS. More important is adherence to the recommendations of where in the directory tree different types of files should be. It seems that Debian is the most compliant distro, closely followed by SuSE last time I saw a comparison. You may have noticed when you administered the Debian Boxen that the /opt directory was completely unsed by Debian, and AFAIK has always been that way. Since the release of Potato, something as laborious as moving every single changelog, readme, info page, man page and other textual file from its previous location (usuallt /usr/doc) into the FHS mandated /usr/share/doc hierarchy. This was of dubious benefit at best, other than strict adherence to the FHS.

      Just a small point of contention, every "Linux distribution" can arguably be called a distinct OS -- Unless you support that they are all just implementations of the GNU OS. But NetBSD and FreeBSD are just distributions of 386BSD. OpenBSD is just another version of NetBSD. AIX and IRIX are just distributions of UNIX. Even if all Linux distros are unified by the LSB, that's not much different than how all Unices have been unified by the POSIX standard. And Remember, Debian keeps their own Linux tree, as does Redhat, both distinct from the Official Linux at Kernel.org.

      Theoretically, software developers should only have to release their files as .TGZ archives, and Free Software Operating systems should respect the conventions... especially in the common case where the software project existed longer than the OS in question. For the most part, the Free Software BSDs have done this. FreeBSD developed their Ports system allowing them to keep a tree of makefiles which would aid in compilation of software packages that isn't part of the standard system. The exception is that the BSDs tend to have integrated XFree86 into their "base system", so they have modified XFree86 from the standard distribution. Debian has gone much further than this, packaging almost any Free Software of interest, for inclusion into their system... making Debian the largest, most versatile system to date.

      As a Red Hat user, it it is unfortunate but understandable that you didn't know more about the FHS and APT when you administered the Debian boxen. Perhaps you would have realised that you were likely using a non standard RedHat 7.x (e.g.) specific RPM. Even Mandrake, which directly descended from Redhat, has enough of a delta from Redhat that not all RPMs will interchange between the two. RPMs intended for other distros will tend to fare much worse. Even an RPM for Redhat 6.0 isn't recommended for Redhat 7.3, so it was a bit naive to expect a non-FHS RPM to work. Better would have been to type:

      apt-cache search pppoe

      If you wanted to install Roaring Penguin's PPPoE RPM to see it it was available, and what the APT package is named. If you had an RPM that you needed to install, then odds are that it was available. Then you type:

      apt-get install pppoe

      and all would have been well. Even if you had the FHS compliant rp-pppoe.RPM, using the APT/.dpkg version would be preferred, as the DPKG format has superior dependancy handling.

      I am heartened to see that you haven't been down modded, I I hope that my post has been informative.

      -castlan
      • > AFAIK, the RPM standard is specified only in the FHS, and not directly in the LSB.

        I hate to burst your bubble, but the FHS has nothing to do with package formats at all.

        joey@silk:/usr/doc/debian-policy/fhs>zgrep -i rpm fhs.txt.gz
        zsh: exit 1 zgrep -i rpm fhs.txt.gz

        As for how well alien works, what can I say, it works for me.
      • It seems that you misunderstand - Alien works great, it makes RPMs, DPKGs, and TGZs interchangeable.
        Your problem comes from the fact that Redhat RPMs (like Debian DPKGs and Slackware TGZs) also contain control information.

        Of course they provide control information - if they didn't, they wouldn't be management systems would they? If alien still removes this information it does not do a good job of installing packages. Rather it turns those packages into dumb archives.

        Since Redhat and Debian (all releases) use differnt locations for e.g. their rc.X files (initscripts)

        Initscripts live in /etc/init.d. Other locations are not correct [linuxbase.org]. Red Hat, SuSEm and other people who once put initscripts in other (now incorrect) locations are moving towards this.

        AFAIK, the RPM standard is specified only in the FHS, and not directly in the LSB.

        It seems you're in error. RPM 3 format packages are specified in the Linux standards base. [linuxbase.org]

        DJB has a number of valid criticisms [cr.yp.to] (of the FHS) that are as of yet not addressed by the LSB, or more accurately, the FHS.

        Good or bad, its a standard. You'll get more pain from not sticking to a standard and fragmenting Linux than you will from adopting a standard even if you don't like every part of it. Some of DJBs recommendations (eg, a registered namespace for apps) coudl easily be included in the LSB, just as suiggested / recommended dependcies could be added to RPM if so desired (says someone who happily maintains a 3GB APT repository filled wit h RPM packages for the Red Hat machines at his workplace).

        in fact the Debian Project has made FHS support a specific requirement [debian.org] in their official policy manual.

        Excellent. But they really should do the same with the LSB.

        The part of the FHS that you seem to be missing, is that while RPM is the official packaging format of the FHS, that doesn't mean that Redhat is automatically compliant.

        True, another poster made this point earlier and I agree: all Linux distribtions should completely support RPM 3.05 packages.

        Offical standard RPMs are handled by Debian via Alien flawlessly

        No they are not, if they remove control information as you have earlier stated. Without this data there is no `management' and it seems alien can hardly be trusted to install a large amount of interdependent software.

        Debian's pretty good with FHS support, so is RH: RH has likewise moved all /usr/doc files into /usr/share/doc, and haven't used /opt in years. Suse moved their initscripts from /sbin/init.d to the proper location, but still /opt kde. I'm glad that these efforts are being made, however greater effort on fundamental issues like the packaging system needs to be performed to stop Linux fragmenting.

        Theoretically, software developers should only have to release their files as .TGZ archives

        If they added standardized installs, uninstalls, information about the relationships between packages, querying / verifying machinisms, etc, this would be possible. Unfortunately they don't and it isn't: hence the need for packaging.

        As a Red Hat user, it it is unfortunate but understandable that you didn't know more about the FHS and APT when you administered the Debian boxen.

        I am well aware of the FHS and APT. I am well aware alien doesn't handle RPM packages beyong turning them into dumb archives. I just wanted to se if there is any attempt under way to fix this.

        I'm also especially aware of how APT works: I run an APT repository for the Red Hat systems at work and my own machcine, with around 3000 packages.

        Even if you had the FHS compliant rp-pppoe.RPM, using the APT/.dpkg version would be preferred, as the DPKG format has superior dependancy handling.

        There are no `APT' packages - you means debs. APT run on top of the packaging system. Yes, recommended / suggested dependencies are very useful, and its good that .deb provides this. So is transaction handling for the rpm database - its good that rpm provides this. They each have their advanatges. I'd like to see the good features of deb added into RPM, and the LSB updated to this new version.

        I am heartened to see that you haven't been down modded, I I hope that my post has been informative.

        Thankyou.

        Mike

        -castlan
        • Without this data there is no `management' and it seems alien can hardly be trusted to install a large amount of interdependent software.

          Why would you want to do that? There's no large interdependent amount of non-free software for Linux. If you're using Debian, use Debian packages - they work better on Debian, since they are built for and tested with Debian. I would be surprised to find a large amount of interdependent Free software that Debian doesn't include at least of most of.

          Does the RPM world agree on dependencies? It didn't last time I heard, but I don't pay attention to stuff like that. The X maintainer completely rearranges the X packages frequently, as do the Gnome and KDE developers, and fairly often some developer will change the packages on his or her package and everyone depending on that package will have to jump to correct their package's dependencies. My assumption would be that Red Hat and everyone else do this too, whenever they find it beneficial, making it a pita to keep track of dependencies cross- and even intra-distribution.
      • This is informative? Its demonstrably incorrect for one thing, about both the FHS and how packages are handled by Alien. Problem: the people who read (and moderate) Debian stories are the ones interested in Debian to the point of excluding anything that seems counter to the direction of their distribution.

        Oh well, I guess I was never going to get much of a chance.
    • Theoretically, the KDE people (for example) should only have to release one set of packages per OS.

      They can't. The LSB doesn't standardize C++, since the libraries change too much.

      In any case, there's no reason for any Debian user to be using KDE that isn't from Debian and isn't from source. Debian does great work to make sure that everything supports the Debian menu system, for example, and any problems with the software can go through one main bug tracking system.

      Doing otherwise wastes a great amoutn of time that could be used elsewhere.

      Getting a large piece of software like KDE working right on your distribution can take quite a bit of work. So? If someone from Debian feels like putting that work into getting to work right with
      Debian, what buisness of it is yours? Taking that away would take away the point of a distribution.

      If you want to write an LSB program, then the LSB is there for you, and Debian will support that. If not, then the source and volunteers from the distributions will be there for you.

      A standardized packaging system is useful for more than just closed source apps - its useful for every open source app maintainer

      That's what "configure; make; make install" is for.

      You can't tell everyone to use the same language so we don't need to translate; don't tell everyone to use the same distribution so people don't have to worry about the differences.
      • Hopefully, perhaps inevitably, C++ libraries will be included as part of the LSB.

        Debian does great work to make sure that everything supports the Debian menu system, for example, and any problems with the software can go through one main bug tracking system.

        Either of these are still entirely possible while using standard packages. One can track . Almost every other Linux distribution has its own version of the menu system, typically /etc/applnk directory.

        Getting a large piece of software like KDE working right on your distribution can take quite a bit of work.

        This is precisely the problem the LSB was created to solve. Linux apps should be Linux apps.

        If you want to write an LSB program, then the LSB is there for you, and Debian will support that.

        Not unless I make alien work as a package manager rather than an extractor of archives.

        >> A standardized packaging system is useful for more than just closed source apps - its useful for every open source app maintainer

        That's what "configure; make; make install" is for.

        How? How will that solve the LDP from having to write twelve million different guides to ppp because some distro decided to use a nonstandard initscript dir, packaging system, or documentation directory? It won't.

        You can't tell everyone to use the same language so we don't need to translate

        Nobody is forcing people to do anything. Linux distro's, if they want to label themselves LSB, should do their best to support the LSB. The current abilities of alien seem to be highly lacking in this regard. If Debian don't want stable and reliable way of installing LSB packages, they should stop hoping inanely that the packaging system decision will be reversed and simply say they have no interest in the LSB, as Slackware does.

        • If Debian don't want stable and reliable way of installing LSB packages, they should stop hoping inanely that the packaging system decision will be reversed and simply say they have no interest in the LSB, as Slackware does.

          Please don't confuse what you want the LSB to be with what the LSB is. Debian is a full member of the LSB, the packaging decision was made with Debian's approval, and it has always been understood that Alien is an acceptable solution.

          An LSB package must have one, and only one, dependency - lsb. There's no possibility of a large independent set of LSB packages.

          How will that solve the LDP from having to write twelve million different guides to ppp because some distro decided to use a nonstandard initscript dir, packaging system, or documentation directory?

          Does every guide really have to tell you how to install a package? Even if you do standardize on all that, what's to prevent a distro from coming up with a better name for it or a completely different implementation? (Documentation directory is more of a strawman - it's dictated by FHS, which is followed by almost everyone.)

          Getting a large piece of software like KDE working right on your distribution can take quite a bit of work.

          This is precisely the problem the LSB was created to solve. Linux apps should be Linux apps.

          So you're going to magically wave your hands and get everything working right? We must never change libpng (since doing so cause rampant incompatibilities in KDE pacakges, that would require a full recompile of everything.) We must never change compilers (again, massive incompatibilies.) We must never add i18n to the package format, for that must forever be pure rpm 3.0. We must never change libc's, even if something vastly superior to glibc comes up.

          We aren't interested in something that would prevent us from improving Debian. Yes, we are different from RedHat. We try to make the incompatibilities where we do something better, but life is as it is. Infinite Diversity in Infinite Combinations. It's a strength of Linux.
          • Please don't confuse what you want the LSB to be with what the LSB is. Debian is a full member of the LSB, the packaging decision was made with Debian's approval, and it has always been understood that Alien is an acceptable solution.

            I see this as a conflict within the LSB. Obviously a system which turns packagines into dumb archives is not a packaging system. Even if you said alien supports RPM installs, (I think the `P' and `M' is prettty debatable) it certainly doesn't do them well. Every Debian user I know of including myself wouldn't install a large volume of packages in standard format on a Debian box.

            This is a bug withihn the LSB generated to satisfy Debian users. A rather unfortuinate compromise that will olikely bite either the LSB or Debian at some point in the future.

            You're wondering if a guide to using software shoudl include instructions about installing that software: yes it should. Next question.

            Yeah, I like /usr/share/doc too. Its nice that everyone's actually uses the directory, rather than installing them into /var/cache/docs and saying they `support' /usr/share/doc is that's what you want to use.

            Your argument regarding changing is completely illogical. What is preventing you from changing? Just change within the standard. Policy is portable, APT already exists on RPM and I'm sure suggested/recommended dependencies woildn't be hard to implement. For servers and wrokstations, Linux should be Linux. If you want to make it something else, you have the option, but by default, it should support LSB standards in their entirety and reliably.
            • I see this as a conflict within the LSB

              And I see this as them specifing what they want, not what you want. LSB packages don't have dependecies, beyond lsb, since dependencies aren't portable among RPM systems. It isn't for people installing a large volume of packages - it's so you can install one or two packages like oracle or Civ:CTP.

              You're wondering if a guide to using software shoudl include instructions about installing that software: yes it should.

              Should it include instructions on how to use your keyboard to type in the installation? Unless installing that software is tricky, then don't bother. If you need to know that to install ppp, you say apt-get install ppp, then you should reading the Debian instructions first. If you need to point out that it isn't named ppp on all system, well, removing deb's won't solve that problem.

              What is preventing you from changing?

              Do you have any idea how much work it would be to take 6000 packages, and repackage them in RPM format? Do you have any idea how much work it would be to support mixed deb and rpm installs? (We still haven't switched completely to /usr/share/doc - there's still a simlink from /usr/doc to /usr/share/doc for each directory in /usr/share/doc, because of a need for backward compatibility.)

              And for all that, compatibility still won't appear. A KDE RPM compiled against libpng3 will still have various problems when run with a libqt RPM linked against libpng2. An RPM that depends on XFree86 will still not work on a Debian system that has xserver-common installed. An RPM that depends on libstdc++2.9 won't make that library suddenly appear on a Debian system - it needs to be recompiled.

              For servers and wrokstations, Linux should be Linux. If you want to make it something else, you have the option,

              Fine. We're exercising that option. You're welcome to go to the trademark holder, and whine about how we diluting the trademark, but until then we're have as much right to call it Linux as anyone else.

              it should support LSB standards in their entirety and reliably

              That doesn't include RPM dependencies, because the LSB doesn't include dependencies. In fact, the LSB was carefully designed so that Debian can support it in its entirety and reliably without moving to RPMs.

              The LSB was never designed to be what you want it to be. If you want a straitjacket standard, you're welcome to try and get one started; good luck getting everyone to use it.
    • From discussion with Debain users (and time spent administering Debian boxed at my workplace) Debian's rpm support doesn't work that well for anything apart from large self-contained statically compiled packages. The problem being that the Linux Standards Base [linuxbase.org] will probably be considered the definition of what a Linux distro is in a couple of years (and is starting to be used as a yardstick these days). Yes Debian ostensibly supports the LSB via alien, but how well?

      That's a very good question (and one nobody bothered to answer in the ensuing discussion). At present, it probably doesn't support it at all, excluding the rudimentary support for LSB packages joeyh added to alien 8.00. I can't locate any intent to package statement for lsb or lsb-rpm (the former being the LSB's core dependency, the latter being the RPM specified by LSB). The only packaged LSB component is lsb_release.

      I'd have to do a bit more digging to figure out if anyone is actually working on this stuff.
  • I've recently become a debian user from slackware. Apt-get is by far the best tool I've ever used however I was shocked when I installed debian standard and checked the versions of some of the tools. SSH was at version 1.2.3!!! which was insane. Testing wasn't a whole lot better. However I am quite satisfied with unstable currently. Although it breaks from time to time on my laptop.
  • but I am compelled to share with everyone how I misread the caption...

    All but three RC base bugs are belong to us.

    :(

    -9mm-

  • Do the packages being yanked out matter? (Score:3, Interesting)

    by Snowfox ( 34467 ) <snowfox@NOsPaM.snowfox.net> on Saturday February 16, 2002 @08:34PM (#3020110) Homepage
    I'm curious as to how much it matters if most of these packages are yanked out of stable.

    Sure, most people using Debian as a server are running the stable release, but I was under the impression that almost all desktop users were tracking unstable for want of the hundreds of packages missing in the age-old 2.2 release.

    Having all these things fixed for Woody release would be nice, but I'm guessing there's almost nobody out there who'd be affected by these vanishing.

    How many of you Debian folk are using stable for something other than a server?

    • Actually, Potato with Ximian Gnome makes for a pretty decent desktop experience. It's what I run on my age-old laptop. (Well, I use the packages from Gnome, I run XFCE, as Gnome, even without running a file manager, seems quite a bit heavier.) It works great, and I see absolutely no reason to upgrade.

      Plus, building packages as you need them for Potato isn't so bad. You can easily find XFree86 4.03 debs for Potato, along with 2.4 kernels. KDE's stuck at 2.1.2, but that's not so old. What more do you really need?

  • /etc/apt/source.list anyone? (Score:2, Informative)

    by Anonymous Coward
    Im surprised by the amount of "slashdotters" who, while bagging Debian for being out-of-date, are painfully unaware of the fact that Debian is actually 3 different distributions, i.e. Stable/Potato, Testing/Woody and Unstable/Sid. You can have the latest and greatest software with Debian, all it takes is a simple find and replace on /etc/apt/sources.list to change the branch apt-get gets it's package list from.
  • My conversion [whiprush.org] has been detailed here.

    I'm not going to get into the Debian/Red Hat argument here. To me, they're both fine distributions that deserve the attention that they're due. I don't understand the "stability" issue that some Debian fanatics get into. Red Hat has been stable as a rock for me. The thing that makes Debian rule is how easy it is to maintain and keep up to date.

    If you're a Red Hat/Mandrake user and has been looking to convert, this might be useful. FWIW, Debian is a mighty fine distro, give it a try, though you have been warned, it can be addictive. :)

  • I usually make images of my Debian CD's, then update them to the latest with a local Rsync server. 2.2r4 -> 2.2r5 seemed to take less than an hour over 56k, so it sure beats downloading 3 whole ISO's.

    But, anyone know if this will be much help going from 2.2r5 to Woody?

Slashdot Top Deals

"And remember: Evil will always prevail, because Good is dumb." -- Spaceballs

Close