Randy McMurchy wrote: > Bruce Dubbs wrote these words on 01/01/06 19:35 CST:
>>DBus: We need to consider moving GLib and possibly Pyrex to recommended >>dependencies to provide more default functionality. This also means >>that we need to add Pyrex to the book. > > > GLib I can see, as it is a package that is so common throughout BLFS. > However, I'll have to disagree with Pyrex. It is only needed if you > want to build the D-BUS Python bindings, that for now are only > needed if you want the hal-device-manager program to run. > > And this takes *so* much overhead that installing Pyrex on your > own is a walk in the park compared to installing GNOME-Python. > Please keep in mind that Pyrex doesn't do anything, unless you > install all that GNOME-Python stuff as well. > > So, my argument being that if you make Pyrex a recommended dep, then > you need to make GNOME-Python recommended as well. There is no > difference. They both provide the same functionality. Are you > willing to go there? I said possibly... Your arguments are reasonable. Lets leave it at optional. However, I still think we need to add the package to the book. >>We do need to upload the Pyrex source to the mirrors and reference that >>until the home site is fixed. Evidently the author is/was a student at >>the University of Canterbury. I can find no reference to the author on >>the school roster. > > > I agree here. I have a copy if nobody else does and would be > happy to make it available to Justin so he can install it > and sync it on all the mirrors. OK. PLease put it on anduin in a place Justin can get it. >>HAL: The run time dependencies section is unique to BLFS. It is >>probably necessary for proper explanation. > > > I didn't know how else to properly do that GNOME-Python thing. > It is a beast. Keep in mind that this is what you want to make > Pyrex recommended for. Are you sure you want to do this? Nope. Discussed above. >>I do not agree with the note in the Configuration Information section. >> I think it is unnecessary and, if followed, actually make the file less >>readable due to the very long line lengths that will result. > > > I don't agree, nor disagree. I only did it because the default > HAL files in /usr/share/hal all are one-liners. We copy these > files making the one in /etc. And they really aren't that long > and are a helluva lot easier to read on one line. The method > used by BLFS make our file different than the maintainers. > That is why I provided instructions to make it the same. > > I really have no preference and the file as put in BLFS works. > I've tested it. So, if you'd like the note removed, just say > so. Yeah, lets remove it. It is xml and the line breaks are not significant. If anything, the stuff in /usr/share/hal/fdi should formatted with more line breaks (but not by us). I personally don't care for config files that have lines greater than 80-90 columns. > Again, thanks for your comments. I probably spent too much time > on HAL, but I can't help but think that it will be a significant > part of BLFS in a short period of time and we need to have it > right. I don't think you spent too much time on it. It was necessary for proper understanding and the users need these packages. This brings up another point I was thinking about. Should dbus and hal really be in LFS instead of BLFS? It seems like it is pretty much core functionality. OTOH, there are so many dependencies, we would probably need to keep it in BLFS anyway. Just a thought... -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
