[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-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.