More NetworkManager related update problems

[Chris Adams]

There is an update to wireless-tools in updates-released, but
NetworkManager blocks it because it is linked against libiw.so.27 and
the new wireless-tools provides libiw.so.28.

yum doesn't handle this problem very well either:

************************************************************************
$ yum update -y
Transaction Check Error:   package wireless-tools-27-0.pre25.3 (which is newer than
wireless-tools-27-0.pre25.2) is already installed
  file /sbin/ifrename conflicts between attempted installs of wireless-tools-27-0.pre25.2
and wireless-tools-28-0.pre4.1.fc3
  file /sbin/iwconfig conflicts between attempted installs of wireless-tools-27-0.pre25.2
and wireless-tools-28-0.pre4.1.fc3
  file /sbin/iwevent conflicts between attempted installs of wireless-tools-27-0.pre25.2
and wireless-tools-28-0.pre4.1.fc3
  file /sbin/iwgetid conflicts between attempted installs of wireless-tools-27-0.pre25.2
and wireless-tools-28-0.pre4.1.fc3
  file /sbin/iwlist conflicts between attempted installs of wireless-tools-27-0.pre25.2
and wireless-tools-28-0.pre4.1.fc3
  file /sbin/iwpriv conflicts between attempted installs of wireless-tools-27-0.pre25.2
and wireless-tools-28-0.pre4.1.fc3
  file /sbin/iwspy conflicts between attempted installs of wireless-tools-27-0.pre25.2 and
wireless-tools-28-0.pre4.1.fc3
  file /usr/include/iwlib.h conflicts between attempted installs of
wireless-tools-27-0.pre25.2 and wireless-tools-28-0.pre4.1.fc3
  file /usr/include/wireless.h conflicts between attempted installs of
wireless-tools-27-0.pre25.2 and wireless-tools-28-0.pre4.1.fc3
  file /usr/lib/libiw.so conflicts between attempted installs of
wireless-tools-27-0.pre25.2 and wireless-tools-28-0.pre4.1.fc3
  file /usr/share/man/man5/iftab.5.gz conflicts between attempted installs of
wireless-tools-27-0.pre25.2 and wireless-tools-28-0.pre4.1.fc3
  file /usr/share/man/man8/ifrename.8.gz conflicts between attempted installs of
wireless-tools-27-0.pre25.2 and wireless-tools-28-0.pre4.1.fc3
  file /usr/share/man/man8/iwconfig.8.gz conflicts between attempted installs of
wireless-tools-27-0.pre25.2 and wireless-tools-28-0.pre4.1.fc3
  file /usr/share/man/man8/iwevent.8.gz conflicts between attempted installs of
wireless-tools-27-0.pre25.2 and wireless-tools-28-0.pre4.1.fc3
  file /usr/share/man/man8/iwgetid.8.gz conflicts between attempted installs of
wireless-tools-27-0.pre25.2 and wireless-tools-28-0.pre4.1.fc3
  file /usr/share/man/man8/iwspy.8.gz conflicts between attempted installs of
wireless-tools-27-0.pre25.2 and wireless-tools-28-0.pre4.1.fc3
Setting up Update Process
Setting up Repo:  base
Setting up Repo:  updates-released
Reading repository metadata in from local files
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package wireless-tools.i386 1:28-0.pre4.1.fc3 set to be updated
--> Running transaction check
--> Processing Dependency: libiw.so.27 for package: NetworkManager
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package wireless-tools.i386 1:27-0.pre25.2 set to be updated
--> Running transaction check

Dependencies Resolved
Transaction Listing:
  Update: wireless-tools.i386 1:28-0.pre4.1.fc3

Performing the following to resolve dependencies:
  Update: wireless-tools.i386 1:27-0.pre25.2
Downloading Packages:
Running Transaction Test
Finished Transaction Test
$ 
************************************************************************

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Dan Williams]

NetworkManager is getting rebuilt against libiw.so.28.

Dan

