[Bismark-devel] bismark software package requirements

[Walter de Donato]

My (in late) comments inline

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.
>

I agree with this proposal.
I'd propose to start creating the folowing packages:
- bismark-shaperprobe
- bismark-ditg
- bismark-tie

and properly set their dependencies/conflicts.


> 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?
>

Sorry about the long latency on that.
Apart from symlinks and unnecessary binaries, some paths referenced inside
the scripts should be modified
according to the folder structure we want to use (see the next point).


>
> 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?
>

I agree with moving binaries inside /bin or /sbin, but probably I'll try to
keep the scripts in a different folder
and dispose a wrapper in /bin to call each of them.
Otherwise I'd suggest to rename all the scripts with a prefix "bismark_".


>
> 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.)
>

We can decide to unpack them in /etc/bismark and then let the post-install
script manage their content.

-Walter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bismark-devel/attachments/20110411/da33ee57/attachment-0002.html>