repo version inconsistencies -- managing & enforcing with smart?

[Andreas Hanke]

snowcrash+smart schrieb:
> is this version-in-repo inconsistency typical? expected?

Yes, this is absolutely expected because the build service calculates
the release numbers in a different way than autobuild.

> if so, what do folks here typically do?  always upgrade? never
> downgrade? etc

What smart declares as being a downgrade is in fact not a downgrade
because the buildservice packages can be "newer" despite the lower
release numbers.

> AND, for whatever is recommended, is there a smart-method/rule to
> ENFORCE that method?

I recommend not using the explicitly unsupported KDE packages from the
build service, this is unnecessary because it's impossible to tell from
the release numbers whether the packages are "newer" or "older" or whatever.

The release number is not a reliable way to identify whether a package
is "newer". This only works for packages from the same origin. You would
have to compare the changelogs manually or compare the build dates
instead of the release numbers.

--
As a side note, I really wonder why people - 2 DAYS AFTER THE RELEASE -
already start installing unsupported stuff onto their systems, replacing
the supported packages that have been worked on for 8 months. Whenever
there's a problem with them, you won't have a bugzilla to complain, or
bugzilla might be closed down if it's going to be abused for that
anyway. (This already happened for 10.0)

smart does nothing wrong here, it just tries to do the best it can do
about it, the rest depends on how people are using it.