Loving Arch - some comments

tomk · 2005-01-19 11:42:16

Arch is now my preferred distro on my laptop - I haven't booted into Debian in weeks, after being a strictly-Debian user for more than two years. I love Arch's simplicity - rc.conf and pacman being the two major examples here. I still have some reservations, which everyone is free to ignore completely, of course!

1. Kernel upgrades - I have added

IgnorePkg = kernel26

to my pacman. conf, because I don't believe in handling kernel upgrades in the same way as other packages. Changing from 2.6.7 to 2.6.8, for example, should be a conscious and considered decision by the user, not something that happens automatically during a pacman -Syu. I always use customised kernels, but even with the Arch standard kernels, I wouldn't feel happy with the current approach.

2. Dependencies - I'm open to correction here, but AFAICS Arch packages are built with every possible dependency made compulsory. For example, I installed the bluefish package recently and as a bonus(!), got many MBs of gnome and other stuff as well. Now I know that some of it is necessary, but nobody is going to convince me that hal and dbus, useful though they might be, are necessary to run a HTML editor. I see that another user has repackaged bluefish here without gnome, so it seems I'm not alone here.

Both the above issues seem to me to go against Arch's principles as I understand them i.e. giving the user choice, and the necessary information to configure their own system.

Let me say again that I love Arch, and I would hope that my comments will be viewed as constructive.

xerxes2 · 2005-01-19 13:29:59

your point nr1 is straight on mr, I always have a few homemade kernels also just in case, it's just too much of a risk to upgrade your kernel if you don't have another one just in case, the last months I've not had arch stock kernel installed either,

ravster · 2005-01-19 15:39:56

Amen, I don't use the stock kernel either(I let it upgrade, but compile my own ones). As for the required dependencies issue, I think there was a talk(somewhat) earlier about making a distinction between required dependencies and dependencies that would allow for extra functionality in progs.

BlackFenix · 2005-01-19 16:11:04

Maybe a "sugestion" section in PKGBUILD can resolve it.

sarah31 · 2005-01-19 16:39:33

With respect to number 2 arch packages are NOT built with every dependency listed. Bluefish is maintained by someone who decided to bloat the crap out of it and thus the dependencies in that package. Some other maintainers do have more complete lists than others but the idea is not to do it the Debian way (I used Deb and i know that one of the things that drove me nuts was how much useless crap you could haul in and out with simple packages). If you install all of the arch packages and ran ldd on the binaries you would indeed find that #2 is completely incorrect.

You will also note that the experieinced maintainers know the difference in their deopendencies to know which are modular (not needed at run time unless you want that feature), build, and actual runtime depends. I have often heavily criticized developers for unnecessarily bloating the depends of applications (ie. i have bitched about bluefish, sylpheed-claws, transcode, and others). Despite this if you look at the builds you will see that you are incorrect in your criticism

As for #1 that is a preference but I know there are just as many that use stock kernels and have no issues with them being part of a wholesale upgrade. Even if they have some reservations about the kernel being a part of a wholesale upgrade but still want a stock kernel and have it installed by pacman they can always install the kernel first with pacman -S kernel. Ignorepkg or not even having a kernel package at all is up to the user and all the features in pacman are there if you have that option.
In preference matters like this it is better to go with what the majority would likely want and most people do not want to deal with customizing their kernel.

I used a stock kernel and I preferred it that way. For the time I had put into farting around with kernel option for those few mircoseconds it just wasn't worth it. You and others may like it and may have had bad luck with stock kernels but many don't (probably more) and trying to impose your desires on them is just not good. I would have ditched Arch without a second glance if I had to go through the bother of farting around with my kernel.

woodstock · 2005-01-19 17:41:23

Sarah31: I agree with your point in respect to the kernel issue. That's the beauty of Arch. You can set it up the way you like and that's that.

As for the dependancies, well... I agree that the more experienced dev's know the difference between runtime,build and modular deps. I just disagree with the fact that doing something similarly to Debian would be considered the Debian way. It would just be, similar.

