Bug 250370 - Missing Dependency: group(ctapiusers)
Missing Dependency: group(ctapiusers)
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: ctapi-common (Show other bugs)
7
All Linux
low Severity high
: ---
: ---
Assigned To: Frank Büttner
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-01 01:11 EDT by Robert 'Bob' Jensen
Modified: 2014-01-21 17:59 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-08 13:02:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robert 'Bob' Jensen 2007-08-01 01:11:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.5) Gecko/20070718 Fedora/2.0.0.5-1.fc7 Firefox/2.0.0.5

Description of problem:
# yum install ctapi-cyberjack
Loading "allowdowngrade" plugin
Loading "skip-broken" plugin
Loading "fastestmirror" plugin
Setting up Install Process
Parsing package install arguments
Loading mirror speeds from cached hostfile
Resolving Dependencies
--> Running transaction check
---> Package ctapi-cyberjack.i386 0:3.0.3-1.fc7 set to be updated
Importing additional filelist information
filelists.sqlite.bz2      100% |=========================|  68 kB    00:00     
filelists.sqlite.bz2      100% |=========================| 7.6 MB    00:00     
filelists.sqlite.bz2      100% |=========================| 3.0 MB    00:00     
---> Package ctapi-cyberjack.x86_64 0:3.0.3-1.fc7 set to be updated
--> Processing Dependency: /usr/lib64/ctapi for package: ctapi-cyberjack
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4) for package: ctapi-cyberjack
--> Processing Dependency: group(ctapiusers) for package: ctapi-cyberjack
--> Processing Dependency: libstdc++.so.6 for package: ctapi-cyberjack
--> Processing Dependency: libgcc_s.so.1 for package: ctapi-cyberjack
--> Processing Dependency: /usr/lib/ctapi for package: ctapi-cyberjack
--> Processing Dependency: libgcc_s.so.1(GCC_3.0) for package: ctapi-cyberjack
--> Processing Dependency: libstdc++.so.6(CXXABI_1.3) for package: ctapi-cyberjack
--> Processing Dependency: libusb-0.1.so.4 for package: ctapi-cyberjack
--> Restarting Dependency Resolution with new changes.
--> Running transaction check
---> Package ctapi-common.x86_64 0:1.1-2.fc7 set to be updated
---> Package libusb.i386 0:0.1.12-7.fc7 set to be updated
---> Package libstdc++.i386 0:4.1.2-12 set to be updated
---> Package libgcc.i386 0:4.1.2-12 set to be updated
---> Package ctapi-cyberjack.x86_64 0:3.0.3-1.fc7 set to be updated
---> Package ctapi-common.i386 0:1.1-2.fc7 set to be updated
---> Package ctapi-cyberjack.i386 0:3.0.3-1.fc7 set to be updated
--> Processing Dependency: group(ctapiusers) for package: ctapi-cyberjack
--> Finished Dependency Resolution
Error: Missing Dependency: group(ctapiusers) is needed by package ctapi-cyberjack


Version-Release number of selected component (if applicable):
ctapi-cyberjack.i386 0:3.0.3-1.fc7

How reproducible:
Always


Steps to Reproduce:
1. yum install ctapi-cyberjack

Actual Results:
--> Processing Dependency: group(ctapiusers) for package: ctapi-cyberjack
--> Finished Dependency Resolution
Error: Missing Dependency: group(ctapiusers) is needed by package ctapi-cyberjack


Expected Results:
Something would provide the group

Additional info:
Comment 1 Jeroen van Meeuwen 2007-08-01 04:36:11 EDT
Does this installation have any fedora-usermgmt package installed?
Comment 2 Frank Büttner 2007-08-01 05:40:18 EDT
The bug is in the ctai-common package.
Comment 3 Robert 'Bob' Jensen 2007-08-01 09:36:26 EDT
So are you going to fix it or do I have to file a bug about it?

ctapi-common installs just fine, it is ctapi-cyberjack that fails to install.
Comment 4 Ville Skyttä 2007-08-01 10:54:55 EDT
This is not a ctapi-common bug - as I told Frank in PM last weekend,
ctapi-cyberjack should just remove the be group(ctapiusers) stuff and do
"Requires: ctapi-common >= 1.1-2".
Comment 5 Seth Vidal 2007-08-01 11:00:20 EDT
ctapi-common no longer provides group(ctapiusers)
afaict nothing NEEDS to require group(ctapiusers)

kill the dep in ctapi-cyberjack, submit it for rebuild move along.

This is like a 10 second bug fix.
Comment 6 Frank Büttner 2007-08-01 11:53:49 EDT
No ctapi-common must be fixed.
The provides group entry is missing, so I can't do anything.
Comment 7 Seth Vidal 2007-08-01 12:06:09 EDT
Frank,
  Could you explain to me why you think ctapi-common should be changed instead
