Development and pending features

[Gustavo Niemeyer]

> And both MacPorts RPM 4.4.9 and FreeBSD RPM 5.0.3 do have the archscore,
> now implemented with the new "PlatformScore" instead of "MachineScore".
>
> As suggested elsewhere*, the best would probably be to make archscore a
> utility function somewhere in smart.backends.rpm and hide details there.
> It could also use a memoization / lookup table for the architectures,
> since the values don't change and might be costly to get every time ?
>
> * for instance http://students.mimuw.edu.pl/~mk209475/smart/raport.html

Sounds like a good idea.

> I found a few minor typos, but otherwise it seemed to be working OK.
> It did want to fetch the PACKAGES.TXT file new every time, though ?

Is there some kind of "digest" file which smaller and could be used to
consider if the big one has changed or not?

> I don't have slack, but Vector 5.9 which is based on Slackware 12.0
> and where the new "slapt-get" features (like relations) are used...
> It "should" work with Slackware and Zenwalk and other distributions
> using slack packages too, but I don't think that has been tested.

Understood.

>> Sounds good in theory, even though I'm not sure about the new tab.
>> Isn't the General tab adequate for this?
>
> It should be, that new tab is rather annoying. In theory, there "could"
> be a whole list of reference URLs but in practice there is only one...
>
> Will rewrite.

Thanks!

> The main problem is that the extra data for the changelog bloats the cache.
> While the filelists are only added to fulfill file dependencies, this adds
> overhead to every single package which makes cache loading even slower...
> To be more useful, it would be nicer if this could be done "on demand" ?

Indeed.. the whole changelog can't be put in memory for every package.  The
on demand logic is supposed to be implemented with PackageInfo instances.
Some of them actually are, but there might be some backend which keeps
data in memory.

>> That's interesting, as we discussed a few times.  It may require some
>> attention during integration to actually be really useful.
>
> The prefixing of the virtual packages might not be optimal either, but it
> is more straightforward than the "groupinstall, "grouplist", "groupinfo" ?
> As in: they would at least show up in the usual pkg interface instead of
> appearing outside. Who knows, maybe it would even help fix dependencies...

Maybe we can use the searcher for these, or show them in a different way
in the interface.  Let's see.

> Both comps and patterns use weak dependencies such as suggests/recommends,
> these are currently ignored by the loader - making some of the groups empty.

I've started implementing support for these, but ended up stopping midway.
I still want to finish this at some point.

> I added a field "reboot", for packages that suggest a reboot (e.g. kernel)
> There's also a "severity" (1-10) that isn't available in current metadata.
>
> The severity/impact/importance would translate to a Low-Important-Critical
> scale, like in e.g. http://www.redhat.com/security/updates/classification/

Sounds more human oriented indeed.  We should probably keep the more fine
grained control in the metadata (e.g. 1-10, if that's what's offered by most
backends) so that we don't lose the precision, and translate that to some
worded terminology in the UI.

-- 
Gustavo Niemeyer
http://niemeyer.net