Smart has been added to the Arch User Repository (AUR)

Rehan rehan.khan at dsl.pipex.com
Fri Oct 15 16:55:08 PDT 2010


Having only one option (system=) would be problematic for some distros. For example the various RPM based distros use different channel types the channel format having evolved over time. I feel that having detailed granularity makes things flexible. It should be noted that once determined these settings don’t usually change much unless some functionality changes in the way a distro/package management system does things.

 

Rehan

 

 

From: smart-bounces at lists.labix.org [mailto:smart-bounces at lists.labix.org] On Behalf Of Xavion
Sent: 16 October 2010 00:31
To: Smart-PM Mailing List
Subject: Re: Smart has been added to the Arch User Repository (AUR)

 

Hi All

Thanks for all of your detailed replies.  I wasn't expecting to get so much new information within a few hours.  My responses to each of your points are listed below them.

Okay, when I said "patch out" I probably meant to say delete the
rpm backend and channels, or put them in a sub-package if possible.
Otherwise smart will still try to load them all when it starts up,
as you can see from the traceback (when run with --log-level=debug).

	 

	@Xavion, You could just delete the backends and channels you don't need after extracting the tarball/pulling the source and then continuing with the install as usual. I think this should work for you.

	 

	Advantage from the perspective that it demonstrates a clean separation
	between the backends but your point is also very valid. Aside from the
	confusion caused by showing unrelated information in the gui (rpm channel
	types on debian, apt channel types on fedora/centos/redhat etc). It's not
	very 'smart' :) Would your proposal prevent the issue Xavion mentioned
	regarding having to install the rpm package on arch (or more accurately
	getting rpm errors because it's not/never will be installed)? Meaning that
	having the rpm backend hanging around requires having rpm/rpm python
	bindings installed? The only 'fix' I know of right now for his issue is to
	actually delete the rpm backend/channels.


I just deleted all non-Arch backends and channels, both before and after installation.  When deleted beforehand, the unwanted files were unfortunately still installed.  When deleted afterwards, I got the "Invalid channel type 'rpm-sys'" error message and Smart then quit.

It turns out that I had a leftover "rpm-sys" channel enabled and that Smart was acting on this, rather than just going by the backends and channels that were currently installed.  After I disabled this unwanted channel, the error messages went away and Smart worked properly.

Of course it would be better to be able to install stuff you need rather than remove the stuff you don't need as it makes more sense.

 

I think it is better to install everything and filter in config, but.  I suppose it could be added to "setup.cfg", under [smart] or something.  Add optional settings for backends, channels, interfaces, and plugins.

	 

	Here was a mock implementation I hacked up just now:
	
	[smart]
	backends = rpm,deb,slack,arch
	channels = True
	interfaces = text,gtk,qt,qt4
	plugins = True
	
	After parsing (where 'True' means *), this ends up as:
	
	backends: ['rpm', 'deb', 'slack', 'arch']
	channels: ['red-carpet', 'arch-dir', 'apt-deb', 'arch-site', 'mirrors', 'rpm-dir', 'up2date-mirrors', 'urpmi', 'slack-site', 'rpm-hdl', 'yast2', 'deb-dir', 'rpm-md', 'apt-rpm', 'rpm-sys', 'deb-sys', 'slack-dir', 'arch-sys', 'slack-sys']
	interfaces: ['text', 'gtk', 'qt', 'qt4']
	plugins: ['aptchannelsync', 'channelsync', 'debdir', 'detectsys', 'landscape', 'rpmdir', 'urpmichannelsync', 'yumchannelsync', 'zyppchannelsync']

	 

	Sounds good. Any reason why the channels and plugins need to be 'True' or
	'*' and not specifically specified like the backends/interfaces? If not then
	I guess this would work well. This should solve Xavion's issues, right? Just
	specify what you need for your distro and install just what is needed.


The expanded version of this looks to be okay, but I still think it could be made easier for end-users.  What's wrong with having only one configuration option, like "system = rpm,deb,slack,arch"?  The Makefile or whatever could determine which backends and channels to install from the value of this option alone.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.labix.org/pipermail/smart-labix.org/attachments/20101016/eb7f454f/attachment-0003.htm>


More information about the Smart mailing list