Jeremy Huntwork wrote:
> 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.
Not sure if I really want you to do this right now, given your words below ("It
was not the purpose of this POC"). Anyway, it can't hurt, so do as you wish.
>> * 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.
I am not sure that I can call the result "a dynamic book". Input is specified
only once--on the start page. HLFS has achieved roughly the same with plain
DocBook, profile.condition, and a chooser page that lists all possible
alternatives--i.e., all with static pages. CLFS has achieved roughly the same
(but in a more fragile way) with XIncludes that also produced static pages for
all combinations. So all this POC proves so far is that there is one more
method
to create many linear books at once. Very good, but someone has to compare
these
methods as applied to our end goal: multiarch book with multiple styles of PM,
when nobody yet has invented a multitude of other choices (i.e., it is
currently
not the case that someone requested so many options that generating a static
book for every combination is not feasible).
(the paragraph above should not be treated as a criticism, the point is that
the
investigation should be continued to see the benefits and the drawbacks of the
new approach)
> 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.
Think about partially installing several versions of the package at once. What
doesn't create file conflicts between major versions, should be split from the
rest. Basically, the items one should care about are:
1) dynamic libraries
2) their .so symlinks, static libraries and headers
3) documentation
4) message catalogs
5) other data
6) perl/python/ruby/tcl/whatever else modules & bindings
7) executable binaries (here think about multilib conflicts--e.g., you can have
only one of 32-bit and 64-bit "qtconfig" binaries installed simultaneously,
even
though both 32-bit and 64-bit Qt libraries can coexist).
(the above doesn't imply building 7 packages--ideally, these 7 items should be
grouped into one, two or three packages as required for reasonable installation
of multiple versions at once)
Anyway, it will probably boil down to specifying dirctories and filename masks
explicitly for each package, and thus is more a responsibility of the book
content writer than the framework.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
