[Bug 175438] Review Request: smart -- Next generation package handling tool

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: smart -- Next generation package handling tool


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175438





------- Additional Comments From jarkko at saunalahti.fi  2006-01-25 19:32 EST -------
Ok, I'll read the spec file line by line and comment here. I'll be commenting
every little detail. Sorry if you don't like my style, but I think it's better
to say everything at once - even minor details.

Ok, here we go...

- Why are the source and patch numbers not growing from 1 to 2 etc. (Not really
an issue. I just wonder if there's some technical reason for that.)

- Packages don't usually use that precise build root dir. Perhaps they should
though and here this is done how it should be done. :) (Not really an issue either.)

- I would not provide smartpm-* there because this package is named smart and
because this will be the initial one there should not be need for those
provides. One name for one software.

- What's smart-plugins? Newer heard. If you made that up as "this would be a
good idea to have" I'd say don't, because there should not be provides which
don't really mean something. I looked quickly at dag's spec file and at least
there is no smart-plugins provided. If you thought this package provides smart
plugins that is not correct as the gui for example is not in this package. Or
perpaps I didn't get it...

- Don't provide smart-tui because the shell is not a tui. There could be a real
tui in the future (dialog style). Shell is not a dialog. I'd say provide
smart-shell because of this - and because "smart --shell" is something the user
knows.

- Require rpm version >= 4.3 even though it can be overridden with epoch. Just
so that the package will tell that rpm >= 4.3 should be used.

- Change smart-gtk to smart-gui. And mention that the frontend is graphical so
that the less techies out there understand what it is.

- Remove obsoletes from smart-gui (if you agree to change the name to
smart-gui). Don't provide smartpm-gui or smartpm-gtk because this is smart, not
smartpm. Things would be different if smart would have already been packaged
somewhere as "smartpm" and there would be possible requirements for it in other
packages.

- If smart-gui (or smart-gtk) belongs to Applications/System, how can ksmarttray
belong to System Environment/Base? A mistake? Should be the same as the gui package?

- Shouldn't smart-usermode obsolete smart-update and not ksmarttray? I might be
wrong but if you just read the decriptions you get that impression.

- The gui package description should say more clearly that it provides a
graphical user interface / frontend. Non-techies don't know what a GTK frontend
means.

- Does %configure contain $RPM_OPT_FLAGS? It would be good to build the package
using optimizations. Also, is there a macro for the make command (I think there
is)? Perhaps use that and not just "make"?

- Same goes for "install". Perhaps use the macro instead?

- You use "touch" there. Shouldn't you require /bin/touch then? Or is there a
macro for it instead?

- You use "test" there. The same thing here. Either there is a macro or you
should require "/usr/bin/test".

- You use "gtk-update-icon-cache". Shouldn't you require
"/usr/bin/gtk-update-icon-cache" then?

- And require those commands in the correct package (if used when installing a
subpackage, require in subpackage).

Ok, done. You have plenty of issues to comment now. Perhaps I was nitpicking but
at least I was reading the spec precise enough so I don't have to reread it and
write more again. :)

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.