I have been playing with Debian on a spare partion for about a year now and I'm pretty much finished playing with it, infact I have been for a long while. I keep it there because I feel Arch can learn from others and Debian is in the same field of package management, with its differences of course. I think that maybe doing something like having Required(), Suggested(), and Obsolete() fields in the PKGBUILDS would increase flexibility, at least that's what I think. Of course though, this adds a layer of complexity which goes against Arch's way (philosophy).

Anyway, to Tomk, welcome to the wonderful world of Arch. I hope you enjoy your stay .

Off-topic* - The Obsolete() field is something that I think is needed though. Take the example of the new Xfce4 packages. Instead of pacman removing the obsolete packages that are no longer needed by Xfce4 in the new release you have to Pacman -Syu the original and then remove the deprecated peices manually... not a problem, but it should be done automatically. Eeew I hate cruft.

sarah31 · 2005-01-19 18:25:18

woodstock wrote:

As for the dependancies, well... I agree that the more experienced dev's know the difference between runtime,build and modular deps. I just disagree with the fact that doing something similarly to Debian would be considered the Debian way. It would just be, similar.

Debian has A nice package manager but the issues I have with it that I never have on other distros is that many packages had too many dependencies. I remember one time I was using Gnome on Libranet and I wanted to remove a simple app that was maybe 200K in size and to remove it I would have taken all of gnome with it. THAT is overdependency since I KNOW the package did not need to have to be that interconnected dependency wise. That is what I meant by handling dependeencies the Debian way.

I think that maybe doing something like having Required(), Suggested(), and Obsolete() fields in the PKGBUILDS would increase flexibility, at least that's what I think. Of course though, this adds a layer of complexity which goes against Arch's way (philosophy).

Required is moot that is what Depends "should" contain. Suggested is very difficult to handle. Packages designed to be modular such a transcode are a bit hard to deal with. Having a Suggested field where a generic message gets piped into the install output is really not enough though about the only way to handle such "depends". ALOT of people pay little heed to their installation output so most of the time people will miss the warnings. Besides modular packages are so few and far between that having a separate field and more lines of code in pacman is just bloating it.

Handling piped info with a .install file works too because pacman is already set to handle such a set-up. The problem, again, is that this all gets piped in in the installation output which few really pay attention to.

Obsolete is not really needed either there are are fields that already handle this it is a matter of using them. Obviously with XFCE the maintainer could not figure out how to do this properly so left it as largely a manual task. In those cases a documented news article on the frontpage should handle this. I do remember that Debian was also pretty damn bad at leaving kruft like this behind with no easy way of removing it without fubarring the newly installed version.

Ultrimately how packages handle dependencies can be fixed by those who are more knowledgable providing the information to the maintainers via a bug report. The idea is to have absolute minimal runtime depends as possible but the maintainers might not realize just how minimal they can go (sometimes I think that they may rely too much on info from such apps as namcap).

woodstock · 2005-01-19 18:35:31

OOOOHH dur.. haha I should have just remembered that instead of making an ass of myself, lol.

Required(),Suggested() are useless, because like you mentioned Depends() already handles this.

Now for the Obsolete() field, does that Replaces() char work in the same way? I have yet to have to use it.

Debian has A nice package manager but the issues I have with it that I never have on other distros is that many packages had too many dependencies. I remember one time I was using Gnome on Libranet and I wanted to remove a simple app that was maybe 200K in size and to remove it I would have taken all of gnome with it. THAT is overdependency since I KNOW the package did not need to have to be that interconnected dependency wise. That is what I meant by handling dependeencies the Debian way.

You make a very good point here. This was and is something that is quite annoying with Debians packaging practice. I think its the Debian version of USE flags that Gentoo has, not as flexible though, but still works in a way. Both IMHO lead to headaches.

Ultrimately how packages handle dependencies can be fixed by those who are more knowledgable providing the information to the maintainers via a bug report. The idea is to have absolute minimal runtime depends as possible but the maintainers might not realize just how minimal they can go (sometimes I think that they may rely too much on info from such apps as namcap).

Yes, from my own experiences I found that namcap should only be used to give you an idea but shouldn't be relied on.

Thanks for your input, highly appreciated.

neotuli · 2005-01-20 01:59:29

