Dan Nicholson wrote these words on 04/15/07 12:54 CST:

> That sounds good. So, <xref linkend="dbus"/>, <xref
> linkend="dbus-glib"/>, etc.? Or just one big <xref
> linkend="dbus-bindings"/>? Or prefer the individual binding xrefs. I
> might need some help with this setup. I don't think I've ever done
> that before.

I was thinking individual xref labels for each different binding
on the dbus-bindings page. So, my thoughts are one page for D-Bus
itself, and another for the bindings. And on the bindings page,
separate the different bindings into sections, each identified by
an xref label.

The Perl Modules page is a perfect example of what I'm talking
about. In fact, Dan, if you'd like I'll knock out the D-Bus
bindings page and put it in the book. Let me know.


> That's much more clever than I was thinking. I came around to your
> original idea to just having a note: "If you're planning on using HAL,
> it will only check for the uncompressed pci.ids. Be sure to decompress
> pci.ids.gz after updating, if this is the case. If you'd like to
> suppress the compression behavior in pciutils completely, pass ZLIB=no
> when executing make."
> 
> The init script works, though.

Well, for folks that don't have their network activated at boot, an
init script isn't a good solution. However, I find it perfect for me.

We will have to provide a mechanism (see instructions I do in the
previous email) to unzip the file in the HAL instructions. As long
as it is done *once*, HAL should forever not bitch about it.

And updating the pciutils page with an option to pass ZLIB=no is
not a bad idea after all. Only thing with that is that at some
point, I can see us removing it when everyone (other package
maintainers) catches up to the fact that the file is compressed.

-- 
Randy

rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3]
[GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686]
13:13:00 up 10 days, 18:10, 1 user, load average: 0.18, 0.06, 0.03
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to