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. 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. So put it this way, even if we don't have to name things differently, it may make sense to do it cleaner - in particular since our distro is for more than just one platform. That is obviously independent of whether we split or combine packages. Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)