By the sounds of this thread... I the only one [in]sane enough to pick "NONE" when the installer asked about a kernel.

I always use my own home-cooked ones.

Xentac · 2005-01-20 02:05:27

Why IgnorePkg = kernel26 if you're not even going to use it? Just uninstall the package.

aha · 2005-01-20 08:14:37

I also use a custom kernel.
Not because I am against stock kernel or something, but because bios on my Laptop is broken. So, stock kernel acpi dosn't work. I have to compile fixed bios firmware with the kernel to make acpi work.

And this is the beauty of Arch. you don't like stock kernel, fine, you have ABS. Make a PKGBUID according to your need and use your custom made package.

tomk · 2005-01-21 11:23:37

sarah31 wrote:

If you install all of the arch packages and ran ldd on the binaries you would indeed find that #2 is completely incorrect.

Good to know Sarah - thanks. I obviously picked a bad example.

sarah31 wrote:

As for #1 that is a preference

Absolutely.

sarah31 wrote:

In preference matters like this it is better to go with what the majority would likely want and most people do not want to deal with customizing their kernel.

Nor am I suggesting that everyone should. It is my preference that the kernel should be handled separately from other packages, and I thought I would see what others think.

sarah31 wrote:

You and others may like it and may have had bad luck with stock kernels but many don't (probably more) and trying to impose your desires on them is just not good.

Like I said, Sarah, these are some comments - I'm not trying to impose anything on anyone, nor would I want to.

woodstock wrote:

Anyway, to Tomk, welcome to the wonderful world of Arch. I hope you enjoy your stay .

Thanks woodstock - I fully intend to.

neotuli wrote:

I the only one [in]sane enough to pick "NONE" when the installer asked about a kernel.

Interesting - but on a new installation, don't you need a kernel to compile a kernel?!

Xentac wrote:

Why IgnorePkg = kernel26 if you're not even going to use it?

DOH! Thanks Xentac. Arch newbie here - what can I say?

iBertus · 2005-01-22 02:10:27

I compile and use my own kernels, with patches here and there, but I use ABS with a package name like kernel26-custom. This makes keeping the system well sorted with lots of kernels laying around much easier. Plus, I always package the source to my kernel with the package for easy access later on.

I've given thought to the Arch kernel and wish agpgart was compiled as a module instead of into the kernel. This causes problems when trying to use a 3rd party AGP module. For instance, the nVidia AGP driver refuses to work on an Arch default kernel because agpgart is not a module and thus conflicts with the nVidia driver. Also, the ATI driver docs mention something about requiring agpgart to be built as a module.

neotuli · 2005-01-22 02:19:50

tomk wrote:

Interesting - but on a new installation, don't you need a kernel to compile a kernel?!

I've got one I compiled on another machine, for the new machine, somewhere on a CD or floppy.
I might also add that the vanilla kernels don't know that I have a harddrive due to lack of support for my ITE8212 chip, so I had to pre-cook an AC kernel, as well as modify the install cd's kernel, so that I could get it all installed and working.

Arch Linux

#1 2005-01-19 11:42:16

Loving Arch - some comments

#2 2005-01-19 13:29:59

Re: Loving Arch - some comments

#3 2005-01-19 15:39:56

Re: Loving Arch - some comments

#4 2005-01-19 16:11:04

Re: Loving Arch - some comments

#5 2005-01-19 16:39:33

Re: Loving Arch - some comments

#6 2005-01-19 17:41:23

Re: Loving Arch - some comments

#7 2005-01-19 18:25:18

Re: Loving Arch - some comments

#8 2005-01-19 18:35:31

Re: Loving Arch - some comments

#9 2005-01-20 01:59:29

Re: Loving Arch - some comments

#10 2005-01-20 02:05:27

Re: Loving Arch - some comments

#11 2005-01-20 08:14:37

Re: Loving Arch - some comments

#12 2005-01-21 11:23:37

Re: Loving Arch - some comments

#13 2005-01-22 02:10:27

Re: Loving Arch - some comments

#14 2005-01-22 02:19:50

Re: Loving Arch - some comments

Board footer