On Tue, 2005-01-18 at 08:44 -0600, Chris Adams wrote:
>  There is an update to wireless-tools in updates-released, but
>  NetworkManager blocks it because it is linked against libiw.so.27 and
>  the new wireless-tools provides libiw.so.28.
>  
>  yum doesn't handle this problem very well either:
>  
>  ************************************************************************
>  $ yum update -y
>  Transaction Check Error:   package wireless-tools-27-0.pre25.3 (which is newer than
> wireless-tools-27-0.pre25.2) is already installed
>    file /sbin/ifrename conflicts between attempted installs of wireless-tools-27-0.pre25.2
> and wireless-tools-28-0.pre4.1.fc3
>    file /sbin/iwconfig conflicts between attempted installs of wireless-tools-27-0.pre25.2
> and wireless-tools-28-0.pre4.1.fc3
>    file /sbin/iwevent conflicts between attempted installs of wireless-tools-27-0.pre25.2
> and wireless-tools-28-0.pre4.1.fc3
>    file /sbin/iwgetid conflicts between attempted installs of wireless-tools-27-0.pre25.2
> and wireless-tools-28-0.pre4.1.fc3
>    file /sbin/iwlist conflicts between attempted installs of wireless-tools-27-0.pre25.2
> and wireless-tools-28-0.pre4.1.fc3
>    file /sbin/iwpriv conflicts between attempted installs of wireless-tools-27-0.pre25.2
> and wireless-tools-28-0.pre4.1.fc3
>    file /sbin/iwspy conflicts between attempted installs of wireless-tools-27-0.pre25.2
> and wireless-tools-28-0.pre4.1.fc3
>    file /usr/include/iwlib.h conflicts between attempted installs of
> wireless-tools-27-0.pre25.2 and wireless-tools-28-0.pre4.1.fc3
>    file /usr/include/wireless.h conflicts between attempted installs of
> wireless-tools-27-0.pre25.2 and wireless-tools-28-0.pre4.1.fc3
>    file /usr/lib/libiw.so conflicts between attempted installs of
> wireless-tools-27-0.pre25.2 and wireless-tools-28-0.pre4.1.fc3
>    file /usr/share/man/man5/iftab.5.gz conflicts between attempted installs of
> wireless-tools-27-0.pre25.2 and wireless-tools-28-0.pre4.1.fc3
>    file /usr/share/man/man8/ifrename.8.gz conflicts between attempted installs of
> wireless-tools-27-0.pre25.2 and wireless-tools-28-0.pre4.1.fc3
>    file /usr/share/man/man8/iwconfig.8.gz conflicts between attempted installs of
> wireless-tools-27-0.pre25.2 and wireless-tools-28-0.pre4.1.fc3
>    file /usr/share/man/man8/iwevent.8.gz conflicts between attempted installs of
> wireless-tools-27-0.pre25.2 and wireless-tools-28-0.pre4.1.fc3
>    file /usr/share/man/man8/iwgetid.8.gz conflicts between attempted installs of
> wireless-tools-27-0.pre25.2 and wireless-tools-28-0.pre4.1.fc3
>    file /usr/share/man/man8/iwspy.8.gz conflicts between attempted installs of
> wireless-tools-27-0.pre25.2 and wireless-tools-28-0.pre4.1.fc3
>  Setting up Update Process
>  Setting up Repo:  base
>  Setting up Repo:  updates-released
>  Reading repository metadata in from local files
>  Resolving Dependencies
>  --> Populating transaction set with selected packages. Please wait.
>  ---> Package wireless-tools.i386 1:28-0.pre4.1.fc3 set to be updated
>  --> Running transaction check
>  --> Processing Dependency: libiw.so.27 for package: NetworkManager
>  --> Restarting Dependency Resolution with new changes.
>  --> Populating transaction set with selected packages. Please wait.
>  ---> Package wireless-tools.i386 1:27-0.pre25.2 set to be updated
>  --> Running transaction check
>  
>  Dependencies Resolved
>  Transaction Listing:
>    Update: wireless-tools.i386 1:28-0.pre4.1.fc3
>  
>  Performing the following to resolve dependencies:
>    Update: wireless-tools.i386 1:27-0.pre25.2
>  Downloading Packages:
>  Running Transaction Test
>  Finished Transaction Test
>  $ 
>  ************************************************************************
>  
>  -- 
>  Chris Adams <cmadams(a)hiwaay.net&gt;
>  Systems and Network Administrator - HiWAAY Internet Services
>  I don't speak for anybody but myself - that's enough trouble.
>

