From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Mike Frysinger <vapier.adi@gmail.com>, Greg KH <greg@kroah.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: usbutils 0.81 release
Date: Wed, 29 Apr 2009 16:50:37 -0300 [thread overview]
Message-ID: <20090429195037.GC1598@khazad-dum.debian.net> (raw)
In-Reply-To: <ac3eb2510904291227v48628c8j181dffc8fdfa1de6@mail.gmail.com>
On Wed, 29 Apr 2009, Kay Sievers wrote:
> > Debian places it in /var/lib/usbids/ for a good reason. So does Ubuntu.
> > Both have working "update-usbids" scripts (might be the one from upstream,
> > or something different). They also have the original file in /usr/share, I
> > don't know if usbutils was changed to check /var first then /usr, or what.
>
> Having several files on the same system sounds crazy from a distro
> standpoint. There needs to be only a single database by default. Users
We are talking about two files, here. Not several.
> can do whatever they want anyway, but packages should not support such
> a thing.
If they are to be useful, yes, they do. Or do you want us to package just
the usb-ids text file by itself and keep updating it all the time? That's
the only other possibility, and it is done for the tzdata.
But update-usbids (like update-pciids and update-intel-microcode) works just
fine, so likely the usbutils maintainer didn't have any reasons to move from
update-usbids to a volatile package.
> If the user updates it, what does a new ids file do? Overwrite it
Well, the package overwrites the older one if the download suceeds with a
mv. No mess. If the download fails, the temp file is removed, and the
older one remains untouched.
There is no mess here. And it might be a simple case of the package
creating /var/lib/usbids/usb.ids at post-install time from the static
packaged data, and usbutils always using just /var/lib/usbids/usb.ids. I am
not the maintainer of that package, and sincerely, given your tone, I am not
inclined to go fetch the source and read the scripts.
Now, I am not sure there is any checking against partial downloads. That is
one thing a more controlled volatile package would be better at.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
next prev parent reply other threads:[~2009-04-29 19:50 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-27 19:35 Greg KH
2009-04-27 20:48 ` Alan Stern
2009-04-27 21:00 ` Greg KH
2009-04-27 21:21 ` Alan Stern
2009-04-27 21:36 ` Kay Sievers
2009-04-29 14:23 ` Benny Amorsen
2009-04-29 15:51 ` Alan Stern
2009-04-29 17:27 ` Mike Frysinger
2009-04-29 17:42 ` Greg KH
2009-04-29 20:23 ` Alan Stern
2009-04-27 21:07 ` Kay Sievers
2009-04-27 21:54 ` Alan Stern
2009-04-27 22:02 ` Kay Sievers
2009-04-29 17:53 ` Mike Frysinger
2009-04-29 18:07 ` Greg KH
2009-04-29 18:17 ` Mike Frysinger
2009-04-29 18:30 ` Greg KH
2009-04-29 23:38 ` Mike Frysinger
2009-04-30 0:45 ` Kay Sievers
2009-04-30 1:48 ` Mike Frysinger
2009-04-30 1:54 ` Kay Sievers
2009-04-30 1:58 ` Mike Frysinger
2009-04-29 18:59 ` Kay Sievers
2009-04-29 19:18 ` Henrique de Moraes Holschuh
2009-04-29 19:26 ` Greg KH
2009-04-29 19:44 ` Kay Sievers
2009-04-29 19:27 ` Kay Sievers
2009-04-29 19:50 ` Henrique de Moraes Holschuh [this message]
2009-04-29 19:55 ` Kay Sievers
2009-04-29 20:00 ` Henrique de Moraes Holschuh
2009-04-29 20:39 ` Kay Sievers
2009-04-30 6:31 ` Bjørn Mork
2009-04-29 19:23 ` Greg KH
2009-04-29 21:42 ` Valdis.Kletnieks
2009-04-29 21:56 ` Greg KH
2009-04-29 22:19 ` Valdis.Kletnieks
2009-04-30 1:48 ` Kay Sievers
2009-04-30 1:56 ` Mike Frysinger
2009-04-30 2:06 ` Kay Sievers
2009-04-30 2:13 ` Mike Frysinger
2009-04-30 4:54 ` Greg KH
2009-04-29 21:57 ` Kay Sievers
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=20090429195037.GC1598@khazad-dum.debian.net \
--to=hmh@hmh.eng.br \
--cc=greg@kroah.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=vapier.adi@gmail.com \
/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
Powered by JetHome