Hello Bastian Germann, I'm not the maintainer so my opinion on this could be considered irrelevant, but I hope you don't mind me provide some counter-arguments on this to hopefully fuel some discussion or food for though anyway...
On Fri, May 07, 2021 at 06:32:56PM +0200, Bastian Germann wrote: > Source: libubootenv > Severity: wishlist > > The binary packages that are built for "Architecture: any" should be built > for linux-any. In general I think any -> linux-any changes are thrown around way to easily. My opinion is that this is likely often caused by non-linux archs wanted to sometimes artificially bump their "%-of-archive-built" number. Since we don't have any non-linux archs even aiming for release-arch status these days, I don't see why this would matter today. Also I've too many times encountered a bug report to change any -> linux-any first, and then followed up by a bug report to request to change linux-any back to any again because the package started to actually compile on non-linux. What I meant to say is: The important thing to consider in this is if we think that this package will *never* be useful on non-linux, then linux-any is correct. But if it's just because it doesn't build on non-linux today, then I disagree with such a change. In a theoretical future where a non-linux port would for example be ported to ARM, then I think it could be very possible that they'd also want to use u-boot. > The package has at least one linux-specific import. I guess you're talking about: src/uboot_env.c:#include <linux/fs.h> That was introduced in https://github.com/sbabic/libubootenv/commit/f4b9cde3815abe84a98079cedd515283ea08c16b "Allow negative offsets" As far as I can tell it's because of the BLKGETSIZE64 usage, and while I'm not sure how you'd go about supporting "negitive offsets" in a non-linux environment it still seems easy and likely enough that the "fix" to make this portable would simply be to introduce a configure check for BLKGETSIZE64 and then `#ifdef HAVE_BLKGETSIZE64` around the relevant code and includes. This is however up to whoever does the porting the the previously discussed theoretical future to propose the best course of action. As of right now, I think it's perfectly fine to allow it to continue to fail to build from source on non-linux archs until we reach a point where it would make any real-life difference. Would be happy to hear some counter-arguments to enlighten me on what I missed. As it currently stand I'd suggest this bug report to be a 'wontfix'. Regards, Andreas Henriksson
