Broken deps (Re: rawhide report: 20080414 changes)

Alex Lancaster alexl at users.sourceforge.net
Tue Apr 15 01:31:39 UTC 2008


>>>>> "AF" == Andrew Farris  writes:

AF> Kevin Kofler wrote:
>>> mediawiki-openid-0.7.0-5.noarch requires php-pear-Auth-OpenID
>>> mediawiki-openid-0.7.0-5.noarch requires php-pear-Services-Yadis
>> 
>> What's up with this one? If the deps can't be satisfied in time for
>> F9, I'd suggest blocking the package from f9-final, it can be
>> pushed as an update together with the dependencies once they are
>> there.

AF> I've noticed that one in broken deps for many months now, it does
AF> seem like its just not going to happen for f9?

This package should never have passed review because the Requires
packages, e.g. php-pear-Auth-OpenID:

https://bugzilla.redhat.com/show_bug.cgi?id=227190

hadn't also passed review.  Noted here:

https://bugzilla.redhat.com/show_bug.cgi?id=218581#c26

+1 for blocking this package from f9-final until deps have passed
+review.

I also note that Axel has included this in his CVS request:

Cvsextras Commits: no (too many people in this group)

which doesn't seem like a very good reason to not allow cvsextras.  

In general I think this is not a good practice because other
maintainers can't step and help fix a package as per:

http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening

I think there needs to be a better reason that just "having too many
people".  Open ACLs encourages maintainers to share some collective
responsibility for the distribution as a whole (e.g. broken deps are
bad, should be fixed ASAP by any maintainer).

Most maintainers are fairly responsible and it's easy to spot when
somebody changes something (since you get an e-mail), and it's easy to
revert.  I never just change something willy-nilly, and always give
the primary maintainer time to respond, but sometimes when something
is time critical or causes broken deps it's appropriate to step in.
(I've opened my ACLs and I'm always grateful if somebody needs to fix
my packages if I'm unavailable to do so).

Alex




More information about the fedora-devel-list mailing list