My (in late) comments inline<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I foresee splitting off the D-ITG &amp; shaperprobe into their own package and just adding dependencies to reduce the complexity of the bismark package. We&#39;ll probably ultimately also have a few bismark-* pkgs rather than just one to allow for different levels of participation but that can be thought about a little later.<br>
</blockquote><div><br></div><div>I agree with this proposal.</div><div>I&#39;d propose to start creating the folowing packages:</div><div>- bismark-shaperprobe </div><div>- bismark-ditg</div><div>- bismark-tie</div><div><br>
</div><div>and properly set their dependencies/conflicts.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Walter, what about the tar that Sri built was wrong? I would like to get the packages further along tomorrow and knowing that will help. I did see a couple of symlinks (rather than original files) were packed in the keys and that there are some non-essential ITG binaries included. Were there other problems?<br>
</blockquote><div><br></div><div>Sorry about the long latency on that.</div><div>Apart from symlinks and unnecessary binaries, some paths referenced inside the scripts should be modified </div><div>according to the folder structure we want to use (see the next point).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Also, I think moving /root/scripts/* and /root/bin/* into /usr/bin or /usr/sbin as appropriate would be a good idea. Other than a few path updates I can&#39;t imagine this causing much of a problem. Opinions? Any scripts/binaries that you know would be sbin versus bin?<br>
</blockquote><div><br></div><div>I agree with moving binaries inside /bin or /sbin, but probably I&#39;ll try to keep the scripts in a different folder</div><div>and dispose a wrapper in /bin to call each of them.</div><div>
Otherwise I&#39;d suggest to rename all the scripts with a prefix &quot;bismark_&quot;.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Finally, I&#39;m guessing that the authorized_keys and known_hosts will probably be moved from the bismark svn to the source control for the custom feed. This is because we don&#39;t want to just copy those files in (might overwrite what the user already had) but rather concatenate the keys dynamically as part of a post-install process for the package. I&#39;m not 100% on this yet as I haven&#39;t played with the post-install but I encountered a similar situation with /etc/rc.local (which was already being provided by another core package.)<br>
</blockquote><div><br></div><div>We can decide to unpack them in /etc/bismark and then let the post-install script manage their content.</div><div><br></div><div>-Walter</div><div> </div></div>