rpi-imager
rpi-imager copied to clipboard
raspberrypi
Debian Packaging?
Hello,
I'm a Debian Maintainer and I noticed there was a request for packaging (RFP) for rpi-imager. Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019701
It looks like this is mostly done, and I am happy to complete this if you'd like!
Would it be possible to get an _debian.tar.gz release, without the debian directory and the dependencies directory? Both of these won't be needed for the packaging in Debian and complicate the packaging (e.g. needing license info for source in dependencies directory, debian directory needs some updates to be non-native, etc.). Of course, I will credit the original author(s) with the files used in the new debian directory.
Thank you,
Lance
Not sure whether having a Debian package is desired. Does Debian still have the policy of sticking to the same upstream software version for the duration of the Debian release?
As far as dependencies directory goes. We do use some files from there on the Linux platform as well (dependencies/mountutils/* dependencies/drivelist/* dependencies/sha256crypt/*)
Not sure whether having a Debian package is desired. Does Debian still have the policy of sticking to the same upstream software version for the duration of the Debian release?
It depends. If the package is included in the release of Debian, unless there is a security issue, it stays at that version (in the 'stable' configuration). This depends on the user/user-base. If your user base runs with the 'stable' repo only, they'll only get the package at the time of the package freeze. If they're able to update their apt sources to pull from unstable, they can get more recent updates.
The other side of this is that Ubuntu pulls from Debian unstable for their releases, so even though the package is in Debian, Ubuntu will put out more up-to-date versions.
If there is no interest, I can let the RFP author know and we can close the issue. No worries in this case also.
As far as dependencies directory goes. We do use some files from there on the Linux platform as well (dependencies/mountutils/* dependencies/drivelist/* dependencies/sha256crypt/*)
Ok, as long as they're documented and credited it should be fine.
Lance
Not sure whether having a Debian package is desired. Does Debian still have the policy of sticking to the same upstream software version for the duration of the Debian release?
As far as dependencies directory goes. We do use some files from there on the Linux platform as well (dependencies/mountutils/* dependencies/drivelist/* dependencies/sha256crypt/*)
Would using Debian Stable (and thus older packages) on a Pi cause issues? RPi OS is itself based on Debian Bookworm.
Would using Debian Stable (and thus older packages) on a Pi cause issues? RPi OS is itself based on Debian Bookworm.
Can you make a guess how many packages RPI OS had to update/customize to make things work the way they wanted?
Would using Debian Stable (and thus older packages) on a Pi cause issues? RPi OS is itself based on Debian Bookworm.
Can you make a guess how many packages RPI OS had to update/customize to make things work the way they wanted?
Distro maintenance is a bit beyond me, though with the move to wayfire and so on, I'd imagine it wasn't straightforward. I didn't know Ubuntu was based on unstable which is interesting.
In the case of rpi-imager, does this mean that if the stable package can't be updated, new images couldn't be added to the imager menu? For example if new Pi devices released during the stable release lifecycle.
In the case of rpi-imager, does this mean that if the stable package can't be updated, new images couldn't be added to the imager menu? For example if new Pi devices released during the stable release lifecycle.
It fetches the list dynamically from https://downloads.raspberrypi.com/os_list_imagingutility_v4.json
But still would be annoying if we can only have a new major Imager version in the Debian repository every 2 years, due to the way Debian's policy works.
I am not inclined to support Debian packaging at this time, and fully intend to migrate Raspberry Pi Imager to using AppImages with the next release.
We will distribute a .deb on Raspberry Pi OS that simply puts the AppImage in a sensible place and sets up the appropriate desktop files - however this is purely a convenience on our own OS, and not necessarily something I'd expect to be replicated on other platforms.
As such, closing as Won't fix
