Revisiting ideas

[Jeremy Huntwork]

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