Menu
▾
▴
Re: [Scrollkeeper-devel] Handling relocatable packages
|
From: Ali A. <ali...@au...> - 2000-11-27 14:32:32
|
* Nik Clayton (ni...@no...) wrote at 03:22 on 26/11/00:
> 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.
This is not scrollkeeper's problem though. We should support both instead of
imposing relocatable packages on people.
Actually, I think if we supposed relocatable packages, we will (by definition)
have supported non-relocatable packages, so this is a moot point.
> > 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.
I don't see how scrollkeeper is imposing policy. We want it to support both
relocatable and non-relocatable packages.
It seems that you want to to "impose" the policy of relocatable packages only
(although the concept of relocatable packages is policy imposing).
> > 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.
Agreed. This shouldn't be one of the "targets" for 1.0, but if somebody does
it we could include it. Also, if post-1.0 comes and it is deemed a
command-line tool is needed, then we can worry about it
> <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.
I think the goal is to make scrollkeeper "automated" enough so that Desktop
users can use it (remember - Help Documents are (usually) for new users).
Now if a sysadmin wanted to play around and mess with ScrollKeeper, I think
this also should be possible. Now, what kind of things would a sysadmin want
to do that should be supported?
> > > 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.
I really don't think this is a major issue (to specify which directory a file
goes into).
This is one of the minor details that can be taken care of.
The issue here is: support multiple ToCs and Contents Lists.
> > > 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.
I've actually never seen an OMF file *goes and hangs his head in shame*
> > > > 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).
Umm - okay, lets say I have a well-formed OMF file and then I do
'sk-generate-omf file.omf' - umm, what exactly has been "done" to this file?
Hmm, you seem to be implying that people will not write OMF files and that
they should be "extracted" from the docs. From my understanding, they are a
part of the doc (there was discussion on wether to include necessary tags in
the docs themselves, or to have separate OMF files).
I think perhaps we should just allow the '--omf:' overrides in the
sk-install-omf binary
> 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.
I think at first, ScrollKeeper will only support DocBook SGML/XML (which I
think is a decent goal for '1.0' (then from the experience with that we can
possible tackle other (more difficult) file formats)).
If a document does not have an OMF file, we should not attempt to "guess"
anything in any way. This document should not be cataloged/indexed.
ScrollKeeper is here to handle /OMF/ files, if they are not present then
obviously you shouldn't use Scrollkeeper. Even if we try to "guess" the
information, we can't figure out things like Author name, language, category,
version #, document title, etc. (esp. if ScrollKeeper is to handle things like
HTML or plain text).
> > > > 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.
Actually - this is a VERY good idea. In fact, DV just suggested this idea on
IRC which I didn't quite understand (then I read this example and I get it)...
Basically, you can have a /etc/scrollkeeper.conf file that lists all the
directories which Scrollkeeper will scan and include as entities.
I have a question though. How will this work for user's directories? Does
Scrollkeeper need to support this "indepenendently (and track it with a
~/.scrollkeeperrc)
> > > 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.
URLs are very unreliable and subject to change actually. There are not fixed
forever. You can just move them to another directory and "poof". Servers can
shutdown, etc.
[snipped the rest in an effor to conserve size]
|