Menu
▾
▴
Re: [Scrollkeeper-devel] Handling relocatable packages
|
From: Nik C. <ni...@no...> - 2000-11-26 15:25:42
|
On Wed, Nov 22, 2000 at 09:55:45PM -0600, Dan Mueth wrote:
> > Can you give me an example of non-relocatable package, and it's
> > justification for being non-relocatable?
>
> On Red Hat `rpm -qai | grep "Relocations: (not relocateable)" | wc`
> gives me 506 packages which are non-relocateable, the last of which is
> xbill:)
>
> I think Red Hat would be better qualified at explaining this decision.
Someone else bought up Gnome as an example of non-relocatable package.
Just because the original implementors didn't provide a hook to make it
non-relocatable, don't assume that other's won't have done.
> I am still uncertain if we want inheritance between contents lists though.
>
> In many cases users will not want inheritance, because they lose any
> control over what they inherit.
"many cases" means, therefore, that there will be times when users will
want inheritence.
There's a saying that's prevalent in the BSD world; "mkae tools, not policy".
Having read some of the later messages in this thread, I'm going to be
coming back to that quite a lot.
I don't care what I, personally, might need some sk. However, it's
important not to impose artificial limitations that impose my (or your)
policy for how to configure a host/network on someone else.
> We definitely want libsk.so. I'm not sure if we would want a command-line
> program for this.
It's not something we need (if someone else needs it then they can write
it). It'll probably prove to be a useful small sample application
though.
<snip>
> Aside from rebuilding the database in cases where it becomes corrupt, I'd
> like this to be a zero maintenance system that works out of the box. I
> don't think we should focus on unusual things a SA may want to
> do.
"Tools, not policy" (see, I said I'd be coming back to it). The things
that you are I think are unusual might be standard practice for someone
who wants to use sk.
> > So if you have multiple Contents Lists, you need to have multiple ToCs
> > (and Indexes), and a way of saying that >this< Contents List was used to
> > produce >This< ToC.
>
> Not if only one contents list/toc pair live in each database directory.
Tools, not policy.
I might want to put the Contents List in one directory (which is
private, and not available to the world), and publish a ToC.
We can certainly say
If you don't tell it otherwise, sk will generate the ToC in the same
place as the Contents List.
but we should make it possible for the SA to change this behaviour if
necessary.
> > Do you agree that making the distinction between a document, and one or
> > more instances of that document (different formats, different languages)
> > is worthwhile.
>
> The only way scrollkeeper knows that two docs of different
> versions/formats/languages are otherwise the same is using the extra OMF
> element (which doesn't yet exist) which assigns them an ISBN-type code
> which is the same. Since they have different IDENTIFIERS (and other
> metadata), sk knows they are different documents.
This is (possibly) something that can be handled outside of sk with
creative use of the RELATION element in the OMF.
> > > Why do we specify the format on the command line? The FORMAT is specified
> > > in the OMF already. The packager should just install and register the
> > > metadata instead of putting it on the command line.
> >
> > Because at this point, all we've done is install a document with no OMF.
> > SK has to synthesise some OMF, based on any additional information we
> > give it.
> >
> > This separation is necessary to support documents that have no separate
> > OMF. Adding "-format" to the command line is probably going to be
> > easier for an end user than having to create a separate file to return
> > to.
>
> Perhaps we agree on this after all and are just talking past each
> other. So for docs with OMF we have two steps:
> 1) update the IDENTIFIER to point to the right URL
> 2) register the OMF file with sk
>
> Really, #1 is only necessary for local docs (as opposed to remote
> ones) and for relocatable packages.
I think that's right. In my example, "sk-install-doc" is probably the
wrong name.
Ah ha, I think I've got a work around.
We've been going back and forth about what to do if a document doesn't
have OMF, or if the doc does have OMF, but the URL in the INDENTIFIER is
wrong, or whatever.
So, what if we have two command, sk-generate-omf and sk-install-omf? The
usage for this would look something like;
sk-generate-omf [--omf:creator ...]
[--omf:maintainer ...]
[--omf:contributor ...]
[--omf:title ...]
[--omf:date ...]
[<other --omf:... options]
file.omf
sk-install-omf [--omf-dir ...] /path/to/omf/file
sk-generate-omf is used to generate OMF for installation into sk. It can be
told about an existing OMF file (for example, if the document has been
distributed with an OMF file). However, it also has a series of --omf:<foo>
options, which are used to override the OMF in the .omf file, and replace
it with something else (I haven't listed them all in the synopsis above).
sk-install-omf is used to install an OMF file into SK.
In the simplest case (where the document already has a separate OMF
file), in the installation Makefile, this might look something like
PREFIX= /usr/local
APP= appname
SK_OMF_DIR= `sk-config --omf-dir`
...
install-doc:
cp ${APP}.html ${PREFIX}/share/doc/${APP}.html
sk-generate-omf --omf:identifier \
${PREFIX}/share/doc/${APP}.html ${APP}.omf
sk-install-omf --omf-dir ${SK_OMF_DIR} ${APP}.omf
All this does is take the existing ${APP}.omf file, and uses
sk-generate-omf to rewrite the IDENTIFIER in the OMF file to make sure
it points to wherever the file has been installed.
This (AFAICS) completely solves the problem of relocatable packages. We
just provide a command line interface for editing OMF files.
For documents that have no OMF (i.e., the author didn't provide one),
sk-generate-omf can be used to generate one that SK can use.
> > > Right now we just number them, which guarantees a unique identifier.
> >
> > Two problems with this:
> >
> > 1. Probably won't scale efficiently as the Contents List gets larger.
> >
> > 2. Makes it impossible to merge two separate Contents Lists, from two
> > or more sites (say you're on a univesity campus, where the biology
> > department and the chemistry department both make available their
> > list of documentation in two different Scroll Keeper Contents Lists).
>
> When sk merges seperate databases, it can easily mark them so that it
> knows where the pieces came. One way to do this would be to append a few
> digit code to the beginning of each id which describes which database it
> came from.
Yeah, but that's going to needlessly complicate the mechanism for
merging databases.
The Contents List is in XML, right. XML already has a mechanism for
saying that a file includes other files.
<?xml version="1.0">
<!DOCTYPE contents PUBLIC "-//Scrollkeeper Contents List//EN" [
<!ENTITY contents.bio SYSTEM "/path/to/biology/contents/list">
<!ENTITY contents.chem SYSTEM "/path/to/chemistry/contents/list">
]>
<contents>
&contents.bio;
&contents.chem;
</contents>
Why reinvent the wheel? All we need to do is ensure (as reasonably as
possible) that the identifiers in the different contents lists are
unique.
> > Your document browser is going to need a mechanism to uniquely
> > identify each document. If there's a strong probability that the
> > document IDs are not unique then the browsers are each going to
> > have to reinvent their own mechanism for ensuring that the
> > documents are unique.
> >
> > The documents URL might be appropriate, but it's a bit unwieldy.
>
> The document URL is a very good unique identifier, and it is already being
> passed to the help browser.
Yes, it's probably the best thing to use.
> > You really need a mechanism that can (as near as possible) guarantee
> > globally unique document IDs.
>
> I'm pretty sure that only one document lives at a given URL ;)
Not necessarily. Web servers have been known to serve up different
document depends on the settings of the browser requesting the document
(for example, it's list of acceptable languages).
> > True. However, we should allow the Index builder flexibilit in deciding
> > what documents are included in the Index. This may include producing a
> > special Index that only contains documents available in HTML, plain
> > text, and PDF (for example).
>
> What do you mean by "index"? The definition I gave for "index" in prop#3
> is what you find in the back of a book - an alphabetical list of concepts
> and links to where they are discussed in the given work. My impression is
> that you mean the Contents List here. Is that right?
Yes, my mistake.
N
--
Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95.
Telephone line, $24.95 a month. Software, free. USENET transmission,
hundreds if not thousands of dollars. Thinking before posting, priceless.
Somethings in life you can't buy. For everything else, there's MasterCard.
-- Graham Reed, in the Scary Devil Monastery
|