Distro packaging: Search resources in /usr/share/bloom?

[jpf91]

Hi,

I'm considering packaging bloom for Fedora. So far I've only done packages for Archlinux though, but this might be a good opportunity to start packaging RPMs :-)

So far, I have a test repo here: https://copr.fedorainfracloud.org/coprs/jpf91/avr-gdb/ (which also includes avr-gdb and is not properly named because of that).

Apart from the build issues in https://github.com/bloombloombloom/Bloom/pull/86 and the procps compatibility issue for Fedora 39 https://github.com/bloombloombloom/Bloom/issues/87 , there's one thing I have to patch locally right now: Finding the resources.

Currently, bloom looks for a "resources" folder in a location relative to the binary. To match the linux filesystem standard, I think these files have to be in /usr/share/bloom instead. Right now, I just patch the sources to hardcode this path. But I wonder what could be a good, general solution.

I assume it'd be best if we could just specify a share dir in cmake? I think classic configure / autoconf has prefix, bindir and datadir options. To still support running the application when it's not installed in the intended location (e.g. installed into /opt/bloom instead of into /usr), I think it's better to not hardcode the full path. Probably finding the relation between bindir and datadir and then constructing the path at runtime using that information, relative to the binary (as it's done now) is best?

[jpf91]

Also the paths in the mapping file have the same issue. However, I think it would be best to just have relative paths in the mapping file be resolved relative to the location of this file?

[navnavnav]

Hello again!

Thank you very much for taking on avr-gdb packaging. I think the last RPM package was abandoned so it's great to see someone picking this up.

RE packaging Bloom, I'd like to share my views on this, but before I do, please understand that it is not my intention to come off as rude or ungrateful for the effort you've put into this.

To put it simply, I posses the following belief:

Linux software developers should be responsible for packaging their own software.

I know that many developers disagree with this. It can be incredibly difficult to package software for Linux, especially when you consider all of the different package formats, dependency management systems and the pain that comes with shared-libraries. I fully accept this, but I still, vehemently believe, that this responsibility should lie with the developer.

There are many problems developers face when relying on distro package maintainers to package software. I've listed some of them below.

1. I have no control over the package. If I want to make changes to it, I have to reach out to the maintainer and work to their schedule. And that's assuming the maintainer is reachable.
2. The time it takes for a new release to reach users will depend on the maintainer's availability (as well as the distro's process, see 3).
3. Some distros lock packages to the distro version (Debian does something like this).
4. Users will likely report any issues with the package, to me. This means I'll have to spend time looking into the issue, only to discover that the issue lies with the package and not the software. And because of 1, I won't be able to help any further, so I'll have to tell the user to (a) contact the package maintainer, or (b) use the package that I provide.
5. The maintainer rarely has the time to familiarise them self with the project. This means they won't know what to look out for when testing the package, so they'll be more likely to miss issues that I would know to look out for.
6. If the maintainer disappears, or abandons the project, I'll be left with users relying on an outdated and abandoned package.

IMHO, relying on package maintainers to package my software will result in pain in the long-term. This is why I try to package Bloom myself. There are days when I really regret this decision, but the pain is reduced by automating much of the process. I've written scripts to produce binary packages for each package format, which I run after building a new release. These scripts do most of the work for me.

So, in all honesty, I'd prefer it if you didn't package Bloom and just leave it with me. If you've found any issues with the packages that I provide, please feel free to raise them here so I can have a look.

---

With all of that said, if you still wish to package Bloom, then I will try to help where I can.

To match the linux filesystem standard, I think these files have to be in /usr/share/bloom instead.

Is there really much of a standard on this? Across distros? As I understand, some distros object to packages provided by third-parties installing files in /usr/, with the obvious exceptions like udev rules and symlinks to binaries. But this varies across distros - I think some distros are OK with it. Some distros follow the Filesystem Hierarchy Standard, but others do not. I remember having a similar conversation RE udev rules on SE.

This is why the packages I provide install Bloom into /opt/bloom, as all distros (to my knowledge), along with the FHS, agree that third-party provided packages can install into /opt.

As you've suggested, I could make the location of the resources directory changeable via a build parameter. That should allow you to specify /usr/share/bloom as the location, for your package, without requiring me to change mine. Let me know if this is something you'd like me to do.

I think it's better to not hardcode the full path

I think it's fine if the path is hard-coded in a particular build, using the value of the build parameter. This would only be an issue for users who decide to move the files after installation, which they shouldn't be doing anyway.

Also the paths in the mapping file have the same issue. However, I think it would be best to just have relative paths in the mapping file be resolved relative to the location of this file?

Ah, yes, that's annoying. I think those paths should just be relative to the resources directory. That way we don't have to constrain the location of the mapping file and we can freely change the location of the resources directory without invalidating the paths in the mapping file. I'll fix that when I get a moment.

Again, thank you for putting in all of this effort and I hope you don't think I'm being rude or unappreciative in my points RE developers packaging their own software.

[navnavnav]

BTW I've just fixed those annoying -Wreorder warnings. The fixes are in the develop branch 👍🏽

[navnavnav]

I think those paths should just be relative to the resources directory. That way we don't have to constrain the location of the mapping file and we can freely change the location of the resources directory without invalidating the paths in the mapping file. I'll fix that when I get a moment.

Have just sorted this. TDF paths are now relative to the resources directory instead of the bin directory. Changes are in the develop branch.