Bug 677799 - Broken dependency: perl-DateTime-Format-Mail-0.3001-9.fc15.noarch requires perl(DateTime) >= 0:0.1705
Summary: Broken dependency: perl-DateTime-Format-Mail-0.3001-9.fc15.noarch requires pe...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: perl-DateTime-Format-Mail
Version: 15
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Chris Weyl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: repoclosure_hash:aa48b732925cc6cb3c3a...
Depends On:
Blocks: F15Alpha, F15AlphaBlocker
TreeView+ depends on / blocked
 
Reported: 2011-02-15 21:22 UTC by James Laska
Modified: 2013-09-02 06:53 UTC (History)
7 users (show)

Fixed In Version: perl-DateTime-Format-Mail-0.3001-10.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-02-16 13:38:16 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description James Laska 2011-02-15 21:22:52 UTC
Added repo-1 repo from /media
Reading in repository metadata - please wait....
Checking Dependencies
Repos looked at: 1
   repo-1
Num Packages in Repos: 2922
package: perl-DateTime-Format-Mail-0.3001-9.fc15.noarch from repo-1
  unresolved deps: 
     perl(DateTime) >= 0:0.1705

Comment 1 James Laska 2011-02-15 21:26:33 UTC
This issue is proposed as a Fedora 15 Alpha release blocker due to the following Alpha release criteria [1]

   There must be no file conflicts (cases where the files in some 
   packages conflict but the packages have explicit Conflicts: 
   tags are acceptable) or unresolved package dependencies during
   a media-based (CD/DVD) install 

https://fedoraproject.org/wiki/Fedora_15_Alpha_Release_Criteria

Comment 2 Paul Howarth 2011-02-15 22:50:03 UTC
Update is just waiting to be pushed:

https://admin.fedoraproject.org/updates/perl-DateTime-Format-Mail-0.3001-10.fc15

Comment 3 Ralf Corsepius 2011-02-16 02:05:19 UTC
(In reply to comment #2)
> Update is just waiting to be pushed:
> 
> https://admin.fedoraproject.org/updates/perl-DateTime-Format-Mail-0.3001-10.fc15
Exactly. Also see http://lists.fedoraproject.org/pipermail/devel/2011-February/148638.html

=> This BZ and the koji/bodhi releated bureaucratic churn could have easily been avoided

Comment 4 James Laska 2011-02-16 13:32:21 UTC
(In reply to comment #3)
> => This BZ and the koji/bodhi releated bureaucratic churn could have easily
> been avoided

Well, not *easily* ... but the AutoQA [1] folks are working on it.  The depcheck test (which is intended to identify and block updates that introduce deps problems will be rolling out in 'permissive' mode in the next few weeks).  Coders welcome :)

[1] https://fedoraproject.org/wiki/AutoQA

But let's track feedback for that on autoqa-devel.org.  For now, this bug is tracking an Fedora 15 Alpha release blocker.  Thanks all!

Comment 5 Paul Howarth 2011-02-16 13:38:16 UTC
The update was pushed to stable overnight.

Comment 6 Ralf Corsepius 2011-02-16 13:46:38 UTC
(In reply to comment #4)
> Well, not *easily* ... but the AutoQA [1] folks are working on it.
Meanwhile switch off this silly delay queue - Whether you like it or not, it has never worked, not even in f13 and f14 ... it's just that the "broken mass merger" is exposing the delay queue's detrimental effect to a wider audience.

Some further food for thought: Maintainers already are withholding bug-fixes and ship knowingly broken packages, because updating a "pending package" would retriggers the delay timer.

(In reply to comment #5)
> The update was pushed to stable overnight.
Yes, this one ... ca. 20 other, similar ones are still waiting. And dozens if not 100s of further perl-package are possibly silently broken by the rpm-dep-tracker changes :(

Comment 7 James Laska 2011-02-16 14:52:02 UTC
(In reply to comment #5)
> The update was pushed to stable overnight.

Great, thanks Paul!

(In reply to comment #6)
> (In reply to comment #4)
> > Well, not *easily* ... but the AutoQA [1] folks are working on it.
> Meanwhile switch off this silly delay queue - Whether you like it or not, it
> has never worked, not even in f13 and f14 ... it's just that the "broken mass
> merger" is exposing the delay queue's detrimental effect to a wider audience.

The "delay" as you call it, has worked quite nicely during Fedora 14 stabilization.  As maintainer, you might not have exposure to the numerous pain points we experience when trying to assemble a distribution full of interdependent moving targets.  As a Fedora user+contributor, I'm sure you are aware of the issues we encounter leading up to release milestones.

While the Karma system isn't perfect, and there are always improvements that could be made, it has been a life saver to allow us to more consistently release Fedora on time.  Calling a process bureaucratic doesn't necessarily move the discussion forward in a positive manner.  We need ideas to improve our tools and process, but simply removing it without a review of the problem space isn't an option.

Of course, apologies to Paul ... this isn't germane to this specific bug report.  Ralf, as you've already done, feel free to continue discussion on test@ or devel@.

Comment 8 Ralf Corsepius 2011-02-16 15:50:10 UTC
(In reply to comment #7)

> (In reply to comment #6)
> > (In reply to comment #4)
> > > Well, not *easily* ... but the AutoQA [1] folks are working on it.
> > Meanwhile switch off this silly delay queue - Whether you like it or not, it
> > has never worked, not even in f13 and f14 ... it's just that the "broken mass
> > merger" is exposing the delay queue's detrimental effect to a wider audience.
> 
> The "delay" as you call it, has worked quite nicely during Fedora 14
> stabilization.
You are cheating to yourself - The only effect it has is it adding more delays to the already exiting delays. Probably you're too close to it and don't maintain enough packages to understand.


>  As maintainer, you might not have exposure to the numerous pain
> points we experience when trying to assemble a distribution full of
> interdependent moving targets.
I am experiencing the detrimental impact of the delays at full strength all of the time, e.g. 

* fixing bugs takes weeks and months, if a bug fix adds a necessity of updating or adding a package chain (pretty common with perl).
* updates/bug-fixes are outdated when they are being released (Typically happens when upstreams start "hectic activity", when being notified about bugs)
* not being able to push bug-fixes in timely manners (typically happens when bugs are causing "non-security" relevant malfunctions).

>  As a Fedora user+contributor, I'm sure you are
> aware of the issues we encounter leading up to release milestones.
Correct, and the delays add further to them.

Ask yourselves: Why is this thread around? .... because the delays are rending fixing bugs a nightmare and are the cause of churn and bugs, next to a release milestone!!

> While the Karma system isn't perfect, and there are always improvements that
> could be made, it has been a life saver to allow us to more consistently
> release Fedora on time.
You mean on the may-be 5-10% of packages which receive a vote at all? 

From my packages (And I maintain many), in almost all cases, my packages don't receive any vote at all - I.e. the only benefit of karma my package receive is them being delayed and occasionally outdated before they are released.

>  Calling a process bureaucratic doesn't necessarily
> move the discussion forward in a positive manner.
I disagree, but I am not naive enough to assume the "officer" who processes the bureaucracy to understand the detrimental effects and overhead he adds.

I only played nice to it this time, because this allowed us to escape the delays and to achieve mostly the same effect as "a push to stable". A functional "push to stable" would have had the same effect, w/ and w/o karma.

'nough said.


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