[Jef Spaleta]

On Tue, 18 Jan 2005 08:44:23 -0600, Chris Adams <cmadams(a)hiwaay.net&gt; wrote:
>  There is an update to wireless-tools in updates-released, but
>  NetworkManager blocks it because it is linked against libiw.so.27 and
>  the new wireless-tools provides libiw.so.28.
>  
>  yum doesn't handle this problem very well either: 
yum handles the problem just fine..... 
yum tries to resolve the deps... there are conflicting deps so yum fails. 

What would you prefer yum do?  Install a package in a way that causes
a broken dep chain inside your rpm database? If the deps can't be met
without causing conflicts, yum tells you and stop processing, how is
this not correct behavior when there really is a broken dep in the
repo tree?

This issue is already filed AND the developer has responded saying a
new NetworkManager package is being built.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145395

I'm not sure how constructive it is to post this to test-list when the
developer already knows about the problem and has stated in bugzilla
that action to fix it is underway.

-jef"really wishes wireless-tools would have shown up in
updates-testing first, so this problem would have been caught by
competent proactive fc3 users who know how to file bug-reports as a
first line response to packaging breakages"spaleta

[seth vidal]

On Tue, 2005-01-18 at 10:03 -0500, Jeff Spaleta wrote:
>  On Tue, 18 Jan 2005 08:44:23 -0600, Chris Adams
> <cmadams(a)hiwaay.net&gt; wrote:
>  > There is an update to wireless-tools in updates-released, but
>  > NetworkManager blocks it because it is linked against libiw.so.27 and
>  > the new wireless-tools provides libiw.so.28.
>  > 
>  > yum doesn't handle this problem very well either:
>  
>  yum handles the problem just fine..... 
>  yum tries to resolve the deps... there are conflicting deps so yum fails. 
>  
>  What would you prefer yum do?  Install a package in a way that causes
>  a broken dep chain inside your rpm database? If the deps can't be met
>  without causing conflicts, yum tells you and stop processing, how is
>  this not correct behavior when there really is a broken dep in the
>  repo tree? 
To be fair it's a case I should be checking for in yum. 

 if a package is already in the ts and it's not one of the packages that
can be installed multiple times:
  raise an error and/or cause problems.


-sv

[Jef Spaleta]

On Tue, 18 Jan 2005 10:06:36 -0500, seth vidal <skvidal(a)phy.duke.edu&gt; wrote:
>   if a package is already in the ts and it's not one of the
> packages that
>  can be installed multiple times:
>    raise an error and/or cause problems. 
Are you relying on a special magic list to determine 'can be installed
multiple times'  here?
Or do you do this as part of the depresolving loops to check to see if
a package conflicts with versions of itself?

-jef

[seth vidal]

On Tue, 2005-01-18 at 10:36 -0500, Jeff Spaleta wrote:
>  On Tue, 18 Jan 2005 10:06:36 -0500, seth vidal
> <skvidal(a)phy.duke.edu&gt; wrote:
>  >  if a package is already in the ts and it's not one of the packages that
>  > can be installed multiple times:
>  >   raise an error and/or cause problems.
>  
>  Are you relying on a special magic list to determine 'can be installed
>  multiple times'  here?
>  Or do you do this as part of the depresolving loops to check to see if
>  a package conflicts with versions of itself?
>   
magical list already existent and two provides statements in the
packages:
 Provides: kernel
 Provides: kernel-module

-sv

[Brian Millett]

