RPM Spec file that demonstrates the modularity of Smart

[rehan khan]

Hi,
 
The there is no direct purpose as such and there is no problem with the current packaging strategy. It started out as an exercise in getting access to the ok button on smaller screen sizes on the add channel dialog (by reducing the number of installed options). However it does highlight the fact that smart is modular and extendable using plugins (in a round about sort of way, this is easily discernable from just looking at the package list). Additionally for example on rpm systems having apt/deb and slack options is particularly useless and can be confusing for some users. A packager also gains some control over what is installed by default (rpm stuff for rpm distros, deb stuff for deb distros etc) while allowing the user to install other backends/channels/plugins as needed. Sometime in the future there will be an Arch backend, a qt interface and additional channels making this problem worse (non-relevant options).
 
There are other (probably better) solutions to the problem e.g. distribute smart as a core application plus separate plugins that a distro can select or a config dialog to enable/disable features so the dialogs display only relevant items but this has not been implemented as yet.
 
I agree that the number of rpm's generated by the spec might be considered overkill, but this is the nature of plugin based applications. With minor changes to the spec the unnecessary rpms can even skipped from the build process and not included as I can't think of a use case for having them in the first place.
 
The modified spec file is just offered up for examination as an example.
 
cheers
R

________________________________

From: Axel Thimm [mailto:Axel.Thimm at ATrpms.net]
Sent: Sun 15/02/2009 16:30
To: rehan khan
Cc: smart at labix.org
Subject: Re: RPM Spec file that demonstrates the modularity of Smart



Hi.

On Sun, Feb 15, 2009 at 12:54:32PM -0000, rehan khan wrote:
> This might be interesting to rpm packagers on the list.
> 
> https://bugs.launchpad.net/bugs/329684
> 
> I have hacked the fedora 10 spec file for smart to increase the
> modularity of the install (hope you don't mind Axel). Details are in
> the bug report. Please note it is only an example and would probably
> need some cleanup/updating to actually be used somewhere.

What would the benefit of this microgranularity be?

The currently packaged form into smart, smart-update, smart-gui and
ksmarttray subpackages is already considered too fragmented by many
users.

The current subpackaging is actually done in a way to have the main
smart package pull in only the really required bits compared to pygtk
or kde bits needs by the graphical subpackages.
--
Axel.Thimm at ATrpms.net


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 5924 bytes
Desc: not available
URL: <http://lists.labix.org/pipermail/smart-labix.org/attachments/20090215/a3713c0c/attachment-0003.bin>