some ideas for smart

[Anders F Björklund]

Gustavo Niemeyer wrote:

>> Smart 1.2 doesn't really "know" about package arch (just as @).
>>
>> Maybe a future version should have an explicit "arch" field
>> in the API, since there's some things that seem to need it ?
>
> As you point out, different backends have different needs, so it's not
> clear to me (yet!) that there's a real benefit in separating out the
> architecture from the version in Smart.  With the current scheme,
> we've been able to address the needs of all the major backends so far,
> including the ones related to architecture dependency.  If we have to
> introduce a specific field, I'd like to at least hear what's the
> problem we're solving that the current approach doesn't solve, and the
> plan for supporting the new architecture field in the several cases we
> now use the unified "version" field.

Actually it would probably work just as well if "version"
continued just like it is now, and there was a common
method to split out the various field if/when needed...

Currently that is done on the PackageKit end instead,
it looks (and feels) kinda horrible but does the trick.
PK wants the arch in order to do filtering on it, I think.

http://cgit.freedesktop.org/packagekit/tree/backends/smart/ 
smartBackend.py#n948

Something like:
(epoch, version, release, arch) = version_split(pkg.version)
pkg.version = version_join(epoch, version, release, arch)

For the interface, some think it looks better if arch
goes in a separate column (like the "newer" command),
and others want to be able to sort/hide on architecture...

--anders