Alexander E. Patrakov wrote: > Glibc is not the best example for discussion. I requested such sample page > for > bash, not for glibc, for a reason: bash needs a specific patch in the RPM > case, > and I don't see the way to force such PM-specific instructions in the current > framework.
I expected you to bring this up. :) I wanted to test a package that also showed variance on architecture. Glibc fit that. As for forcing PM-specific instruction, that ability may not be present, but I don't believe it would be overly difficult to introduce. If you wish, I'll add the bash page as another example. > * making one big RPM package with both the shared library and its headers > is > technically incorrect (this is not so severe for glibc, but think about > gradual > updates from libssl.so.0.9.8 to libssl.so.0.9.9, and that's impossible > without > removing a lot of dependent packages if one doesn't package the conflicting > headers in a separate RPM file); > > * the current framework doesn't allow for such split; > > * editors that don't use a package manager have to be taught about this. Well this is a sort of build methodology that needs to be worked out if bringing RPM to the table. It was not the purpose of this POC to sort out all of these issues, but merely to demonstrate how we can make the book dynamic. Again, once we know what core things need to be marked and defined in order to produce such a packaging split, I don't think it would be difficult to add it in the framework. Since I haven't had experience with creating such split packaging, help with determining what is needed would be appreciated. > As for the generated pages: if the LiveCD is to be revived, this means > packaging > PHP and some lightweight HTTP server on it (I prefer lighttpd). It also means > increased requirements for mirrors, both in terms of available software and > the > level of trust to the book authors (i.e., so that they don't put a malicious > PHP > script in order to compromise a lot of mirrors at once, or just > unintentionally > introduce a security hole). Are we ready to this? Good question. I don't know the answer to it. > P.S. Sorry for several hackish HTTP requests to www.linuxfromscratch.org. So > far, I have found no obvious way to compromise the scripts in the current PHP > configuration. Well, that's good. :) -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
