public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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



  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