remove packaging support for SPARC
As part of the retirement of SPARC support, I propose to simply remove the packaging data for SPARC systems.
This is an incremental step to the removal, and I'm proposing it for these reasons:
1. It makes it clear that SPARC that isn't meant to be delivered or supported anymore.
2. Partial updates to e.g. remove platforms or drivers or drivers can be a lot more challenging because of the need to detangle dependencies to not deliver busted stuff.
3. Apart from that concern, it makes the effort for follow up cleanups considerably less; no need to touch packaging at all when simply removing SPARC bits.
4. It makes the burden lower for some non-SPARC updates (e.g.)
Updated by Garrett D'Amore over 1 year ago
pkgrepo diff showed no differences:
gdamore@rts-build-01:~/ws/illumos$ man pkgrepo gdamore@rts-build-01:~/ws/illumos$ /usr/bin/pkgrepo diff -s 14786-no-sparc-pkg/packages/i386/nightly/repo.redist -s 4889-scsa-obsolete/packages/i386/nightly/repo.redist/
The table below shows the number of packages [total distinct versions]
by publisher in the specified repositories.
- Repo1: /devp02/gdamore/illumos/14786-no-sparc-pkg/packages/i386/nightly/repo.redist/
- Repo2: /devp02/gdamore/illumos/4889-scsa-obsolete/packages/i386/nightly/repo.redist/
| Publisher | Repo1 only | Repo2 only | In both | Total |
------------+------------+---------+------------+ | on-nightly | 0  | 0  | 539  | 539  |
The attached script was used to compare the contents of two repos. The resulting files (/tmp/dir1.out /tmp/dir2.out) were diff -u'd.
The only differences in content (after eliminating hash and version number changes -- see the script) is this:
--- /tmp/dir1.out Sun Jul 17 22:25:45 2022
+++ /tmp/dir2.out Sun Jul 17 22:26:23 2022
@ -29061,6 +29075,8 @
dir group=sys mode=0755 owner=root path=platform/i86xpv/kernel/tod variant.opensolaris.zone=global
dir group=sys mode=0755 owner=root path=platform/i86xpv/kernel/tod/amd64 variant.opensolaris.zone=global
file elfarch=i386 elfbits=64 group=sys mode=0755 owner=root path=platform/i86xpv/kernel/tod/amd64/xpvtod reboot-needed=true variant.opensolaris.zone=global
+dir group=bin mode=0755 owner=root path=usr/share/man
+dir facet.doc.man=true group=bin mode=0755 owner=root path=usr/share/man/man4d
link facet.doc.man=true path=usr/share/man/man4d/fdc.4d restart_fmri=svc:/system/update-man-index:default target=fd.4d
file facet.doc.man=true group=bin mode=0444 owner=root path=usr/share/man/man4d/npe.4d restart_fmri=svc:/system/update-man-index:default
dir facet.doc.man=true group=bin mode=0755 owner=root path=usr/share/man/man5
@ -35006,7 +35022,6 @
file elfarch=i386 elfbits=64 group=bin mode=0755 owner=root path=usr/lib/scsi/plugins/ses/framework/amd64/ses2.so
file elfarch=i386 elfbits=32 group=bin mode=0755 owner=root path=usr/lib/scsi/plugins/ses/framework/libses.so
file elfarch=i386 elfbits=32 group=bin mode=0755 owner=root path=usr/lib/scsi/plugins/ses/framework/ses2.so
-dir group=bin mode=0755 owner=root path=usr/lib/scsi/plugins/ses/vendor
dir group=bin mode=0755 owner=root path=usr/lib/scsi/plugins/smp
dir group=bin mode=0755 owner=root path=usr/lib/scsi/plugins/smp/engine
dir group=bin mode=0755 owner=root path=usr/lib/scsi/plugins/smp/engine/amd64
The explanation of those two entries changing:
1. We added a man page directory which was erroneously only listed for SPARC, even though we still contents into that directory (this is a fix)
2. We removed the ses/vendor plugin directory, as there was no longer anything delivered into it.
Updated by Electric Monk over 1 year ago
- Status changed from Pending RTI to Closed
- % Done changed from 80 to 100
commit 708bde8c8780e5414779e4d9e7a7648886a4700e Author: Garrett D'Amore <firstname.lastname@example.org> Date: 2022-07-19T14:48:52.000Z 14786 remove packaging support for SPARC Reviewed by: Gergő Mihály Doma <email@example.com> Reviewed by: Peter Tribble <firstname.lastname@example.org> Reviewed by: Andy Fiddaman <email@example.com> Reviewed by: Toomas Soome <firstname.lastname@example.org> Approved by: Joshua M. Clulow <email@example.com>