On Tue, 2005-01-18 at 10:03 -0500, Jeff Spaleta wrote:
>  On Tue, 18 Jan 2005 08:44:23 -0600, Chris Adams
> <cmadams(a)hiwaay.net&gt; wrote:
>  > There is an update to wireless-tools in updates-released, but
>  > NetworkManager blocks it because it is linked against libiw.so.27 and
>  > the new wireless-tools provides libiw.so.28.
>  > 
>  > yum doesn't handle this problem very well either:
>  
>  yum handles the problem just fine..... 
>  yum tries to resolve the deps... there are conflicting deps so yum fails. 
>  
>  What would you prefer yum do?  Install a package in a way that causes
>  a broken dep chain inside your rpm database? If the deps can't be met
>  without causing conflicts, yum tells you and stop processing, how is
>  this not correct behavior when there really is a broken dep in the
>  repo tree?
>  
>  This issue is already filed AND the developer has responded saying a
>  new NetworkManager package is being built.
>  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145395
>  
>  I'm not sure how constructive it is to post this to test-list when the
>  developer already knows about the problem and has stated in bugzilla
>  that action to fix it is underway.
>  
>  -jef"really wishes wireless-tools would have shown up in
>  updates-testing first, so this problem would have been caught by
>  competent proactive fc3 users who know how to file bug-reports as a
>  first line response to packaging breakages"spaleta
>   
Jeff, you must be having a bad day.  I would normally not even respond
to this type of message, but you seem to be doing this a lot.
  
Your response to a posting for a problem that happen just this morning
is just rude.  We do not have the insight that you do to know that a
developer is working on a problem "right now".   I just did a cvs
checkout of the NetworkManager.  Compiled and installed it.  Guess what?
The same problem exists because I was stupid to not rpm -e
NetworkManager before installing from source.  But if I did that, then I
would not know of other dependencies that could happen.  I'm learning,
slowly, but I'm learning. 

If I wanted abuse, then I'd go down the hallway to the abuse department.

--
Brian Millett - [ Londo and G'Kar, "By Any Means Necessary"]
"50,000 commercial credits, in cash, in advance."
'That's an outrage!'
"Of course, it's an outrage. The question is, how important is your
religious ceremony to you?"

[seth vidal]

>  Jeff, you must be having a bad day.  I would normally not even
> respond
>  to this type of message, but you seem to be doing this a lot.
>    
>  Your response to a posting for a problem that happen just this morning
>  is just rude.  We do not have the insight that you do to know that a
>  developer is working on a problem "right now".   I just did a cvs
>  checkout of the NetworkManager.  
Well, to be fair to jeff, I noticed the same problem this morning and I
went to bugzilla first, searched on wireless-tools in the fedora core
product and found it in a few seconds. I added myself to the bug report
and watched from there.

I knew that it was being worked on b/c of that.

-sv

[Brian Millett]

On Tue, 2005-01-18 at 10:23 -0500, seth vidal wrote:
>  > Jeff, you must be having a bad day.  I would normally not even
> respond
>  > to this type of message, but you seem to be doing this a lot.
>  >   
>  > Your response to a posting for a problem that happen just this morning
>  > is just rude.  We do not have the insight that you do to know that a
>  > developer is working on a problem "right now".   I just did a cvs
>  > checkout of the NetworkManager. 
>  
>  Well, to be fair to jeff, I noticed the same problem this morning and I
>  went to bugzilla first, searched on wireless-tools in the fedora core
>  product and found it in a few seconds. I added myself to the bug report
>  and watched from there.
>  
>  I knew that it was being worked on b/c of that. 
Ok, thanks for the insight.  
I'll do that also from now on.  I understand that the load for the
developers is great, and we need to do our home work a bit better.
What is the protocol to posting to the test list?  Is it after a bug has
been filed?  Or looked for and not found?

Thanks.

And I apologize Jeff.
--
Brian Millett - [ Sinclair, "And the Sky Full of Stars"]
"When I looked at those ships, I...I didn't just see my death. I saw the
death of the whole damn human race."

[seth vidal]

>  Ok, thanks for the insight.  
>  I'll do that also from now on.  I understand that the load for the
>  developers is great, and we need to do our home work a bit better.
>  What is the protocol to posting to the test list?  Is it after a bug has
>  been filed?  Or looked for and not found? 
I always tend to post to -test only if I've gone through bugzilla and
found nothing. If I do find the bug then I only post to let people know
that it's in bugzilla and to not bitch about it on this list. If I don't
find the bug, then I file it and then post here to let people know it's
been filed.


-sv

[Michal Jaegermann]

On Tue, Jan 18, 2005 at 10:03:04AM -0500, Jeff Spaleta wrote:
>  On Tue, 18 Jan 2005 08:44:23 -0600, Chris Adams
> <cmadams(a)hiwaay.net&gt; wrote:
>  > There is an update to wireless-tools in updates-released, but
>  > NetworkManager blocks it because it is linked against libiw.so.27 and
>  > the new wireless-tools provides libiw.so.28.
>  > 
>  > yum doesn't handle this problem very well either:
>  
>  What would you prefer yum do? 
If you really ask then it would be truly nice if yum would drop
such unresolvable subset from a transaction, not silently of course,
and proceed with whatever remains.  It could be some twenty other,
unrelated, updates outstanding and currently one failed blocks them
all. _If_ you are doing that interactively that --exclude is an
obvious answer but even then such help would be welcome.

I have no idea how much work that would be or even if there are
cases which would make that really hard.  Maybe one day...

   Michal

[Dan Williams]

Hi,

Here's whats going to happen:

1) The wireless-tools update will be pulled from FC3-updates
2) A NetworkManager that doesn't use bind & caching-nameserver will be
pushed to FC3-updates, and therefore will use 'nscd -i hosts' and not
work in some situations
3) Rawhide will continue to use NM in a bind & caching-nameserver
situation until the replacement is ready.

