On Fri, 2021-01-22 at 12:25 +0100, Andreas Färber wrote:
Hi Nicolas,
On 22.01.21 11:35, Nicolas Saenz Julienne wrote:
Now, here's the issue, the packages I mentioned above were designed based on the assumption we had to do things differently. It's not the case anymore and I'd like to limit the amount of divergence with debian/raspbian WRT packaging as well. I see two options:
- Obsolete 'raspberrypi-firmware-eeprom' and 'rpi-eeprom-config' to create a new package 'rpi-eeprom.' Which is a 1:1 copy of what the Debian package does.
- Upgrade 'raspberrypi-firmware-eeprom', 'rpi-eeprom-config' and introduce 'rpi-eeprom-update.' On top of that create a pattern 'rpi-eeprom' that installs everything. We'd avoid obsoleting anything, but IMO it'd be harder to maintain in the long run.
So, what do you advise I do? I personally like the first option better.
I really hate that rpi-foo naming.
+1
We do have raspberrypi-firmware naming for a long time, stemming from github.com/raspberrypi/firmware. Thus, having related source packages in OBS be called raspberrypi-foo rather than rpi-foo makes them easiest to find within a devel project. You can always add Provides to the spec file, to allow for installation via Raspbian-compatible package names.
In summary, we'll have a package called 'raspberrypi-eeprom', with 'Provides: rpi-eeprom' and two sub-packages 'raspberrypi-eeprom-firmware' and 'raspberrypi-eeprom-tools'. Regards, Nicolas