From: Daniel Drake <dsd@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils
Date: Wed, 31 Oct 2007 14:56:59 +0000 [thread overview]
Message-ID: <472897BB.3030506@gentoo.org> (raw)
In-Reply-To: <20071031160950.42571kmkugpo1800@www2.mailstation.de>
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
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2007-10-31 15:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-31 1:56 [gentoo-dev] Resolving HAL vs. pciutils/usbutils Robin H. Johnson
2007-10-31 10:46 ` Daniel Drake
2007-10-31 11:04 ` [gentoo-dev] " Guilherme Amadio
2007-10-31 11:31 ` Jan Kundrát
2007-10-31 13:30 ` Ryan Hill
2007-10-31 15:09 ` [gentoo-dev] " Wulf C. Krueger
2007-10-31 14:56 ` Daniel Drake [this message]
2007-10-31 15:40 ` Doug Goldstein
2007-10-31 16:12 ` Roy Marples
2007-10-31 17:07 ` Rémi Cardona
2007-10-31 16:26 ` Daniel Drake
2007-10-31 16:41 ` Jan Kundrát
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=472897BB.3030506@gentoo.org \
--to=dsd@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox