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 & shaperprobe into their own package and just adding dependencies to reduce the complexity of the bismark package. We'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'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'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'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'd suggest to rename all the scripts with a prefix "bismark_".</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Finally, I'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'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'm not 100% on this yet as I haven'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>