https://fedoraproject.org/wiki/Changes/F38-FPC-repackaging
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == Split the `fpc` package (the Free Pascal Compiler) into several sub-packages (built from the same spec file).
== Owner == * Name: [[User:suve|Artur Frenszek-Iwicki]] * Email: fedora@svgames.pl
== Detailed Description == The `fpc` package will be split into three packages: * `fpc` - the compiler itself, plus utility programs * `fpc-ide` - the terminal-based TUI IDE (`/usr/bin/fp`) * `fpc-units-ARCHNAME-linux` - pre-compiled units (think "FPC's stdlib") for developing programs for Linux
The "units" subpackage will be a shared dependency for both `fpc` and `fpc-ide`.
== Benefit to Fedora == The TUI IDE will be moved to a separate package, slightly reducing the download size for packages requiring FPC to build.
Putting Linux units in an `fpc-units-ARCHNAME-linux` package will create a precedent which can be used in the future for introducing cross-compilation packages, like `fpc-units-x86_64-win64` for MS Windows.
== Scope == * Proposal owners: ** Edit `fpc.spec` as required and rebuild the package, preferably before the Mass Rebuild.
* Other developers: No action required.
* Release engineering: No action required.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact == After upgrading to Fedora 38, users interested in the TUI IDE will need to manually install the `fpc-ide` package. For those not interested in the TUI IDE, there will be no impact.
== How To Test == A copr repository has been created where users can test out the modified package: [https://copr.fedorainfracloud.org/coprs/suve/fpc-split/ copr/suve/fpc-split].
This copr repository also modifies the spec to build units for MS Windows (`x86_64` only), allowing for cross-compilation.
== User Experience == For users not interested in the TUI IDE, this Change will slightly reduce the install size (about 1.5 MiB for the IDE plus another 3.5 MiB for its dependencies).
Since the TUI IDE does not launch the compiler as a sub-process, but rather contains an embedded copy of the compiler, users who use only the IDE and not the standalone compiler will benefit in a similar way - they will be able to install just the IDE, without the main compiler package.
== Dependencies == None.
== Contingency Plan == Worst case scenario - give up, revert to an old version of `fpc.spec` and rebuild the package.
== Documentation == N/A (not a System Wide Change)
== Release Notes == The `fpc` package no longer includes the terminal-based TUI IDE. Users interested in the IDE should install the `fpc-ide` package.
On Fri, Dec 30, 2022 at 02:06:20PM -0500, Ben Cotton wrote:
== Detailed Description == The `fpc` package will be split into three packages:
- `fpc` - the compiler itself, plus utility programs
- `fpc-ide` - the terminal-based TUI IDE (`/usr/bin/fp`)
- `fpc-units-ARCHNAME-linux` - pre-compiled units (think "FPC's
stdlib") for developing programs for Linux
The "units" subpackage will be a shared dependency for both `fpc` and `fpc-ide`.
== Upgrade/compatibility impact == After upgrading to Fedora 38, users interested in the TUI IDE will need to manually install the `fpc-ide` package. For those not interested in the TUI IDE, there will be no impact.
Do you plan to add the usual Obsoletes:fpc<… to both fpc and fpc-ide so that both are installed on upgrades? This would make the user experience nicer.
Zbyszek
Haven't planned on this originally, but it seems like a good idea.
Never really used Obsoletes before, so I have to ask: what's the dnf behaviour when a package is obsoleted by multiple packages? If it tries to install all of them, then that'd be okay. I'd like to avoid a situation where dnf decides that it prefers to upgrade by removing the "old" fpc package and installing only fpc-ide.
A.FI.
On Tue, Jan 17, 2023 at 10:33:10AM -0000, Artur Frenszek-Iwicki wrote:
Haven't planned on this originally, but it seems like a good idea.
Never really used Obsoletes before, so I have to ask: what's the dnf behaviour when a package is obsoleted by multiple packages? If it tries to install all of them, then that'd be okay. I'd like to avoid a situation where dnf decides that it prefers to upgrade by removing the "old" fpc package and installing only fpc-ide.
You need to add 'Obsoletes: $original_package_name < $some_version_after_split' to both the $original_package_name subpackage and to the new split-out subpackage. With that, dnf will install both on upgrade of $original_package_name.
Zbyszek
After the mass rebuild, some of my packages requiring fpc are now FTB because fpc-units are not installed in the buildroot. Sorry to not have caught this before, but the change proposal should have included the necessary BuildRequire change for all dependent packages.
Moreover, having the units subpackages named `fpc-units-ARCHNAME-linux` is extremely unfriendly. The subpackages will already be built for the relevant architecture, there's no need to have the arch specified in the name. Can we have this changed? I'll wait for a reply before applying the fix to my packages.
Thanks Mattia
fpc has a Requires: on the units package, so it should always be installed.
The build failures for packages using FPC, as far as I can see, are all packages using Lazarus. As far as I can tell, this is because Lazarus seems to quite tightly depend on specific FPC versions, and historically, whenever we updated/rebuilt FPC, we also rebuilt Lazarus. This time I completely forgot to do this.
I may be wrong here, but I'm like 99% sure that, since Lazarus was eventually rebuilt during the Mass Rebuild, once lazarus-2.2.4-2.fc38 lands in the rawhide buildroot, it should be possible to resubmit any failed packages as-is and they'll work this time.
A.FI.
Il 24/01/23 18:02, Artur Frenszek-Iwicki ha scritto:
fpc has a Requires: on the units package, so it should always be installed.
The build failures for packages using FPC, as far as I can see, are all packages using Lazarus. As far as I can tell, this is because Lazarus seems to quite tightly depend on specific FPC versions, and historically, whenever we updated/rebuilt FPC, we also rebuilt Lazarus. This time I completely forgot to do this.
I may be wrong here, but I'm like 99% sure that, since Lazarus was eventually rebuilt during the Mass Rebuild, once lazarus-2.2.4-2.fc38 lands in the rawhide buildroot, it should be possible to resubmit any failed packages as-is and they'll work this time.
You're probably right, I now see that fpc-units-<arch> was installed in the buildroot on the failed builds. I'll try to resubmit the builds and see what happens.
Thank you.
Mattia