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
signature.asc
Description: This is a digitally signed message part