of ctapi-cyberjack?

Thanks
-sv


Comment 8 Frank Büttner 2007-08-01 12:12:44 EDT
Yes, because to add an provides group .. is much cleaner than simply modify the
depend version. For example when in an later update of the common part the group
was removed by an mistake, then it will only comes out very late.(At the first
time when somebody try to access the reader). The requere group will prevents of
missing the group on the system.
Comment 9 Robert 'Bob' Jensen 2007-08-01 18:42:01 EDT
So how do we resolve this? You point the finger at the -common package it then
gets pointed back...

The tree is broken and it needs to be resolved, please figure it out.
Comment 10 Robert 'Bob' Jensen 2007-08-02 11:01:09 EDT
Frank you say this bug is in ctapi-common, please quit closing it as NOTABUG. 

Fix one of your packages I don't care if it is ctapi-common or ctapi-cyberjack.
You are a maintainer of both of these packages, fix one of them.

If you and your co-maintainer of ctapi-common can not come to an agreement I am
of the opinion that these packages be removed from the tree. Users will end up
paying the price.
Comment 11 Seth Vidal 2007-08-02 23:30:03 EDT
Reply to Comment #10:
 Yes, I'd agree to that, if a bug is keeping a package from being even installed
and the maintainers cannot or will not fix it, sounds like ground for removal.

Comment 12 Frank Büttner 2007-08-04 03:54:59 EDT
I have fix it at the ctapi-common package, but my fix was removed. So I can't do
anything more.
Comment 13 Seth Vidal 2007-08-04 08:41:42 EDT
Ville,
 You and Frank need to solve this b/t the two of you.

-sv
Comment 14 Ville Skyttä 2007-08-04 09:51:19 EDT
Seth, others, I do not intend to do anything about this - from my POV it's not a
ctapi-common bug.  Here's what has happened:

I asked Frank to take over ctapi-common completely, he didn't want more than
co-maintainership and I thought it was better than nothing and would result in
less things for me to worry about (but later I've learned it's been the opposite).

Then, Frank pushed a broken ctapi-common update without discussing the largish
and questionable changes with me, I posted how I intended to fix it in Bugzilla.
 Meanwhile the broken update slipped through to F7 updates-testing and devel
even though I had asked rel-eng to hold it, then I pushed the fix ASAP after
learning what had happened.

The fixed update stayed in updates-testing for almost a week, and I pinged Frank
during that time that ctapi-cyberjack will need adjustments or it will break, he
probably received broken dep reports also from buildsys before the breakage hit
the non-testing updates tree, and he told me I should just go ahead and fix it.
 I said if he wants the Provides, I thought it was his job to take care of
either in ctapi-common or ctapi-cyberjack and he's free to take care of it but
not reintroduce the earlier breakage.  I never heard back, and looks like he did
nothing except pushed ctapi-cyberjack to non-testing updates in a state that had
broken deps both with and without the ctapi-common update.

Frank can still go ahead and either adjust ctapi-cyberjack's dependencies or add
Provides: group(ctapiusers) to ctapi-common.  As said, I do not intend to do
anything about this, I don't think it's a ctapi-common bug, it's not a standard
practice in Fedora at the moment to use these Provides/Requires: group(foo)
things, and I don't use or maintain ctapi-cyberjack.

So, ctapi-common is still up for grabs for a new main or co-maintainer, for both
Fedora and EPEL as far as I'm concerned.  The current co-maintainership
arrangement has not worked out well at all, and I'm now even more ready to let
others worry about this stuff than I was before, and will ask for removal of
myself from its maintainers tomorrow.
Comment 15 Seth Vidal 2007-08-04 12:31:48 EDT
Ville, thanks for the explanation and fair enough. 

Frank, it sounds like the ball is in your court for both of these packages. If
neither of you wants to fix it then please send an orphan message to maintainers.

this little sideshow has gone on for long enough, I think.
Comment 16 Robert 'Bob' Jensen 2007-08-04 13:20:46 EDT
(In reply to comment #14)
 Thank you Ville
Comment 17 Frank Büttner 2007-08-04 14:47:34 EDT
No the ball is not me it is at Ville!!!!
But I can add it to the common package again. 
Comment 18 Robert 'Bob' Jensen 2007-08-07 20:29:21 EDT
The Fedora 7 tree is still broken because of these packages. This bug DOES exist. 
Comment 19 Jeroen van Meeuwen 2007-08-08 10:46:49 EDT
Latest builds in koji appear to be OK, but they have not been pushed afaik. Who
gets this show on the road?
Comment 20 Frank Büttner 2007-08-08 13:02:22 EDT
The last package contain the fix.

Note You need to log in before you can comment on or make changes to this bug.