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

[Rehan Khan]

> -----Original Message-----
> From: Anders F Björklund [mailto:afb at algonet.se]
> Sent: 15 October 2010 10:21
> To: Rehan
> Cc: Xavion; Smart-PM Mailing List
> Subject: Re: Smart has been added to the Arch User Repository (AUR)
> 
> Rehan wrote:
> 
> > 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.
> > It's been discussed before but there didn't seem to be a need. My own
> > view is that it would be cleaner to break up the smart source into a
> > 'core' application and then separate backends with their compatible
> > channels in their own source code repositories.
> 
> I think you discussed in https://bugs.launchpad.net/smart/+bug/329684 ?
> 
> The current breakup is to smart (cli, python) and smart-gui (gtk, qt).
> 
> It is possible to package backends/channels as subpackages, if needed.
> 
> I think it is better to install everything and filter in config, but.

Ah yes, I had forgotten that. It was a lot of work to work around the fact
that the installation does not help with this.

> > Thus one would be able to pull in what one needs rather than having to
> > delete what one doesn't need. A secondary advantage would be that rpm
> > development would be separated from apt development from arch
> > development etc. However this does seem a lot more work than possibly
> > needed.
> 
> 
> And that's an advantage ? It's bad enough having each "distro" version!
> 
> Splitting further into each package manager would only make things worse.
> 
> > Doing this in the makefile or setup.py etc would be less work but
> > would probably need configuration/support for each distro that uses
> > Smart.
> 
> 
> I suppose it could be added to "setup.cfg", under [smart] or something.
> 
> Add optional settings for backends, channels, interfaces, and plugins.

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.

Rehan