RSB

[Chris Johns]

On 17/9/21 9:54 am, Joel Sherrill wrote:
> On Thu, Sep 16, 2021, 6:36 PM Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>> wrote:
> 
>     On 16/9/21 10:59 pm, Joel Sherrill wrote:
>     > On Wed, Sep 15, 2021 at 7:08 PM Chris Johns <chrisj at rtems.org
>     <mailto:chrisj at rtems.org>> wrote:
>     >> On 16/9/21 1:46 am, Joel Sherrill wrote:
>     >>> On Tue, Sep 14, 2021 at 5:52 PM Chris Johns <chrisj at rtems.org
>     <mailto:chrisj at rtems.org>> wrote:
>     >>>> On 15/9/21 4:49 am, Joel Sherrill wrote:
>     >>> The issue I mentioned is that the same rtems-tools- at TAG@-1.tar.bz2
>     >>> is used for every architecture. Perhaps rtems-tools- at ARCH@- at TAG@-1.tar.bz2.
>     >>> Then you can script building all architectures without renaming files.
>     >>
>     >> That implies the tools are arch specific and they are not. The tools
>     should be
>     >> tagged with the host arch details if we add anything.
>     >
>     > The issue is that the tarball name is wrong and the rtems-tools one
>     rtems-tools,
>     > binutils, gcc/newlib, and gdb. It includes EVERYTHING that is built
>     > when you use 6/rtems-arm.
> 
>     I am not surprised, maybe the staging changes may have effected the tar naming?
> 
>     If you wanted to select a parent which parent would be selected?
> 
> I don't mind everything being lumped together. Except for rtems-tools, it is all
> an arm RTEMS tool chain which is why it never struck me that it was using the
> repo rtems-tools as the name.

I think separate is still the way to go. It should be an easy script to unpack
the pieces and make a single tarball.

> Maybe rtems-toolchain-CPU. Ideally rtems-tools would be separate.

The CPU has to be x86 etc. I am not comfortable with a target arch being mixed
in here.

> Maybe a variable to define the package name to override some default.

I think the naming needs to be consistent for the RSB. How it is deployed is
left to you and others to sort out.

>     The current design packages at the config file level it gives you the various
>     pieces as a single block so you can packages them. A single tarball for the top
>     level would make it hard for someone to use to make packages that can be
>     deployed.
> 
>     For tools the name of the tarball needs to match the contents and it is native.
>     The fact each arch bset builds the same thing is a side effect of the packaging
>     being used. Adding the arch might create the impression each arch tools package
>     has to be kept separate.
> 
>     > The automake tarball has automake and autoconf
> 
>     I am not sure why this is happening. Maybe 2 tarballs should be created. This
>     stuff is a little more complicated because of the internal build stage. Autoconf
>     and automake cannot be cleanly relocated so in installers I have created in the
>     past I had the installer build the packages using the install prefix.
> 
> 
> This one isn't critical as we aren't using it going forward. This is an issue on
> 5 and older.

>     > The rtems-tools tarball has everything I listed above. Beyond
>     > rtems-tools, binutils,
>     > gcc/newlib, and gdb, I suppose it also includes sis or dtc on some
>     > architectures.
> 
>     Do you want the RSB to generate user accessible tar files that need no further
>     touching?
> 
> Ideally they shouldn't be named the same. I don't particularly care if they
> duplicate files. Packages would be nice not to duplicate since we should be able
> to control that. 

If the contents is the same then they are the same and if an arch is added to
the name we end up with a new set of confusions. For example, can the separately
arch named rtems tool packages be installed and removed under the same prefix?
They can be installed but they cannot be removed. File systems do not reference
count.

> I'm already post processing to extract a common tarball. But the names and
> contents of the RSB generated tarballs don't accurately reflect the contents and
> don't reflect the target CPU (or host). 

The issue appear is when you package for a distro. The install phase is easy and
things work but the removal is when things break. You install an arm package
then you install a powerpc package with bunches of common gcc, binutils files
plus rtems-tools and all still works. You then remove the powerpc package and
all the shared pieces are removed and the arm tools are now broken.

Here is the last set of packages we made as an example:

https://ftp.rtems.org/pub/rtems/archive/rpms/linux/4.11/centos/7/x86_64/

Chris