| Summary: | Profile hardened/linux/uclibc/x86 is getting spoiled by stabilization of package versions that fail to build with uclibc | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Mark Reiche <mr20.gentoo> |
| Component: | Eclasses | Assignee: | The Gentoo Linux Hardened Team <hardened> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | normal | CC: | embedded |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Mark Reiche
2013-02-25 16:01:16 UTC
(In reply to comment #0) > I noticed two examples, but there are probably more: > - dev-db/sqlite-3.7.15.2 was stabilized in spite of Bug 458920 > - sys-apps/util-linux-2.22.2 was stabilized in spite of Bug 458496 > In both cases, the previous stable version compiled without problems with > the latest stable uclibc version. > I'm not overly worried about either of these. Read their respective bug reports. > > It is probably not desirable to hold back new versions for the majority of > the x86 users (with glibc). But I see two issues for the uclibc profile. If > not addressed, they will render that profile completely unusable in short > time :-( No they will not become completely unusable. > > 1) emerge --update world will fail. It becomes a matter of trial an error > finding the latest stable version that actually builds > 2) Eventually the latest uclibc compatible version will be tree cleaned, > because the ebuild does not show that some "stable" versions do not build on > uclibc 1) Expect breakage. 2) They will not be tree cleaned. These profiles are marked experimental, but they are not unmaintained. > > What would be a feasible solution? > - Masking the specific versions as long as according bugs are open? (solves > only issue 1) > - A separate keyword (e.g. x86-uclibc, amd64-uclibc)? > - ...? I have thought about separate keywording but that's all we need, more keyword bloat. > > Reproducible: Always The current situation is not that bad. You're using an experimental profile, so when things break 1) report a bug and 2) mask locally and keep back. If you really want, I can mask sqlite-3.7.15.2 on those profiles until posix_fallocate hits stable uclibc, but most users of those profiles know enough to mask and there are lots of packages that still break (and probably will always break) under uclibc. Please don't get me wrong: I do not want to add more effort to the gentoo developers (that's way I already expected that a separate keyword would not be a good solution). It's actually the opposite: I like to help as best as I can with the limited time that I can spend on that. So of course, the least I can do is submit bug reports with as good information as possible. I just thought if there was a way to prevent the "many" uclibc users from running into the same issues. :-) Regarding sqlite: It's not urgent for me; now I know that this particular version does not compile on uclibc, so I will wait with an update until the bug is resolved. the only real way to "fix" this is to get more devs working on uClibc. there's no way i'm going to go with a new KEYWORD. (In reply to SpanKY from comment #3) > the only real way to "fix" this is to get more devs working on uClibc. > there's no way i'm going to go with a new KEYWORD. Yeah this is not really a bug report we can act on, although true. I'm working my best at squashing bugs but at any given time there's always those few "known" issues still floating around that I'll get to. i run stable x86 on my webserver, and most things are working for me now. at least, i've got almost 400 packages living happily including postgres, apache, php, and qmail :). (In reply to SpanKY from comment #5) > i run stable x86 on my webserver, and most things are working for me now. > at least, i've got almost 400 packages living happily including postgres, > apache, php, and qmail :). I've built over 7000 packages against uclibc but amd64 hardened. |
