Questionable patch organization in RTEMS tools and RSB

[Sebastian Huber]

Patches for RTEMS tools are available via the RTEMS tools repository:

​https://git.rtems.org/rtems-tools/tree/tools

They are organized using subdirectories.

The RSB uses these patches. It removes the subdirectories and collects everything in a "patches" directory, e.g.

download: ​https://git.rtems.org/rtems-tools/plain/tools/4.11/newlib/arm/newlib-ARM-Optimize-IEEE-754-sqrt-implementation.diff -> patches/newlib-ARM-Optimize-IEEE-754-sqrt-implementation.diff

This works only in case the patch file names are unique. So, the use of subdirectories in the RTEMS tools is questionable.

[Amar Takhar]

This should be easily solved by preserving the subdirectories when downloading Keeping the subdirectories is good for orginisation and still handy when they've been downloaded.

[Chris Johns]

Is the issue switching between branches when testing?

There is the patch option of --rsb-file= that overrides the RSB's detection of a file name from the URL. This option assumes a file name and not a file path.

I question the need for patches being in rtems-tools, the less we have the better off we are. I cannot see how we can remove the ones we have without needing to update the 4.11 and master branches.

The RSB has evolved to being able to download patches from a range of sources. I prefer to see patches referenced from upstream sources where ever possible. Mailing list archives are a good source of patches and I wonder if this is a better place for us to hold any patches we need?

The ability to support a download directory structure would mean the RSB would need to more complex code to handle some of sites we currently download from. I am not sure how to do this.

[Gedare Bloom]

The problem of multiple patches with the same name would be a problem regardless of the source of the patches. This namespace problem could be solved by renaming all patches to something that should be unique, e.g. the hash value of the file.

[Chris Johns]

Replying to Gedare:

The problem of multiple patches with the same name would be a problem regardless of the source of the patches. This namespace problem could be solved by renaming all patches to something that should be unique, e.g. the hash value of the file.

The hash value of the file would work and a good idea. I was concerned about making it difficult to find the patch or file from the error or log but a hash is something you can grep the config tree for.

If no hash is provided the file name can be used. This keeps the bootstrap of adding new files like it currently is, ie a warning.

This would be common to the source and patch directories. Is that OK?

[Chris Johns]

A problem with using the hashes is releases, that is:

​https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.1/sources/

The release procedure uses the RSB in a download only mode to collect all the source needed in a release.

I am not sure how to handle this.

[Sebastian Huber]

I think we should stop to use subdirectories in the RTEMS tools for the patches.

[Chris Johns]

Sebastian, I did not understand your last comment.

[Chris Johns]

I fixed #2951 using the patch from the newlib mailing list:

​https://git.rtems.org/rtems-source-builder/commit/?id=b47a811955e427f945f8958de87158e9990dc7da

I like this approach. The --rsb-file option can be used to make a patch name unique such as pre-pending rtems-4.11- to the start.

[Sebastian Huber]

I think we should copy everything we need to a place we can control. URLs may get out of date and web servers may disappear. GCC snapshots seem to be only available for six months or so.

[Sebastian Huber]

Replying to Sebastian Huber:

I think we should stop to use subdirectories in the RTEMS tools for the patches.

In case we copy everything into one directory on the patch consumer side, e.g. RSB, release directory, then we should not use subdirectories to make a patch unique on the patch provider side, e.g. RTEMS tools.

[Chris Johns]

Replying to Sebastian Huber:

I think we should copy everything we need to a place we can control. URLs may get out of date and web servers may disappear.

For a release this is what happens. The directory for 4.11.1 is:

​https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.1/sources/

and this is all the source for that release.

I am not sure I follow the context of "copy everything". In terms of a time line the only points that matter are the release branch heads for the active and previous branch and master. I do not see any value in a single collection point for any and every patch the RSB references over time.

Attempting to make sure all commits in the RSB are functional does not make sense. Hosts change and this effects the RSB so there are 2 dependent variables in play.

GCC snapshots seem to be only available for six months or so.

Yes as we have discovered. I am fine with an FTP area on the ftp.rtems.org being set up for special cases if we have a need and gcc fills this role. If a release references a GCC snapshot when the release will contain a copy. The downside of this is a clutter of files that are of no value sitting around.

In case we copy everything into one directory on the patch consumer side, e.g. RSB, release directory, then we should not use subdirectories to make a patch unique on the patch provider side, e.g. RTEMS tools.

Yes, and I am for us not using rtems-tools for patches any more.

[Sebastian Huber]

The consensus seems to be that rtems-tools should no longer be used for patches.

[Sebastian Huber]

Milestone renamed

[Sebastian Huber <sebastian.huber@…>]

In 3a32d15/rtems-tools:

Add tool patches warning

Update #2949.