mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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