The replacement for the bind+caching-nameserver situation is likely to
comprise lwresd (from the bind package) and nss_lwres, but won't be
ready for some amount of time because work still has to be done to bring
lwresd up to the functionality of the bind+caching-nameserver packages.
There isn't really anything that works for 99% of what we need now
_except_ bind+caching-nameserver, and since people have a crusade
against that, we have to fix up lwresd instead.

Dan

[Matthew Miller]

On Tue, Jan 18, 2005 at 10:42:05AM -0500, Dan Williams wrote:
>  There isn't really anything that works for 99% of what we need
> now
>  _except_ bind+caching-nameserver, and since people have a crusade
>  against that, we have to fix up lwresd instead. 
Thank you. It's not an irrational crusade, and I appreciate the extra work
you're doing to do this right.

-- 
Matthew Miller           mattdm(a)mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>

[Rodolfo J. Paiz]

On Tue, 2005-01-18 at 10:44 -0500, Matthew Miller wrote:
>  On Tue, Jan 18, 2005 at 10:42:05AM -0500, Dan Williams wrote:
>  > There isn't really anything that works for 99% of what we need now
>  > _except_ bind+caching-nameserver, and since people have a crusade
>  > against that, we have to fix up lwresd instead.
>  
>  Thank you. It's not an irrational crusade, and I appreciate the extra work
>  you're doing to do this right.
>   
Amen to both points. I was about to post something longer and on the
same lines, but Matthew put it more succintly and very well.

Cheers,

-- 
Rodolfo J. Paiz <rpaiz(a)simpaticus.com&gt;

[Alan Cox]

On Tue, Jan 18, 2005 at 10:42:05AM -0500, Dan Williams wrote:
>  lwresd up to the functionality of the bind+caching-nameserver
> packages.
>  There isn't really anything that works for 99% of what we need now
>  _except_ bind+caching-nameserver, and since people have a crusade
>  against that, we have to fix up lwresd instead. 
Anything that does real (as opposed to just treating it as a tcp rpc service
to a real name server) name resolution service inside a decent firewall 
doesn't work. Its hard to blame anyone since DNS comprehensively predates 
early firewall technology.

There's a patch to make glibc stat the resolv.conf file, Ulrich may hate it
but it does seem to work for non nscd cases. Having nscd aware of the situation
would be even better - I take it dbus aware nscd is a no-go ?

Alan