repo version inconsistencies -- managing & enforcing with smart?

snowcrash+smart schneecrash+smart at gmail.com
Sun Dec 10 00:30:29 PST 2006


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

ah. i did not realize that. that explains some.

> > 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.

that's now clear.  i can't say that i understand why the buildservice
numbering has been chosen to be different, but nonetheless this is
good to know.

> > 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.

again, clear now. thanks!

> 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)

well, first, i haven't begun installing anything, actually. i choose
to keep certain 'high value' (to me ...) repos enabled, so that i can
monitor what progress is being made in those repos -- by checking
updates/upgrades.

i can/do choose to -- or not to -- upgrade or not.

my reason for *this* thread was to better understand why SOME repos'
pkgs are upgraded and SOME are downgraded, and to clarify the apparent
version inconsistencies.

your explanations have helped. thanks.

> 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.

thanks.



More information about the Smart mailing list