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@xxxxxxxxxxxxx 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. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
