Buggy packages

Gullible Jones · 2004-12-31 17:08:48

No, I am not trolling. Hopefully, you will realize that, and this warning will not be necessary.

First of all: I like Arch Linux. Of all Linux distros, it conforms most closely to what I look for, at least in theory: it uses an up-to-date version 2.6 kernel, has packages that are up-to-date within reason, and has the same sort of "keep it simple" philosophy at its core that made Slackware such a great distro.

But it has problems. Or rather, a problem:

Buggy packages.

Firefox crashes regularly; hotplug lacked a pnp.distmap file until this week and still thinks I have PCI-express (I don't); feh fails to support Fluxbox-devel's pseudotransparency and complains of problems with glibc to boot; XMMS is slow as hell... And applications in general are unstable and finicky. I've been forced to build a surprising number of things myself, not because of the bloat of precompiled optional features, but because of precompiled packages' ridiculous bugginess.

This needs to stop.

Arch is partly source-based; but it is not entirely source-based. I am willing to bet that a lot of Arch users use it because it is not completely source-based - precompiled packages are simply more convenient for those who lack the massive computing power needed for source-based distros.

Therefore, I propose a solution:

Switch package management from Arch's signature .pkg.tar.gz files to Slackware's .tgz files. There are plenty of .tgz packages on the web, and a bunch of repositories; and Slackware complies with UNIX standards, so AFAIK it would be quite possible for Arch Linux to use packages made for Slackware.

And what about the i686 optimization? Well, Slack packages are compiled with -mcpu=i686, and that's fast enough for me folks. And if you really want -march=i686, -O3, or whatever... Well, that's what ABS is for. And if you're not happy enough with ABS... That's what Gentoo is for.

So, what do you think of my suggestion? Is it cool, or does it suck? Don't be afraid to say...

And does the original complaint even apply to you? Is the buggy package problem just a quirk of my aging machine, or perhaps all in my head?

Any criticism is welcome...

i3839 · 2004-12-31 17:53:02

Well, I have zero problems, but I don't use that many apps. May be bad luck for you or something, either with non-working apps on your system, or with broken hardware which causes instability. If you have general unstableness then it's likely that your hardware is flaky.

Your solution doesn't solve anything though, it only moves the responsibility to somewhere else. Crashing programs are buggy programs, which must be fixed by the developers, not the package maintainers. What package format is used is irrelevant. You as user can help find the bugs with writing bugreports when apps don't work. If you don't want to do that then don't use the newest versions, but older ones which have proven to work. If it's really a bug in the Arch package then they should be found and fixed. Again, without user feedback it's impossible to tell if something doesn't work when it does for the package maintainer.

Oh, last time I merely speculated about adding a sort of tool to be able to use Slackware packages with Arch I was flamed and buried alive. The idea was to be able to use more packages, those absent in Arch, avoiding time and energy to maintain them seperately.

miqorz · 2004-12-31 18:22:10

Firefox crashes? I've been using Arch for 3 days without a single buggy package.

Oh, and if Arch ever started to use slackware packages, I'd probably quit using Arch and then linux all together.

Mr Green · 2004-12-31 18:38:04

Just pacmaned in firefox runs fine ... using it now ....

compiled it from ABS still works ok ....

try

pacman -Syu

see if that helps ....

iBertus · 2004-12-31 18:38:51

First, the most important aspect of Arch is pacman and the format it uses to store packages. If you were to eliminate pacman you would destroy the most important single thing that makes Arch simple to use. With no other distro is it possible to generate a package with the same ease as Arch using ABS. Period.

Second, while I will grant you that several packages have been buggy in the past, I haven't had any problems lately that weren't caused by "stupid user syndrome," or my hardware being incompatable with linux. These little problems simply help us further develop as *NIX people.

I used Slackware for a long time before switching to Arch. While I agree that we have a long way to go before being perfect, I would also say that Arch is not intended for that purpose. Perfection is something best left to gods and single-minded cybernetic beings. The Arch philosophy is as close to perfect of any distro that I've ever tried. This user community is dynamic and will respond very quickly to problems.

Also, you should consider filing bug reports for packages that you find any problems with. I'm not saying that there are no problems, but that we can't solve them by looking away from the things that have made this such a great distro.

Gullible Jones · 2004-12-31 19:50:17

Umm... I never said "get rid of pacman". I suppose I should have been more specific though... I was implying that it should be changed so it handles Slackware-type .tgz files.

But anyway, if nobody wants to change pacman or try to compile none-buggy packages, I could always ask for RPM to be included in the "extra" repository.

contrasutra · 2004-12-31 20:22:02

Your suggestion makes no sense. Almost all of Arch's packaging problems are dependency errors. TGZ doesn't even have dependency checking. I suppose that solves the problem . Any other errors can still be present in a TGZ.

Plus many of your problems are not Arch packaging issues. How could Arch's package cause XMMS to be slow? I also have no problems with XMMS, firefox, etc here. I have had firefox and XMMS running for about 2 weeks strait without any complaints or crashes. I have very few packaging problems, and the devs have definitely gotten better recently.

Arch is not a "partial source" distro or anything like that. Arch is 100% a binary distro. Therefore it builds binary packages to suit its needs. Using third party TGZs causes more harm than good. And if we were to switch, DEB would be a better choice, as there's over 10,000 packages available.

So in conclusion, your idea sucks. You don't really know what you're talking about.

Gullible Jones · 2004-12-31 20:38:27

I'm not saying the problem is with the way the packages are packaged. I'm saying that a very large number of Arch packages are buggy, and that a very large number of TGZ packages are not buggy. It's just a proposed solution to the problem of buggy packages.

You're right about TGZ not having dependancy solving, though. I forgot about that little problem courtesy of Swaret... :oops:

But the big problem with Arch right now is that a lot of the packages don't work properly, even with all the dependencies accounted for.

iBertus · 2004-12-31 20:48:46

Okay, so if we *COULD* modify pacman to handle another format that is more popular--what would that get us? I've always said that the linux community needs one universal package format similar to the way we have one accepted x-server (xorg for now), webserver (apache), etc. But for now pacman is the best package system I've found. Even if a package isn't there for download it's very easy to use makepkg to build you're own package. If you have trouble making your own package (which I have from time to time) then you can post on the forum and odds are that one of ubergurus will take time out to make a package for you.

I feel that while maybe you're idea does have some merit, you will never be able to outweight the advantages of using the current system. Also, please list some of the packages that have issues here for us to review. For instance I've found that the new fam package is missing the correct daemon script. Just a minor issue that I was able to fix but still an annoyance. My most serious problem right now is courtisy of ATI and their lack of linux development staff, which I'm sad to say the Arch developers can't help me with.

Gullible Jones · 2004-12-31 21:10:54

- Firefox: crashes randomly. Application terminates, window disappears without a trace. This happens whether or not Flash animations or Java applets are present.

- Kdesktop: crashes upon "loading peripherals". Worked fine once; it may have started doing this upon upgrade. I made no changes to any configuration files.

- Feh: fails to support Fluxbox 0.9.x pseudotransparency, complains of corruption of glibc or somesuch.

- Kaffeine: several dozen error messages up startup, crashes.

- AmaroK: fails to start up; if started from terminal, displays several dozen error messages.

- XMMS-Iris: does not work, displays error message, invariably causes XMMS to crash on startup. Starting XMMS from terminal with Iris plugin enabled results in the "You have probably found a bug in XMMS!" message; it is quite possible that that is the problem, I suppose, and that Arch is not at fault, but I think this bears some investigation.

- Mplayer-plugin: controls do not function, e.g. cannot rewind or stop a movie. (Might it respond to keystrokes but not the mouse? I don't know...)

- Kernel 2.6.9: problem involving PTYs which prevented xterms and other terminals from working; now fixed.

- XMMS: slows down system a good deal, takes a surprising amount of time to start (5-6 seconds) no matter what plugins are used. On other distros I've used, it does not hamper system responsiveness and starts in under 2 seconds. (For comparison, MPlayer starts in only 1 second.)

- ESD: fails to start at all 50% of the time. I haven't found out why; there is little doubt that I would know if I had greater knowledge of Linux, but having no fear of the command line doesn't keep me from being a newbie, so cut me some slack alright?

If you need more, ask me...

johnisevil · 2004-12-31 21:28:45

Reading over this forum, I haven't found a single post like this where anyone has had so many problems. I've been using Arch on this box exclusively since August after switching over from Slackware and I haven't had a single problem. The closest thing to a problem I had was switching from devfsd to udev, that was easily fixed. I'd imagine that I'm using the same versions of software that you are and I'm having no problems whatsoever. I'd go as far to say that Arch is one of the most stable distros I've used. So not only me, but I'm sure many people on this forum can back up what I'm saying. With this many problems with things crashing have you ever considered hardware failure?

iBertus · 2004-12-31 21:36:55

I have had trouble using firefox and mplayer-plugin in the past but now it's working fine. As for the KDE stuff I don't know b/c I use GNOME. I've had this box running Arch for several months with very few problems.

My system is as follows:
- AMD Athlon XP 1800+
- 768MB PC2100 DDR Dual Channel
- Epox 8RDA+ nForce2 Mobo
- ATi Radeon 8500 128MB

xerxes2 · 2004-12-31 22:51:43

as i see it is most of the things jones is whinging about is not arch bugs, i've been running testing for months and the only showstopperbug i had so far was when python went to 2.4 and break backwards compatibility, it took the developers 1-2 days to recompile almost all python stuff,

Gullible Jones · 2004-12-31 22:56:47

My system:

- P3 Katmai 450 MHz
- Intel mobo with Intel 440x chipset (I think) :? (This was a component of the original machine - because of its huge size and unusual design, I couldn't replace it.)
- 6.8 GB Maxtor ATA66 HD, not sure what RPM (noisy little sucker!)
- 384 MB PC100 SDRAM (computer came with only 64 megs)

It sucks, yeah, but a P3 should have no problems at all with -march=i686...

(Hmm. Arch packages are compiled with -march=i686 -O2, aren't they - like the default for makepkg?)

Pajaro · 2005-01-01 13:52:13

amarok works fine, xmms is not slow, firefox crashes sometimes, but I think that it is when it tries to use gxine plugin, the mplayer plugin works fine. kdesktop crashes only when I play half-life with cedega. I don't use the other packages.

I've also had some problems with arch but finally i found that they were hardware related. My mobo was curved :shock:

iBertus · 2005-01-01 17:29:38

-march=i686 -O2 should work just fine with that setup as far as I can tell.

sarah31 · 2005-01-01 19:09:03

why not just go back to slackware if it is so much more stable for you?

I ran some of those packages you mentioned without difficulty for over three years.

Have you also ever considered thhat the "bugs" may be upstream and your precious and dead slackware may have known this and patched for it?

While Arch definitely suffers bouts of poor builds it is not full of buggy packages as you infer. If it is it is because people are not filing bug reports.

Having Arch accept .tgz packages is not a solution. There is no guarnetee that package would work becuase there are difference in filesystem setup between Arch and Hackware. It is a square peg in a round hole solution.

Not intending to be rude either go back to slackware or offer your assistance to fix "all the buggy packages" by filing bugs or recommending known fixes. You should also be suure that bug are not upstream issues. Slackware didn't become infallible by people bitching to people, such as the majority of us forum useres, who have zero ability to change development issues.

If you also look around these problems you are having are not universal so it could be a local issue (ie some hardware problem not yet full blown but starting).

skoal · 2005-01-03 00:58:41

Gullible Jones wrote:

[..]Buggy packages.[..]

Myth #1: Windows or commercial packages are bug free.
Myth #2: Certain Linux distribution packages are bug free.
Myth #3: Open Source software has far fewer bugs than commercial ones.
Myth #4: Dedicated teams of testers & a horde of MIT graduate level CS students have bug free source.
Myth #5: This scripting language or that programming language is less prone to bugs.
[...] ad infinitum

When has anyone since the dawn of ENIAC witnessed a bug free app? Even Thomas Edison theorized ~1870 that all electronic circuits are prone to bugs, by design or by accident.

I guess I find this whole thread laughable to say the least, but mildly entertaining (since I'm gullible enough to post in it).

Open source software is inherently dynamic and in constant motion. It's main advantage is speed in addressing bugs as they are discovered. It's inherit flaw is that most developers rely on outside sources of development, and vice-a-versa. Syncing different layers of compatability between dependent external sources is nothing short of spectacular.

But, in all fairness to this thread, I experience far far fewer unpredictable bugs while using Arch than I did with Windows, Red Hat, et al. However, I barely blink an eye when my browser closes unexcpectadly, or an XMMS song skips while a cron task fires off in the background. I guess when you use computers, it's expected, within reason. But, isn't that obvious?....Maybe one day, when the fellers at AT&T labs finish the crystal lattice optical computing device, a "100% stable, bug-free" sticker can be slapped on every application....(hUuUUuUUUhhhhhh!)

...

(huHHHHhhhHhhhhh...) Whew! 11 whole seconds that time. I'm getting a little better at this "holding your breath" thingy...

Pajaro · 2005-01-03 13:08:00

google people made a conference in barcelona where they explained what think the do to aviod with software unavoidable hardware bugs.

Quantics are based in provability, and nowadays computers are based on quantics, so what can you espect of a computer?

JGC · 2005-01-08 00:00:05

Gullible Jones wrote:

My system:
- P3 Katmai 450 MHz
- Intel mobo with Intel 440x chipset (I think) :? (This was a component of the original machine - because of its huge size and unusual design, I couldn't replace it.)
- 6.8 GB Maxtor ATA66 HD, not sure what RPM (noisy little sucker!)
- 384 MB PC100 SDRAM (computer came with only 64 megs)
It sucks, yeah, but a P3 should have no problems at all with -march=i686...
(Hmm. Arch packages are compiled with -march=i686 -O2, aren't they - like the default for makepkg?)

I think it's your harddisk. I happened to have one of those sucky maxtor 5400RPM ATA66 disks of that age and the only thing it did was resetting my IDE bug while I was compiling a kernel that supports ext3 while I still had ext2 after a debian woody install (hell yeah how nice, throw a brick on the "Y" key after rebooting, fsck will be nice to you )

I can confirm firefox can be flaky, this is caused by freetype issues. I'm working on new packages that should go with the 0.7 release. With the three of them they close something like 15-20 bugs :X

scarecrow · 2005-01-24 20:35:01

Firefox never crashes here, and the only problems are java (javaws not working- but this is a registered Sun bug, not an Arch one) and mplayer which is unable to find VCD's and DVD's (might be because I don't use dbus/hal - yet!). Everything else is working fine, and the bugs (if you stick to release/current/extra) are just a small fraction of the ones I encountered before on the Mandrake "Official" releases. I can understand that Slackware or Debian Woody have less bugs, but they trail regarding package age a hell of a lot.

IceRAM · 2005-01-25 09:36:16

Gullible Jones wrote:

My system:
- P3 Katmai 450 MHz
- Intel mobo with Intel 440x chipset (I think) :? (This was a component of the original machine - because of its huge size and unusual design, I couldn't replace it.)
- 6.8 GB Maxtor ATA66 HD, not sure what RPM (noisy little sucker!)
- 384 MB PC100 SDRAM (computer came with only 64 megs)
It sucks, yeah, but a P3 should have no problems at all with -march=i686...
(Hmm. Arch packages are compiled with -march=i686 -O2, aren't they - like the default for makepkg?)

Hey.. I had the same computer (but a 8.5GB HDD) running Arch (Xorg, KDE...)..
I actually.. still have that PC... it's my gateway... it plays as a router in my LAN... still running Arch... only 128 RAM... and it's stable.

My current computer uses a copy (yes, cp -R) of that system + lots of 'pacman -Syu's... and it's stable too...

Arch Linux

#1 2004-12-31 17:08:48

Buggy packages

#2 2004-12-31 17:53:02

Re: Buggy packages

#3 2004-12-31 18:22:10

Re: Buggy packages

#4 2004-12-31 18:38:04

Re: Buggy packages

#5 2004-12-31 18:38:51

Re: Buggy packages

#6 2004-12-31 19:50:17

Re: Buggy packages

#7 2004-12-31 20:22:02

Re: Buggy packages

#8 2004-12-31 20:38:27

Re: Buggy packages

#9 2004-12-31 20:48:46

Re: Buggy packages

#10 2004-12-31 21:10:54

Re: Buggy packages

#11 2004-12-31 21:28:45

Re: Buggy packages

#12 2004-12-31 21:36:55

Re: Buggy packages

#13 2004-12-31 22:51:43

Re: Buggy packages

#14 2004-12-31 22:56:47

Re: Buggy packages

#15 2005-01-01 13:52:13

Re: Buggy packages

#16 2005-01-01 17:29:38

Re: Buggy packages

#17 2005-01-01 19:09:03

Re: Buggy packages

#18 2005-01-03 00:58:41

Re: Buggy packages

#19 2005-01-03 13:08:00

Re: Buggy packages

#20 2005-01-08 00:00:05

Re: Buggy packages

#21 2005-01-24 20:35:01

Re: Buggy packages

#22 2005-01-25 09:36:16

Re: Buggy packages

Board footer