[repo-coord] mozilla epoch madness (was: Galeon appears to be broken)

[Axel Thimm]

This should probably be filed as a bug at bugzilla.atrpms.net against
galeon (do so if you like), but I am forwarding this to the repo-coord
list, as this is the most prominent example of epoch inflation.

Could we skip the epoch increments and nail the epoch right into
infinity? ;)

It looks like rawhide's mozilla-1.6-2 is at epoch 37, just like FC1's
1.4.1-17, so it seems like it has converged (and I thought the
question to 42 would be "what's the highest epoch mozilla will get?" ;)

Is there any reason to keep epochs in third party repos higher than
37? If yes, could you coordinate this with Christopher Blizzard
<blizzard at redhat.com> (cced)? At the very least upgrade paths to the
next Red Hat/Fedora Core release are broken.

BTW, why does galeon have to depend on the epoched version? Wouldn't
an epoch-less directory dependecy a la

Requires: /usr/lib/mozilla-1.6

be far better (epoch-less)? It only breaks with inequality
constraints.

Thanks!

On Mon, Apr 12, 2004 at 10:38:30AM -0400, BTC wrote:
>  apt-get install galeon
> Reading Package Lists... Done
> Building Dependency Tree... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
>  
> Since you only requested a single operation it is extremely likely that
> the package is simply not installable and a bug report against
> that package should be filed.
> The following information may help to resolve the situation:
>  
> The following packages have unmet dependencies:
>   galeon: Depends: mozilla (= 38:1.6) but 37:1.6-0.fdr.7.1 is to be
> installed
> E: Broken packages
> 

-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/repo-coord/attachments/20040413/9a05dd53/attachment.bin