[ATrpms-users] Re: purpose of atrpms-package-config: modularity & flexibility (was: ...)

[Fernando Pablo Lopez-Lezcano]

On Thu, 2004-05-27 at 11:27, Axel Thimm wrote:
> On Thu, May 27, 2004 at 10:57:09AM -0700, Fernando Pablo Lopez-Lezcano wrote:
> > On Wed, 2004-05-26 at 19:15, Axel Thimm wrote:
> > That is true.
> > That is not true. 
> > No, I'm not nuts. 
> > 
> > There is no named strict dependency. True. But then there's the small
> > tiny detail of your package epoch. You have bumped the epoch of apt to
> > "1" in your repository [...]
> 
> This is a sad story with the title "The week the epoch 0 bug killed
> our nerves". One year ago someone at fedora.us decided without testing
> that it would be wise to slam "Epoch: 0" to every fedora.us
> specfile. Unfortunately there was a bug in rpm concerning that, that -
> while fixed in rpm at that time - was present in hard coded form in
> apt.
> 
> Within a short time lists were flooded with bug reports maintainers
> could not diagnose, nobody would have thought back then that "Epoch:
> 0" was higher than "Epoch: (none)". That was the week 99% of my epoch
> bumps happened because I had no other way to understand and fix the
> breakage. Finally I sat down for a day or two and reviewed the code of
> apt and found the bug (and got a patch upstream), but epoch bumping
> had occured and is one-way :(

Well, now I understand the "epoch 0" thing I've heard about so many
times. Too bad that something like apt of all things got bumped up in
the confusion.  

> So this has nothing to do with epoch wars. Epochs in a repo are a sign
> of package degradation, and I wished I could spin any epochs down to
> 0, but that is not possible :(

So would I, I have some epoch bumps myself. It is possible to go back
(ie: erase the old package, replace with a newer one without the broken
epoch - obviously scriptable but the problem is how to reach everyone
with an update like this :-)  

> > So. If somebody puts atrpms urls in sources.list once, _your_ apt will
> > take precendence over _any_ other apt and get installed. As it comes
> > with no configuration files it _will_ pull atrpms-package-config.
> 
> > I guess I'll have to find a way to make apt an exception in the upgrade
> > process so that at least my users are not bitten by an unneeded upgrade
> > to the atrpms version of apt. 
> 
> Why not do as I proposed and _use_ the same apt, but providing your
> own config files? That is the purpose of it and you don't have any
> versioning comparison to care about.
> 
> E.g. just create ccrma-package-config and you are ready.

Yes, that is a possibility of course. Regretfully the epoch override in
apt is here to stay. 

> When the 4 repos (freshrpms, dag, newrpms, atrpms) were considering a
> merger or at least common infrastructure, I did exactly this config
> split to ease sharing common rpms. Excluding in apt/yum/up2date/rcd
> certain packages will become a PITA, so it's better IMO to get a clean
> common ground of operation.
> 
> What do you think? Shouldn't we share common apt and yum rpms w/o
> config files and provide them separately?

Yes, of course that would be great! Any other repos doing something
similar as far as you know? Also, as was commented before in the thread
your configuration files point to other repositories already, what would
happen to that?

-- Fernando