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-31 08:06 EST ------- > The problem with plugins is, that they usually add new dependencies > which are not need for the core functionality. So my first 'smart' > package had a physical '-plugins' subpackage. Because *current* > plugins do not add mentioned dependencies, I merged it back into the > main package. I bet you will never ship smart-plugins because when a plugin adds that kind of dependencies you will make a separate subpackage for that specific plugin, not for all plugins. This is the reason I'd say don't provide this smart-plugins package. > 'smart --shell' is a textual interface for user interaction. So, it > can be labeled 'TUI'... But ok, to make it clear, I renamed it to > '-tui-shell'.... I'd still follow the usage "smart --shell" and name this as "smart-shell". But, as you don't ship a separate smart-tui, smart-shell or smart-tui-shell subpackage, I'd say don't provide it. The reason is to not pollute the package namespace with packages which doesn't really exist and which have never even existed. (For the same reason I'd say don't provide smartpm-* packages.) > README should tell this also... Again: there is absolutely no technical > reason to add versioned dependencies here Is there a policy for this? There might be because this is a very general issue; whether to issue all version requirements or only those which might not be satisfied already in the distribution. > Ok, you have won. I renamed it to 'smart-gui-gtk' which should please > everybody. I'd still like to follow the usage "smart --gui" here and name the package as "smart-gui". I don't like long names... And I don't like names which don't follow the upstream names... And I don't like names which try to tell things like the used library etc... Those namings belong to Debian policy (which I think causes more confusion than help - again: rpm --requires tells the toolkit etc.). Fedora policy is to name packages like they are named in upstream. > 'rpmbuild ...' environments should have coreutils installed I think you are right there. Only those requirements should be issued which aren't already provided by other requirements (although you should be 100% sure they really are provided). And in this case /bin/touch is provided by coreutils which provides fileutils which in turn is required by rpm. :) > which macro? %{__install} (from /usr/lib/rpm/macros). In general, I'd use the most common macros - at least those from /usr/lib/rpm/macros because those should not add any extra dependencies. > 'test' is a bash builtin Yes, sorry. I really noticed "which" is not very usefull command - "type" is much better. :) > ??? Forget. I was just talking in general there. -- 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
