You are not logged in.

#1 2005-01-02 01:42:21

STiAT
Member
From: Vienna, Austria
Registered: 2004-12-23
Posts: 606

Making pacman "better"...

Hello everyone.

Well, i've a small suggestion, making pacman better than any other Package Management System, better than it already is.

Usually, every Package Management System upgrades the Kernel if a new one is available.

Well, let's say the users dont want to upgrade, until ALL their installed depends are solved. So all kernel modules are available for the new kernel version.

I've had the problem lately with the ipw2200 driver. The new kernel was installed, but the ipw2200 module was missing, so i had to recompile it from source...

Every other package management system handles it similar, but what's the advantage of this for the user? None, if i'm right (correct me if i'm wrong).

It would be great, if the kernel doesn't update, till all modules installed are available for the current kernel version.

Just a suggestion... maybe not that easy to develop, but would be good for every "not experienced" user.

STi

PS: please excuse typing mistakes, i've been on a birthday-party before.


Ability is nothing without opportunity.

Offline

#2 2005-01-02 02:43:58

cactus
Taco Eater
From: t͈̫̹ͨa͖͕͎̱͈ͨ͆ć̥̖̝o̫̫̼s͈̭̱̞͍̃!̰
Registered: 2004-05-25
Posts: 4,622
Website

Re: Making pacman "better"...

STiAT wrote:

would be good for every "not experienced" user.

Arch really isn't geared towards the "not experienced" user. This partly accounts for the ability of the system to remain relatively simple and robust. Adding "catch" code for all the things user's could possibly do incorrectly can lead to quite a bit of system bloat.

http://www.archlinux.org/about.php

So, to sum up: Arch Linux is a workhorse distribution designed to fit the needs of the competent linux user.


"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍

Offline

#3 2005-01-02 03:03:43

skoal
Member
From: Frequent Flyer Underworld
Registered: 2004-03-23
Posts: 612
Website

Re: Making pacman "better"...

STiaT, I feel your pain.  But, to illustrate the importance of control over what you choose to upgrade with pacman:

I got burned in the past with a kernel upgrade, not while using Arch however.   From that experience, when the 2.6.9 kernel came out, there were issues with the current nvidia driver.  Well, while everyone else was patching this and that to get the latest kernel on Arch, I waited.  I knew Nvidia would soon follow with an update to remedy the problem with the new kernel release.  It was only about a week after that Nvidia posted a new release to match the kernel.

The moral of that story is: If you want to live on the bleeding edge, be ready to bleed.  And, of course, if it ain't broke, don't fix it.  I forgot how, but there is a way to exclude certain packages from being upgraded when you "pacman -Su".

Actually, that was one feature of "up2date" that I liked on fedora core 3.  It automatically excluded the latest kernel update (by default), unless you told it to do so.  As I say, you can do the same in Arch, and I have before, but I normally don't update that much to remember how, and post it here.  Sorry about that.  Maybe pacman should by default not update the kernel when you "pacman -Su".  I would rather just "pacman -Sy kernel" to get the latest.  So, I think your original post has some merit, and I would welcome something similiar.

Offline

#4 2005-01-02 03:12:59

iBertus
Member
From: Greenville, NC
Registered: 2004-11-04
Posts: 2,228

Re: Making pacman "better"...

You can place the kernel26 package in the IgnorePkg option of pacman.conf. If it isn't there then you can just add it. This will prevent the default behavior of updating the kernel everytime you do a system-wide update.

For example, mine looks like this:
   IgnorePkg=kernel kernel26 xorg

I would, however, like to say that compiling the kernel for your machine is probably better than just using the stock kernel regardless of this distro you're using.

Offline

#5 2005-01-02 03:13:05

Pajaro
Member
Registered: 2004-04-21
Posts: 884

Re: Making pacman "better"...

add this to pacman.conf:

IgnorePkg = kernel26

in order to prevent from upgrading the kernel with a system upgrade

Offline

#6 2005-01-02 03:15:03

Pajaro
Member
Registered: 2004-04-21
Posts: 884

Re: Making pacman "better"...

I also have all my driver packages in IgnorePkg, so I can upgrade them all at once when they all are available

Offline

#7 2005-01-02 03:55:51

cjdj
Member
From: Perth, Western Australia
Registered: 2004-05-07
Posts: 121

Re: Making pacman "better"...

More to the point, it would probably be better to actually set in the driver package that it requires a particular version of the kernel. 

For example, I use wlan-ng26, and when I upgraded to kernel 2.6.10 it got broke because it is specifically compiled against the 2.6.9 headers and actually puts the lib files in the 2.6.9-ARCH folder which is ignored when 2.6.10 is installed.  So the first problem I had was that the kernel couldnt find those modules at all, and then when i moved them over, they didnt work.

So, in summary, if you create a package that uses kernel headers, or create a module that resides in a folder specific for that current kernel version, you should mark that kernel version as a dependency. 

I dont know how easy this is in practice, but it makes sence to me in theory at least.

Offline

#8 2005-01-02 11:14:18

STiAT
Member
From: Vienna, Austria
Registered: 2004-12-23
Posts: 606

Re: Making pacman "better"...

Actually i dont have a problem with this, since i already know quite well what i'm doing.

Anyway, this suggestion was placed because it still annoys me, that i update my kernel, go in my /root where i saved the sources, and recompile it every time the kernel upgrades.
This suggestion was placed, since i dont think "experienced" means that i need to compile several things again after every update.
It would be just a feature, accentuating the Arch package management from other Package Management systems.

I'd rather call someone silly, not experienced, who likes to patch his kernel every time up again, instead of having something simply convenient and good.

STi


Ability is nothing without opportunity.

Offline

#9 2005-01-02 18:36:25

cactus
Taco Eater
From: t͈̫̹ͨa͖͕͎̱͈ͨ͆ć̥̖̝o̫̫̼s͈̭̱̞͍̃!̰
Registered: 2004-05-25
Posts: 4,622
Website

Re: Making pacman "better"...

*shrug*
my setup requires no custom compilation, so I guess I cannot "feel your pain" on this one.
:?


"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍

Offline

#10 2005-01-02 19:28:44

Xentac
Forum Fellow
From: Victoria, BC
Registered: 2003-01-17
Posts: 1,797
Website

Re: Making pacman "better"...

The reason no packages depend on specific kernel versions is because it's our policy to not have any packages depend on any kernel packages at all.

It's our policy to not have any packages depend on any kernel packages so that you have a lot of choice over what you want to do with your kernel (use kernel24, or kernel24-scsi, or something you compiled yourself).


I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal

Offline

#11 2005-01-03 07:18:24

STiAT
Member
From: Vienna, Austria
Registered: 2004-12-23
Posts: 606

Re: Making pacman "better"...

The first answer where i can see a problem smile.

Thank you Xentac.

I'll think some time about the problem...

Will need to take a look at the pacman code.. gonna' play a bit...

STi


Ability is nothing without opportunity.

Offline

#12 2005-01-03 16:24:16

cjdj
Member
From: Perth, Western Australia
Registered: 2004-05-07
Posts: 121

Re: Making pacman "better"...

Xentac wrote:

... because it's our policy to not have any packages depend on any kernel packages at all.

I understand the reason for that in most cases, however in this case, the wlan-ng26 package is specifically compiles for the 2.6 kernel and it installs things in a place that only the 2.6.9 kernel can find it.

Offline

#13 2005-01-04 04:47:47

Xentac
Forum Fellow
From: Victoria, BC
Registered: 2003-01-17
Posts: 1,797
Website

Re: Making pacman "better"...

...unless you rebuild it.


I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal

Offline

#14 2005-01-04 20:33:37

Pajaro
Member
Registered: 2004-04-21
Posts: 884

Re: Making pacman "better"...

In packages that just put a .ko file in the modules dir there's no much trouble in dependencies. I have 3 kernels. Each of them need the same drivers. I keep upgrading every kernel separately. Lots of packages to be build when I can simply type make install, so it is not good for drivers which has no package.

But this behaivour is good as long as there are no compiled drivers packages avaible.

The point is that, in example, having an ndiswrapper package for me is useless, because it don't cares if I build my own kernel in my own dir or if I upgrade the arch official package, and when a new version of the kernel comes out the only way i have to know if the package is for the new kernel version is downloading it and looking at its contents.

So I think that having the package pointing to the kernel version would be good. It's just a little thing, but that would be great that pacman could tell you  that next action will break up your drivers and you will have to build them manually if they've not been released yet as packages.

Offline

#15 2005-01-04 20:53:24

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: Making pacman "better"...

I have to stick my nose in this one too...
I recently screwed up a bit when upgrading to 2.6.10.  For the record, I use the stock kernel.
My laptop wireless requires ndiswrapper, so I have my own custom package.  Now, when building packages like this, I just added a `uname -r` to the directory, so each package I make is for the kernel it's running under....

So the story goes like this:
I upgraded to 2.6.10 then rebooted so I could install nvidia and ndiswrapper... nvidia was fine, considering I had cached it with pacman already (download only) and I was just going to install my ndiswrapper package and "mv" the ko to the new directory... no dice... the kernel interfaces had changed so I had to recompile ndiswrapper.  Luckilly I still had the source in the src directory where I built the package... error, error, error.... aw crap I need to download a new one...

So I went digging through boxes of crap, and after abut 20mins found an ethernet cable....

The moral of the story is... wait... there is no moral....
The reason kernel modules change and are required to change is because the interfaces in the kernel change.  This is by design.  You usually can't copy something like the nvidia module from 2.6.3 to 2.6.9, it just won't work.

This difficulty on my part was my fault.  I should have added kernel26 to my ignore list... this way it won't get lost in a big mush of things... (I seriously didn't know I was upgrading the kernel because when I -Syu'ed I ended up with like 30 packages and 90some MB to download.... I hit yes and closed the laptops).

Offline

#16 2005-01-05 07:21:04

STiAT
Member
From: Vienna, Austria
Registered: 2004-12-23
Posts: 606

Re: Making pacman "better"...

That's exactly what happened to me, and that's basically the reason why i wrote the suggestion.

I of course understand that it's part of the Arch philosophy, anyway, it was and is worth a thought.

After i thought a bit about it:
Some kernel modules definitely depend on specific kernel versions, so why not make them depending on the kernel version? Then there would be also the possibility to reverse-check if any other installed module needs exactly this version, and if there is an upgrade available changing this, so that the kernel can update as well...

Worth a thought... at least in my eyes. Since the fact which phreakture brought up - kernel interfaces can change, you can't for sure say that a module designed for a kernel version will work on the next kernel version as well, just by rebuilding it.

STi


Ability is nothing without opportunity.

Offline

Board footer

Powered by FluxBB