From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-12-ewr.dyndns.com (mxout-063-ewr.mailhop.org [216.146.33.63]) by lists.bufferbloat.net (Postfix) with ESMTP id B77532E016E for ; Mon, 11 Apr 2011 08:56:43 -0700 (PDT) Received: from scan-12-ewr.mailhop.org (scan-12-ewr.local [10.0.141.230]) by mail-12-ewr.dyndns.com (Postfix) with ESMTP id 548B1939590 for ; Mon, 11 Apr 2011 15:56:42 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 192.132.34.61 Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by mail-12-ewr.dyndns.com (Postfix) with ESMTP id 898FE939544 for ; Mon, 11 Apr 2011 15:56:41 +0000 (UTC) Received: from mail-qy0-f171.google.com (mail-qy0-f171.google.com [209.85.216.171]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id p3BFucDR029544 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 11 Apr 2011 17:56:40 +0200 Received: by qyj19 with SMTP id 19so1470014qyj.16 for ; Mon, 11 Apr 2011 08:56:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.32 with SMTP id i32mr4366480qck.5.1302537398639; Mon, 11 Apr 2011 08:56:38 -0700 (PDT) Received: by 10.229.75.16 with HTTP; Mon, 11 Apr 2011 08:56:38 -0700 (PDT) In-Reply-To: References: <4D9E6195.8040602@taht.net> Date: Mon, 11 Apr 2011 17:56:38 +0200 Message-ID: From: Walter de Donato To: "Poole, Brian" Content-Type: multipart/alternative; boundary=002354332c6ef3dcc704a0a69edd Cc: "bismark-devel@lists.bufferbloat.net" Subject: Re: [Bismark-devel] bismark software package requirements X-BeenThere: bismark-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: BISMark related software development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 15:56:44 -0000 --002354332c6ef3dcc704a0a69edd Content-Type: text/plain; charset=ISO-8859-1 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 --002354332c6ef3dcc704a0a69edd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My (in late) comments inline

I foresee splitting off the D-ITG & shaperprobe int= o their own package and just adding dependencies to reduce the complexity o= f the bismark package. We'll probably ultimately also have a few bismar= k-* pkgs rather than just one to allow for different levels of participatio= n but that can be thought about a little later.

I agree with this proposal.
I= 9;d propose to start creating the folowing packages:
- bismark-sh= aperprobe=A0
- 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 th= e packages further along tomorrow and knowing that will help. I did see a c= ouple of symlinks (rather than original files) were packed in the keys and = that there are some non-essential ITG binaries included. Were there other p= roblems?

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

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 c= an't imagine this causing much of a problem. Opinions? Any scripts/bina= ries that you know would be sbin versus bin?

I agree with moving binaries inside /bin o= r /sbin, but probably I'll try to keep the scripts in a different folde= r
and dispose a wrapper in /bin to call each of them.
Otherwise I'd suggest to rename all the scripts with a prefix "bis= mark_".
=A0

Finally, I'm guessing that the authorized_keys and known_hosts will pro= bably be moved from the bismark svn to the source control for the custom fe= ed. This is because we don't want to just copy those files in (might ov= erwrite what the user already had) but rather concatenate the keys dynamica= lly 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 a= nother core package.)

We can decide to unpack them in /etc/bisma= rk and then let the post-install script manage their content.
-Walter
=A0
--002354332c6ef3dcc704a0a69edd--