[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: My thoughts on repotag

On Mon, 19 Mar 2007 08:38:09 +0100 (CET), Dag Wieers wrote:

> On Sun, 18 Mar 2007, Tom 'spot' Callaway wrote:
> > It seems like everyone keeps asking me in private to speak on the topic
> > of using a repotag for EPEL, probably since I'm the one who decided to
> > not use one for Fedora Extras (the decision predates the Fedora
> > Packaging Committee).
> > 
> > The first problem I have with overloading Release with a repotag is that
> > we start to play games between repositories:
> > 
> > foo-1.0.0-1.el5.epel < foo-1.0.0-1.el5.notepel
> > 
> > Is it really? Nah. This is just RPM trying to make sense of what we've
> > shoved in there.
> If that really is a concern, then you loose anyway by not having one.
> 	foo-1.0.0-1.el5 < foo-1.0.0-1.el5.rf
> Besides this case is only useful when releases are identical, which often 
> they aren't and there is no reason to assume that:
> 	foo-1.0.0-4.el5 > foo-1.0.0-2.el5.rf
> either. So whatever the point is, a repotag simply does not affect the 
> version comparison in an important way, because releases from different 
> repositories simply cannot be compared. Any attempt doing that is 
> brain surgery. Higher does not mean better, besides RPMforge looses anyway 
> because most packages have a release of 1, while EPEL seldom has 1.
> Moot artificial point.

Is it? No, it is not. It is a real-world example.

The scheme above assumes that the dist tag is mandatory. Mistake #1.
A mandatory dist tag enters automatic Provides/Requires and also
must be considered in manual Obsoletes/Provides/Conflicts. Bad.

It then proceeds to adding a mandatory repo tag. Mistake #2.

It still fails for branch-specific (i.e. dist-specific) fixes, where the
least-significant portion of the full %release value is increased for
rebuilds or minor fixes:

 	foo-1.0.0-2.el5.fdr.1 < foo-1.0.0-2.el5.rf

In the past, the proponents of mandatory dist tags have ignored that issue
or have tried to fight it with their main counter-argument that updates
are applied to all branches always. Mass-updates *always*.

As I've explained before, more tags at the right of %release don't solve
the repository mixing problems. 

They only try to hide the fundamental problem. The primary goal, once
again, seems to be to add something mandatory to package names, which
makes users point the finger at a specific repo when they run into
repository mixing problems. Instead, it would be much better if
repositories collaborated actually and shared common packages with
the common goal of eliminating upgrade problems, conflicts, and
redundant package development.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]