Debian Woody Nearing Release 297
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."
Better Late (Score:2, Insightful)
Re:Better Late (Score:2)
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
About time too (Score:1)
Re:About time too (Score:1)
No, I meant Debian 2.2
Re:About time too (Score:4, Interesting)
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.
Re:About time too (Score:2)
Re:About time too (Score:5, Interesting)
Re:About time too (Score:2)
Unfortunately, the data for Debian which leads to this conclusion is completely wrong. Important security holes were simply ignored when the statistics was prepared (for example, the OpenSSH remote root hole is missing).
Re:About time too (Score:2)
Wow, April Fool's Day [debian.org] came early this year
Daniel
Re:Debian Security (Score:2)
You sir, are a class AA fuckwit.
I find Testing, to be the most stable Linux distro I have ever used, besides Stable.
At best, I guess I could give you the benefit of the doubt and assume you to just be a troll. PS, this is a compliment.
Kernel version? (Score:2, Funny)
Re:Kernel version? (Score:2)
2.2.20 AFAIK. It's a rock solid kernel.
Re:Kernel version? (Score:3, Informative)
Sorry, you can use 2.2.20 or 2.4.13 2.4.14, 2.4.16 and 2.4.17.
See the list of base packages [debian.org].
(and always you can build your own kernel of course)
Re:Kernel version? (Score:2)
There was previously a reiserfs flavor based on the 2.2 kernel, but it doesn't seem to be availble any more.
Daniel
Re:Kernel version? (Score:1, Informative)
Until just recently, if Debian wanted Woody to be their new stable release, a 2.2 kernel was the best they could do - the 2.4 series just wasn't ready, what with all the VM rework.
Now, though, they could go with 2.4.16 or
Re:Kernel version? (Score:4, Insightful)
Re:Kernel version? (Score:2)
Re:Kernel version? (Score:2)
it's a public secret that stable really stands for seriously out of date.
Actually stable stands for you won't spend hours cursing over your malfunctioning server because the package you installed had serious bugs in it.
If you really want something from testing or unstable, just download the source deb, and re-build it for stable.
Re:Kernel version? (Score:2)
So why won't you use Sid with 2.4.17 [debian.org] then?
Re:Kernel version? (Score:2)
Even without make-kpkg there is usually a choice of kernel.
Re:Kernel version (Score:2)
Serious, however, Debian is the best Linux distro I ever used. Some of its approaches are questionable - like "alternatives" - but its as close to a well-designed system as one can get with an eclectic system like GNU/Linux.
The major griefs are - obviously, others already pointes that out - the bogus release cycle nearly forcing you to run unstable, and the package management system, which rocks, but only as long as you are just installing pre-made binaries. I never tried to create a RPM, but making a .deb from some arbitrary code you downloaded is definetly way to much work (compare it to creating a BSD port, where the hardest thing is to determine the best download URL for the source tgz). While Debians package collection is of course impressive, once you install something not included, you most likely will not care about your packaging system, which is always a bad thing.
Why is it... (Score:1, Funny)
Re:Why is it... (Score:2)
use apt-get...
Re:Why is it... (Score:1, Funny)
-MBCook
Re:Why is it... (Score:3, Insightful)
Blah...
Re:Why is it... (Score:2)
big news (Score:1, Funny)
Debian is being released soon!
in other news, hell has recently frozen over.
List of all the Release Critical bugs (Score:5, Informative)
List of all the Release Critical bugs (15 feb. 2002) [debian.org]
Re:List of all the Release Critical bugs (Score:2)
Re:List of all the Release Critical bugs (Score:3, Informative)
Re:List of all the Release Critical bugs (Score:2)
In other news... (Score:1, Offtopic)
foo (Score:3, Informative)
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)
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
Re:foo (Score:2)
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)
But most people should stick with stable. If stable is too out-of-date, the proper solution is to release more often.
Daniel
Re:foo (Score:2)
Daniel
fallback to unstable hack (Score:1)
--- begin cut here ---
Package: *
Pin: release a=unstable
Pin-Priority: 50
--- end cut here ---
enjoy,
-- p
Re:fallback to unstable hack (typo correction) (Score:2, Informative)
if you have a recent version of apt, and you put the following lines into
--- 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)
The distributions which put initscripts in nonstandard places have had to change, those install packages into
And yeah, I'm a Red Hat user who has posted a non 100% supportive comment about Debian in a Debian release news item.
Re:So does alien work reliably yet? (Score:4, Interesting)
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.
There are no `version 4' RPMs (Score:2)
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.
Re:There are no `version 4' RPMs (Score:3, Insightful)
nop@family-values:/tmp$ wget ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i
[...]
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.
Re:There are no `version 4' RPMs (Score:2)
Re:So does alien work reliably yet? (Score:2)
I've not installed too many rpms though....
Debian and Standards (Score:5, Interesting)
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
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
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
Re:Debian and Standards (Score:3)
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.
Re:Debian and Standards (Score:2)
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
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
Theoretically, software developers should only have to release their files as
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
I am heartened to see that you haven't been down modded, I I hope that my post has been informative.
Thankyou.
Mike
-castlan
Re:Debian and Standards (Score:2)
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.
Informative? Its wrong! (Score:2)
Oh well, I guess I was never going to get much of a chance.
Re:So does alien work reliably yet? (Score:2)
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.
Re:So does alien work reliably yet? (Score:2)
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
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.
Re:So does alien work reliably yet? (Score:2)
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.
Re:So does alien work reliably yet? (Score:2)
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
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.
Re:So does alien work reliably yet? (Score:2)
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
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.
Re:So does alien work reliably yet? (Score:2)
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.
Re:So does alien work reliably yet? (Score:2)
Re: my KDE example. If KDE produced a single set of packages against the LSB, and they didn't work on SuSE, then SuSE should fix whatever bug stops these packages from working - because very soon, people will take the attitude that if it isn't LSB, then it isn't Linux.
Re:So does alien work reliably yet? (Score:2)
Why? In some ways, Linux has the best of all possible worlds. It doesn't have the monoculture of Windows or MacOS, where new ideas and new ways never get tested and if you don't like it, there's nothing similar that might fix your bug - if you want to move, you change everything. It beats the proprietary Unixes, in that they all work together in new features and bug fixes, and almost never will a program work on one Linux but not another. With Linux, you have actual choices, without losing everything you liked about the operating system.
Re:So does alien work reliably yet? (Score:2)
Indeed, the Debian policy is similar - is there any reason that it wouldn't be largely portable to RPM? Conectiva (which uses standard packages) already uses Debian policy as a basis for its own packaging guidelines.
Re:So does alien work reliably yet? (Score:2)
Because Debian doesn't allow one to install a standard package and have that package work with ither software. This means a whole bunch if unecessary effort. As I've said earlier, and you've said yourself, policy has nothing to do with rpm or deb. Policy would be applicable to a LSB based Debian as well. In fact, this policy should be moved into the LSB - that's the best place for it. If one distro isn't allowing a et of packages to be installed because it causes some kind of problem, it sounds like all distros could benefit from that information. This should be obvious.
Please note that Debian and therefore DEB is older than Redhat or SuSE, AFAIK.
AFAIK that's not correct, RPM is the older system, but I can't find a URL. Not that age has anything to do with this.
Re:So does alien work reliably yet? (Score:2)
Most of the important Open Source Software is already in Debian. If you miss anything, file a RFP(Request for Packaging) bug against wnpp.
And if one doesn't feel like waiting for that beaurocracy to get it's act together, one could just compile the program themself. Just a thought.
Re:So does alien work reliably yet? (Score:2)
it's reserved for local system administrator use, distributions can't use the directory unless they ask the local sysadmin if its okay to overwrite files that exist there. In other words,
Unix sorts file by type (lib, bin, doc, etc) and always has / will. I can see the advantages of sorting by program, but you don't want to break the exising system like
Re:So does alien work reliably yet? (Score:2)
Why are symlink forests not a solution?
Re:So does alien work reliably yet? (Score:2)
About Time (Score:1)
Re:About Time (Score:3, Informative)
Forgive me... (Score:2)
All but three RC base bugs are belong to us.
:(
-9mm-
Do the packages being yanked out matter? (Score:3, Interesting)
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?
Re:Do the packages being yanked out matter? (Score:2)
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)
Red Hat to Debian (Score:2)
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.
Rsync my ISO's... (Score:2)
But, anyone know if this will be much help going from 2.2r5 to Woody?
Re:Fighting the /. effect. Do not mod up. (Score:1, Funny)
Re:Fighting the /. effect. Do not mod up. (Score:2)
Re:Fighting the /. effect. Do not mod up. (Score:2)
J
Re:Fighting the /. effect. Do not mod up. (Score:2)
Oh well. Won't happen. We must use something version
This is stupid.
Re:Fighting the /. effect. Do not mod up. (Score:3, Funny)
Thanks,
Daniel
[0] or is that inciteful?
update (Re:Fighting the /. effect. Do not mod up.) (Score:3, Interesting)
Obviously Debian is a not a commercial product but if people who did this out of the good of their heart get so sick of the slow release schedule that they are leaving it seems obvious that there are a number of problems. Of course you can say "slashdot troll" and so can I but all criticism of Debian is pretty much ignored. The Debian project is a very insular project that isn't very open to criticism or change.
Those things are pretty obvious from the outside. I don't know what people think of these issues on the inside and frankly I don't really care. All I care about is progress.
The funny part of this whole thread is that I'm replying on a machine running unstable. But the fact is I don't think I'd use Debian on a server. As a sysadmin the core release makes sense but the fact that other non-essential packages like Apache are never upgraded in a release does not. I'd rather run the mainstream release of a package with perhaps only a few modifications for install location than the Debianized patched to hell version.
So I currently run FreeBSD and RedHat (sigh) on my servers. I'd love to run Debian but it simply doesn't make any sense.
Ok, now you can reply with six million reasons why I'm wrong, how this university runs Debian stable on 3,000 boxes, yadda yadda.
Re:update (Re:Fighting the /. effect. Do not mod u (Score:4, Interesting)
You keep bringing this up. Only a few people (less than ten, probably less than five; I don't have an exact count and not all the announcements were public) have left in the last year, and most of those were burn-outs who have continued their involvement with Debian as users. (that is to say, they are still active on the mailing lists and submit bugs/patches; they just don't take on the commitment of maintaining packages, etc) Only one person cited the release schedule as a reason for leaving. That's hardly droves.
Do you really expect 6000 people to be continually happy with everything about the project? I hope you don't think we're the Borg
I also never said I think the release process was perfect; I merely disagreed with what you claimed were the flaws in it.
all criticism of Debian is pretty much ignored. The Debian project is a very insular project that isn't very open to criticism or change.
It's quite hard to take it seriously when most of the criticism is making the same few claims without providing a shred of hard evidence, and when most of the changes suggested are the same one we've heard before.
If people are terse in replying, it's because these specific issues have been discussed for years in gigantic threads already, and the list traffic is high enough that no-one wants to waste more bandwidth on it. The consensus each time has been that the number of packages is a red herring, and we need to look elsewhere for the problems.
Ben Collins recently observed that the "Debian is dying, it has too much bloat" thread has been around, in various forms, since he became involved with the project, and I can say pretty much the same thing. Some people even suggested, only somewhat facetiously, that it's been around ever since Ian realized he couldn't maintain the entire distribution himself
I don't know what people think of these issues on the inside and frankly I don't really care. All I care about is progress.
How admirably utilitarian of you. It also absolves you from making any constructive suggestions that people will listen to..
Oh, and if you want my personal opinion: there have been a lot of technical measures taken to streamline Debian releases in the past year or two. Many people have suggested that woody's long cycle implies that these measures are failures. I personally suspect, although I'm not yet sure I believe, that these measures are responsible for the fact that woody is being *released at all*.
Compared to what I remember from previous releases, the number of coordination problems we've had with coordination and dependency issues does not seem *to me* to have increased proportionally to the package count; in fact, I think it may actually have gone down. (this is all a very fuzzy estimate, and should not be taken particularly seriously)
Automatic dependency checks to ensure an internally consistent "testing" distribution, BTS enhancements for all manner of things, automatic lists of base system bugs [debian.org], continual improvements in the package maintainence tools (debhelper, debconf, lintian, etc)...all of these have addressed particular problems in the distribution. I think that claiming that they didn't work simply because they didn't solve every single problem at once is failing to see the forest for the trees.
And finally, since I said I don't think your explanation is correct, here are some specific things I have seen that probably held things up, based on my personal experience within the Debian Project:
* Effort was diverted from boot-floppies to debian-installer; then, when it appeared that debian-installer wouldn't be releasable in time for woody, it was put on hold and the installation team scrambled to get boot-floppies to work again (since it had since been broken by changes to the base system) We lost at least several months here.
A major problem here (and the reason we want to get rid of boot-floppies) is that the boot-floppies code is fragile and tends to break whenever it is so much as sneezed upon. It's been a culprit in past delays as well.
debian-installer will be used for woody+1, and to hear joeyh talk about it, it's the coolest thing since debhelper
* Many new architectures were added, some at the "last minute". This resulted in many more "interesting" ways that packages can fail to build, especially since the build tools often behave subtly differently on different archs. In some cases, we actually have to use completely separate branches of code! (gcc 2.95, 2.96, and 3.0 are all required for at least one arch, for instance, so all code must compile with all three of them)
(I should add that Debian has probably made a tremendous contribution to the portability of free software in general, simply by building every single program in the archive, no matter how exalted or humble, for architectures the author often never heard of, and submitting patches for the failures)
At the same time, some core packages always seemed to be broken on some obscure arch, generally due to the immaturity of that port of the program. Today g++ wouldn't compile hppa code; tomorrow libc didn't build from source on s390. And the kinds of platform bugs that crop up in these packages tend to be hairy and hard to solve.
* Many maintainers became too busy to maintain their packages (perfectly ok) but left themselves as the official maintainer in the package system (not ok!) This meant that many packages became buggy and went unattended to for far too long before anyone noticed. In fact, this is still a problem, although measures (technical and social) have been and are still being put in place to combat it.
This is the one place where size hurts: with so many maintainers, so-called "MIA"-ness seems to be somewhat inevitable. The main fix here appears to be breaking down the semi-feudal "one maintainer, one package" paradigm that has become ingrained in the distribution.
I think that sums up the major things I have seen slowing the project down, and they're based on hard (or at least firmly mushy
And of course, remember: these are only my personal opinions. I may be wrong, and other maintainers probably disagree violently with me.
Daniel
Re:update (Re:Fighting the /. effect. Do not mod u (Score:2)
6000 people
That should of course be ~1000 at last count.
I was somehow thinking people=packages or something.
Also, I realized it looks like I'm contradicting myself a bit: first "size doesn't matter" and then "technical measures to deal with issues are helping us release.."
Basically, I think that archive size has not been much of a problem precisely because people have been addressing some specific technical problems. Even if they weren't meaning to work on that
Daniel
Re:update (Re:Fighting the /. effect. Do not mod u (Score:2)
Many maintainers became too busy to maintain their packages (perfectly ok) but left themselves as the official maintainer in the package system (not ok!) This meant that many packages became buggy and went unattended to for far too long before anyone noticed. In fact, this is still a problem, although measures (technical and social) have been and are still being put in place to combat it..
I think what led to that insular comment was the general feeling of having the "one maintainer, one package" thing and the problems that result. It sounds like that is being fixed and seeing people say "fix it or I'm going to fix it myself" in terms of abandoned packages is very refreshing...
Oh, and if you want my personal opinion: there have been a lot of technical measures taken to streamline Debian releases in the past year or two. Many people have suggested that woody's long cycle implies that these measures are failures. I personally suspect, although I'm not yet sure I believe, that these measures are responsible for the fact that woody is being *released at all*.
Well as I said in my other post it will be interesting watching the next couple years. Change takes time...
You point out a lot of holes in some arguements that come up fairly regularly here and (it sounds like from your posts) on the debian mailing lists. Definately gives me something to think about. Thanks for posting for what that's worth...
Re:update (Re:Fighting the /. effect. Do not mod u (Score:2)
Because as a sysadmin running mainstream packages is more beneficial to prepackaged things. The combination of Apache+PHP+PostgreSQL/MySQL is far better managed outside of the Debian process. If you can live with PHP 4.0.1 for a couple years than go for it.
The easy solution there is to simply build my own
Funny. The only Linux I allow in my servers is Debian stable.
RedHat wasn't and isn't my choice.
Re:update (Re:Fighting the /. effect. Do not mod u (Score:2)
I trust you but I'll have to look at it myself. At least I can read over the package sources for earlier versions. For some things we can't live with an older version of PHP/Apache/DB. Hard choices...
Sure, sometimes I need a newer version of some package (say, openldap). For those I usually pull the woody source package and build potato binaries. Check this article [debianplanet.org], it explains the basics on doing this trick.
Now that does sound sweet. Thanks for pointing it out.
Re:Fighting the /. effect. Do not mod up. (Score:3, Informative)
Why not? Having precompiled packages that integrate with the system is a very valuable thing to me and many other developers and users.
As for "just the base system"...the primary reason the freeze was held up was because of bugs in the base system, many of them bugs from the upstream source relating to failures on obscure hardware or when using charsets other than the default one.
The primary reason the freeze is now progressing again is because the base system is down to under five "makes the package unsuitable for release" bugs.
Packages not in base or standard will simply be dumped if they aren't ready in time (about two weeks from now), as you'd know if you had read the article.
the fact remains that people are leaving debian, debian is lagging behind, the release process is very slow, etc.
The fact remains that a handful of maintainers have left in the last year due to burnout, the number of Debian maintainers is increasing overall, woody is a very impressive distribution, and it is (at long last) moving towards release.
The fact remains that if you only read
The fact remains that sometimes experience matters, and uninformed opinions are uninformed. "I don't know a thing about aeronautics, engineering, or fluid dynamics, but I've flown on lots of planes, and I have this great idea about how you can make your 747s go faster.."
Everyone has seen the accusation that "all those crufty packages" are holding up the release, it's been discussed dozens of times on the mailing lists, and not one person has yet produced a specific and concrete example of a way in which so-called "package bloat" is holding up the release. Hand-waving arguments, personal attacks, and oblique references to Fred Brooks are easier, I guess. *shrug*
Daniel
Re:Fighting the /. effect. Do not mod up. (Score:2)
So you're saying that the Debian doesn't have a slow release problem? That is only a
The fact remains that sometimes experience matters, and uninformed opinions are uninformed. "I don't know a thing about aeronautics, engineering, or fluid dynamics, but I've flown on lots of planes, and I have this great idea about how you can make your 747s go faster.."
Maybe that is because people are getting so frustrated at a lack of progress in the change that they'll suggest anything... It's easy to shoot people down but I don't really see you coming back with any response besides "this isn't an issue and you aren't fit to question/make suggestions" and ignoring things that are an issue.
Everyone has seen the accusation that "all those crufty packages" are holding up the release, it's been discussed dozens of times on the mailing lists, and not one person has yet produced a specific and concrete example of a way in which so-called "package bloat" is holding up the release. Hand-waving arguments, personal attacks, and oblique references to Fred Brooks are easier, I guess. *shrug*
Maybe part of that is because these people are partly right. FreeBSD has a nice steady release process and the ports system works well. Obviously Debian isn't FreeBSD but it doesn't hurt to look at other ways of doing things.
Anyway, I'm done... I don't think that my critizing is going to help anything. Helping would be much more beneficial. It's just that reality is so frustrating sometimes
Re:Fighting the /. effect. Do not mod up. (Score:2)
I quote you:
the fact remains that people are leaving debian, debian is lagging behind
"people are leaving debian" is sensationalized. See my other post.
And honestly, the "lagging behind" bit is overdramatized in my opinion. 6-month cycles for major new releases are not a necessity, folks.
I was referring more to the "Debian is Dying" overtones, a meme that some people seem to have picked up lately. I don't know where they got it from. Maybe they like the alliteration.
(although I'm not sure
Maybe that is because people are getting so frustrated at a lack of progress in the change that they'll suggest anything
Fine, but it doesn't mean that these repetitive "suggestions" do anything more than clog up the communication channels every time they have to be discarded. (about every three months on average)
It's easy to shoot people down but I don't really see you coming back with any response besides "this isn't an issue and you aren't fit to question/make suggestions" and ignoring things that are an issue.
Likewise, it's easy to make broad claims about what things are serious "issues" without backing them up. When someone does indeed do this, and comes up with the same "new" idea as many other people who are unfamiliar with the situation, I tend to dismiss the comment as coming from a person who doesn't have enough information or experience to assess the situation accurately.
Maybe part of that is because these people are partly right. FreeBSD has a nice steady release process and the ports system works well. Obviously Debian isn't FreeBSD but it doesn't hurt to look at other ways of doing things.
Another explanation is that "for every complex problem, there is a solution which is simple, obvious, straightforward, and wrong"...
Actually, it's you should mention that, because someone started a thread about that just the other day on debian-devel. It's still going; I'm browsing the most recent few messages in another window. Many people in the thread agree that some changes are a good idea, based on the experience of this cycle; however, we can't change the entire process this close to a release.
Personally, I think the closest thing to the "split it up" approach is that we could put out several quick releases on a frozen core -- but changing the core will be a pain anyway, we can't get around that. It's the nature of the core.
And I'm not really convinced this is as simple as it seems. In this area, the devil is generally in the details. Two years ago, we thought "testing" was going to issue in a golden age of quick releases. It really has been a tremendous help (IMO), but it hasn't lived up to some of the overly high expectations that some people had of it.
Daniel
Re:Fighting the /. effect. Do not mod up. (Score:2)
I think for me the best thing to do would be to learn the packaging process and do my own packages for things I can't live without. That would be far more beneficial to myself than whining about crap on
porn-get (Score:1)
Re:Speed of releases (Score:2)
Debian isn't out-of-date (Score:3, Insightful)
Anyone who says Debian is out of date is just wrong.
Re:Speed of releases (Score:2)
Re:random removal? (Score:2)
If you have a package installed which is removed from testing, it will still be installed on your personal machine. ajt won't come to your house and wipe it from your disk
But you won't get upgrades from apt (unless you have it set to download from unstable or the new testing) until or unless the package is placed back into the archive.
Daniel
Re:random removal? (Score:2)
Daniel
Re:random removal? (Score:2)
Whether or not this is a bug or a feature, I won't say.
Re:Wow good to see the light at the end of the tun (Score:2)
Re:Question about Stability (Score:2)
Have you filed bug reports? Dependencies are handled automatically by the build scripts, so it's possible the maintainers haven't noticed those errors.
Re:Question about Stability (Score:2)
Re:Question about Stability (Score:2)
To be fair, there's little new in the idea, although I'd like to think that our implementation is somewhat more advanced
But in reading the posts here, it seems that more people are concerned with the newest fad feature over stability
Because of some unusual situations within the Linux software world, potato's age is more critical than it might otherwise be. Many very useful software packages have been created or have come to maturity in the last year and a half. For instance, the web browser I'm typing this into (galeon) did not exist when potato was released...at least, not in any usable form.
There are interdependencies that are being forced into the installation that are getting very expensive to manage. Examples are: Apache now requires mysql-client to be installed. But it is only used if you are interested in using mysql for authentication. That's a rather heavy handed requirement for a rather specialized function.
I suspect that people who want to use mysql for authentication might differ with you on that
In any event, this dependency seems to have been removed in unstable.
Similarly, I was very happy with emacs until they make a package requirement for XFree86 in order to install emacs.
Ok, you win. You've completely stumped me here. I cannot find an emacs package that depends on an X server. Could you post the control information for that package here so I can put together a bug report?
Oh, in case this is it, depending on xlibs isn't a bug -- the X support in emacs is very useful, and it can't be enabled without this. Having xlibs installed will do nothing to you if you don't install the rest of X.
Now some random general comments:
Things that one person considers bloat are usually a feature request from another person.
Some maintainers compile their package dozens of times, once for each useful combination of compilation options...this lets you be selective about what options you have installed, but tends to (IMO) bloat the archive and package list, and make things confusing for the user. Striking a balance is very difficult, and the only certain thing is that some people will be upset no matter what we do
Daniel
Re:Question about Stability (Score:2)
As I explained in private mail before I checked here, xfree86-common is just a bunch of documentation and skeleton files to support X clients and servers. It doesn't install any programs or configuration, and it doesn't start an X server.
It is being pulled in because xlibs now depends on it, not because of emacs; it is far less bloated than emacs itself; and the X maintainer has a history of making good decisions about his packages, so I presume he did this for a sound reason unless I hear otherwise.
Daniel
Re:Most popular packages? (Score:2)
Daniel