future of smart

[rehan khan]

I read this thread with interest. I have been a supporter of smart for many years now as it solves a lot of problems and makes the upgrade process a no brainer in most cases. I have a couple of comments:

1) The biggest issue I see, from a higher level perspective than actually installing packages, is that there is a huge disconnect between the repository compose tools and the package installation tools. If the same depsolver engine was used to create and verify the repository in the first instance then the client would be much more likely to be able to use the repository with no problem. I'll take fedora as an example as I use it. The createrepo tools are, the last time I looked some two years ago, some scripts that parse a directory of rpms and write out the metadata. Apparently there is some procedure to verify the metadata and the package relations but this is not trouble free. I opened a bug at redhat to demonstrate this issue (https://bugzilla.redhat.com/show_bug.cgi?id=451235) however the standard solution is to say ` oh ok, get the package maintainers to fix thier packages'. This is all well and good but it's like mindlessly picking up the dead bodies while completely ignoring that there is a war going on around you. The bodies need to be picked up but someone should do something about the war as well, then there would be no bodies to pick up. Indeed this is probably the only option whilst there are no comprehensive  tools to automate the verification of repositories at creation time (a point in case is if Livna repository could easilty verify it's repo against the standard fedora repos then another issue would be solved - no conflicts or at least there is a way to highlight the issues to the relevant people). I think it would be a great idea for the 'server' side of repository management to be tightly integrated with the client side (or at least the code should overlap). To this end perhaps splitting the core smart depsolving engine into a library of sorts might help other package managers adopt what is quite clearly a well thought out and comprehensive piece of software. Additionally making the repository/client code a plugin type of system would allow it to follow more independant development paths depending on the availability of time from third party developers who only have an interest in one packaging system. With strong focus on the unittesting by Gustavo I think maturity would come faster (eg like adding group processing to repomd repositories which doesn't affect other kinds of repository, adding mirrorlist processing for mirrorlists generated by mirrormanager (the fedora software used to manage mirrors)) <- heh, something wrong with that. These things would not require a new release of the core engine but of the plugin only. For example for rpm repositories, each distro can use the core repomd code and plugin new features like mirror lists and group processing. Of course this would be a huge effort but I also think it would help the bigger Distros adopt Smart as an equal if not better client.

2) I don't think people should hammer packagekit so much. It has similar high level goals to smart package manager ('one client to rule them all' if one might be permitted to mangle a Tolkeinism). It integrates with dbus/network manager so tries to only update your system when you have a network connection, uses consolekit to allow users with non-root privledges to install software, has a commited and hard working developer who welcomes any and all participation (packagekit has improved leaps and bounds in it's brief lifespan). In some ways it might be a better approach than smart as it allows each package manager to be continually improved with new features separately to the frontend (perhaps this might help Smart adoption?). Smart support is good and getting better so for that user who has 200 laptops wondering the world it might solve some of the user issues (packagekit frontend/smart backend). Indeed it is designed to be accessible by non-technical users which can only mean good things by helping to bring a diverse range of (non-technical?) users into the linux fold.

3) I have added Grant's patch to this bug at Redhat: https://bugzilla.redhat.com/show_bug.cgi?id=451235

4) I'm so tired of being considered a Smart fanboy when I tell people it makes things easier/better :( Perhaps Smart needs a 'marketing' department :)

Thanks
Rehan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.labix.org/pipermail/smart-labix.org/attachments/20080614/12b4941b/attachment-0003.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: show_bug.cgi-id=451235.url
Type: application/octet-stream
Size: 204 bytes
Desc: show_bug.cgi-id=451235.url
URL: <http://lists.labix.org/pipermail/smart-labix.org/attachments/20080614/12b4941b/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: show_bug.cgi-id=451235.url
Type: application/octet-stream
Size: 204 bytes
Desc: show_bug.cgi-id=451235.url
URL: <http://lists.labix.org/pipermail/smart-labix.org/attachments/20080614/12b4941b/attachment-0007.obj>