On Thu, 24 May 2007, Panu Matilainen wrote:
On Wed, 23 May 2007, Dag Wieers wrote:
> On Wed, 23 May 2007, Tim Lauridsen wrote:
> > Panu Matilainen wrote:
> >
> > > My 5c on the topic I've been trying to avoid because it's too
flammable
> > > for
> > > my taste. I hate politics so I'm not going to get into that, I'm
> > > commenting
> > > from purely technical POV, and actually have a proposal that might make
> > > them
> > > unnecessary.
> > >
> > > Repotags as part of release string are just plain wrong. Unlike disttag,
> > > the
> > > repotag does not have a meaningful version information in it, it's
> > > really
> > > just a fuzz-factor to somehow differentiate packages coming from
> > > different
> > > places.
>
> It does have meaningful version information in a multi-repository world.
> It shows what version of the package you have. rf means this is the
> RPMforge version. It makes the package/filename/version unique !
Actually you could make the package filename contain a repotag just by
tweaking %_build_name_fmt macro on the buildsystem. The packages themselves
have plenty of uniquely identifying data in them, strongest of which is the
signature (if present). It's just that the current tools dont allow using the
data to full extent.
Yes, that would replace one of the things that repotags are useful for.
But not the most important. They make the version/release unique.
(cross-repository)
> Granted, the repotag does not have any real meaning in
"version
> comparison" between packages from different repositories. Neither does the
> release tag. The release tag has no meaningful version information between
> packages from different repositories.
Indeed (in the "is another package newer" sense) - like you noted it does have
a meaning in non-automatic, versioned (sub-)package dependencies.
This has (now) become the most overlooked benefit of repotags :)
> > > The perfect repotag would actually be the
package's gpg signature:
> > > - it's not involved in version comparison
> > > - it can't be faked by locally rebuilding a package - it's
recorded in
> > > rpmdb
> > > so it's possible to see where a package came from
>
> It is not a perfect repotag for other reasons:
> - It doesn't make the filename unique (or gives insight of the package
> before downloading)
> - It is not shown when one has dependency problems, either on yum, apt or
> rpm level
See above, filename "uniqueness" is easily solvable. Making a human-friendly
signature visible in the tools obviously requires some modifications to the
tools. So it might not help RHEL 2.1 or Fedora 7, but I'd rather try and start
fixing the problems so I don't have to read about repotag arguments five years
from now.
Oh, I do not object in engineering future solutions. But that's not what
we are discussing within EPEL or RPMforge. We create packages that are
available for 7 years ! RHEL5 has just been released and we'll have
packages going into 2014.
We'll have to see if EPEL actively supports RHEL5 when RHEL7 is release,
like RPMforge actively supports RHEL2.1 and RHEL3 now.
As I mentioned to you before, Panu, is that my last contract was to
migrate RHEL2.1 to RHEL3 ! Yes, in 2007 companies migrate to RHEL3.
Reasons are vendor-support of tested applications.
That's production. New systems are being deployed with RHEL4 now as well,
but RHEL3 is what most of production is using.
People that now start afresh with RHEL5 are just lucky chaps, living a bit
on the edge :)
> > > For depsolvers, you need some sort of priorisation
mechanism anyway to
> > > make
> > > any sense out of mixed repository situation. So the repotag mostly
> > > serves as
> > > a visual clue to humans. All the major depsolvers now have some means to
> > > priorize between repositories so what the actual rpm EVR string is
> > > doesn't
> > > really matter, what's missing is the visual clue.
>
> The major depsolvers lack a meaningful way for a user to provide a policy
> of what they want to do with repositories or packages. Some plugins do
> allow somewhat more, but there are many shortcomings and without repotags
> errors are at first sight inexplicable or confusing.
>
> Especially when packages from different repositories have the same NEVR,
> similar sub-packages and have dependencies between them.
>
> The clamav package is a nice example. Without repotags, dependencies would
> exists between packages from different repositories.
Yup. See my other mail for an idea wrt this. Again, wont help you for existing
releases.
But that's just part of the problem... manual, versioned dependencies are a
minority in the package dependency data, the vast majority is automatically
generated soname dependencies where there are no repotags and things can (and
do) get pretty mixed up easily. It might help if yum etc could try to first
resolve dependencies from the same repo where the dependency itself comes
from.
True, it does not necessarily fix all problems. But the most obvious ones
are the subpackages depending on each other and on the base package.
> Saying that repotags have no meaningful version information is
very wrong.
> It makes the system work.
"Prevents the system from totally blowing up" would be closer to reality I
think :)
Right. It helps a bit, plus it adds the other benefits that others may not
validate as a requirement.
> > > Long-term, more than that's needed to really solve
the issues with
> > > repository mixing. One (perhaps crazy) idea is turning repotags into
> > > namespaces, and dependencies are first looked up within that namespace
> > > and
> > > only if unsolved, other namespaces are looked at in (configurable)
> > > order.
> > >
> > > An example (please excuse the :: notation, that's not a good choice
but
> > > for
> > > examples sake...): assume we have packages foo and bar which both depend
> > > on
> > > glibc, and foo additionally depends on bar. Foo and bar are available
> > > from,
> > > say, both EPEL and ATrpms:
> > >
> > > rhel::libxml2-2.6.28-1
> > > epel::foo-1.2-1
> > > atrpms::foo-1.2-1
> > > epel::bar-2.4-5
> > > atrpms::bar-2.4-1
> > >
> > > If you install atrpms::foo, as atrpms namespace also provides bar, that
> > > one
> > > gets selected instead of epel::bar even though it's evr is higher.
The
> > > actual namespace could internally be the gpg signature, only mapped to a
> > > human readable where exposed to the user. Sound crazy enough? ;)
> >
> > Yes, i sounds very crazy to me ;-) ;-) .
> > I dont know if this can be done without a lot of changes into RPM.
>
> The namespace idea is an interesting one and when it gets implemented and
> is ready is surely an alternative to repotags.
>
> But it is not ready and will not be in EL2.1, EL3, EL4 or EL5. So we
> cannot consider it an alternative because we cannot use it now.
>
> It's not that I'm unwilling to see an alternative, it's just that there
is
> NO alternative to repotags that cover it's different uses.
>
> > Nice to see something constructive to solve the real problems.
>
> It doesn't solve real problems as it is not a realistic solution yet.
Yes, I don't have a solution, but repotags are not a solution either, just a
bandaid. I'd rather attempt to have a constructive discussion how to solve the
bleeping problems for good. But this isn't the best forum for that discussion,
going crazy with package/dependency namespaces and whatnot concerns far more
people than are involved in epel...
At this point it's either bandaid or nothing. I'd prefer the bandaid, thos
prefering nothing do not see the whole repository picture but look inside
EPEL only.
Existing RPMforge/ATrpms/CentOS users beware !
Kind regards,
-- dag wieers, dag(a)wieers.com,
http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]