#2949 closed defect (wontfix)

Questionable patch organization in RTEMS tools and RSB

Reported by: Sebastian Huber Owned by:
Priority: normal Milestone: 5.1
Component: tool/rsb Version:
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description

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.

Change History (16)

comment:1 Changed on Mar 22, 2017 at 12:25:02 PM by 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.

comment:2 Changed on Mar 22, 2017 at 11:42:36 PM by 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.

Last edited on Mar 22, 2017 at 11:43:03 PM by Chris Johns (previous) (diff)

comment:3 Changed on Mar 23, 2017 at 3:53:24 PM by 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.

comment:4 in reply to:  3 Changed on Mar 24, 2017 at 1:28:52 AM by 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?

comment:5 Changed on Mar 24, 2017 at 4:29:59 AM by 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.

comment:6 Changed on Mar 24, 2017 at 10:27:31 AM by Sebastian Huber

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

comment:7 Changed on Mar 24, 2017 at 10:27:34 PM by Chris Johns

Sebastian, I did not understand your last comment.

comment:8 Changed on Mar 27, 2017 at 4:37:32 AM by 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.

comment:9 Changed on Mar 27, 2017 at 5:18:29 AM by 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.

comment:10 in reply to:  6 Changed on Mar 27, 2017 at 5:20:21 AM by 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.

comment:11 in reply to:  9 Changed on Mar 27, 2017 at 5:42:35 AM by 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.

comment:12 Changed on May 11, 2017 at 7:31:02 AM by Sebastian Huber

Milestone: 4.124.12.0

comment:13 Changed on Jun 8, 2017 at 7:54:08 AM by Sebastian Huber

Resolution: wontfix
Status: newclosed

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

comment:14 Changed on Oct 16, 2017 at 6:26:07 AM by Sebastian Huber

Component: unspecifiedtool/rsb

comment:15 Changed on Nov 9, 2017 at 6:27:14 AM by Sebastian Huber

Milestone: 4.12.05.1

Milestone renamed

comment:16 Changed on Nov 13, 2017 at 7:39:52 AM by Sebastian Huber <sebastian.huber@…>

In 3a32d15/rtems-tools:

Add tool patches warning

Update #2949.

Note: See TracTickets for help on using tickets.