<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Rehan<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> smart-bounces@lists.labix.org [mailto:smart-bounces@lists.labix.org] <b>On Behalf Of </b>Xavion<br><b>Sent:</b> 16 October 2010 00:31<br><b>To:</b> Smart-PM Mailing List<br><b>Subject:</b> Re: Smart has been added to the Arch User Repository (AUR)<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>Hi All<br><br>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.<o:p></o:p></p><p class=MsoNormal>Okay, when I said "patch out" I probably meant to say delete the<br>rpm backend and channels, or put them in a sub-package if possible.<br>Otherwise smart will still try to load them all when it starts up,<br>as you can see from the traceback (when run with --log-level=debug).<o:p></o:p></p><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>@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.<o:p></o:p></p></blockquote><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Advantage from the perspective that it demonstrates a clean separation<br>between the backends but your point is also very valid. Aside from the<br>confusion caused by showing unrelated information in the gui (rpm channel<br>types on debian, apt channel types on fedora/centos/redhat etc). It's not<br>very 'smart' :) Would your proposal prevent the issue Xavion mentioned<br>regarding having to install the rpm package on arch (or more accurately<br>getting rpm errors because it's not/never will be installed)? Meaning that<br>having the rpm backend hanging around requires having rpm/rpm python<br>bindings installed? The only 'fix' I know of right now for his issue is to<br>actually delete the rpm backend/channels.<o:p></o:p></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><br>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.<br><br>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.<o:p></o:p></p><p class=MsoNormal>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.<o:p></o:p></p><div><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>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.<o:p></o:p></p><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Here was a mock implementation I hacked up just now:<br><br>[smart]<br>backends = rpm,deb,slack,arch<br>channels = True<br>interfaces = text,gtk,qt,qt4<br>plugins = True<br><br>After parsing (where 'True' means *), this ends up as:<br><br>backends: ['rpm', 'deb', 'slack', 'arch']<br>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']<br>interfaces: ['text', 'gtk', 'qt', 'qt4']<br>plugins: ['aptchannelsync', 'channelsync', 'debdir', 'detectsys', 'landscape', 'rpmdir', 'urpmichannelsync', 'yumchannelsync', 'zyppchannelsync']<o:p></o:p></p></blockquote><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Sounds good. Any reason why the channels and plugins need to be 'True' or<br>'*' and not specifically specified like the backends/interfaces? If not then<br>I guess this would work well. This should solve Xavion's issues, right? Just<br>specify what you need for your distro and install just what is needed.<o:p></o:p></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><br>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.<o:p></o:p></p></div></div></div></div></div></div></body></html>