Wulf C. Krueger wrote:
The question is not if some software is doing the right thing or not but
if our packages behave like they should for our users.
There is also value in satisfying and not deviating away from upstream,
as well as respecting values of upstream decisions (such as offering
compressed IDs to save bandwidth and disk space). But yes, the correct
software behaviour is useful too, and I wouldn't be pushing a solution
that caused a degradation in user experience.
Neither is the question if any of us are happy but if our *users* are
happy when their installation process breaks because of "that HAL bug".
We don't make HAL, its upstream or anyone but our users happy. Our
obligation is primarily to them.
pciutils has an upstream too.
I am attaching a HAL ebuild patch which is the approach
... that still potentially allows things to break because of animosities
among ourselves.
HAL handles the missing file condition at runtime if it was compiled
with support for it. So, there will be no breakage under circumstances
where the package was built for a different box. No issue here.
We have a good solution, namely robbat2's, which will make sure things
don't break for our users. IMO, that's the way to go because the other
approaches make us look bad and are unworthy of a distribution that
wants to be taken seriously.
Things already work for the users with the hal useflag for pciutils, and
things will also work with my patch in a slightly nicer/more robust way,
without having to extend the HAL issue to the pciutils package.
I'm going to drop out of this discussion here, just wanted to point out
that there is both technical reasoning behind my suggestion, no
technical flaws that I know of, and no degradation in user experience.
Only in distant corner cases would someone notice a difference, and the
"fix" is easy and documented by the ebuild messages.
Daniel
--
[EMAIL PROTECTED] mailing list
