scrollkeeper-devel — Developer discussion list for ScrollKeeper

Re: [Scrollkeeper-devel] 0.3

[Dan M. <d-...@uc...>]

On Fri, 7 Sep 2001, David Merrill wrote:

> What is the plan for 0.3, and is there an estimated release date?

I think Laszlo and Mary have basically finished adding the rather long new
feature list to take us from 0.2 to 0.3.  Laszlo will send out a summary
of where things stand next week when he gets back from his holiday.

Once we get the status and see if there are any holes which still need to
be filled, we basically just need to do a bunch of testing and debugging.
I'm hoping a couple people will step forward to help us run through the
0.3.x releases and get close to our next stable release 0.4.

Dan

[Scrollkeeper-devel] 0.3

[David M. <da...@lu...>]

What is the plan for 0.3, and is there an estimated release date?

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                   da...@lu...
Collection Editor & Coordinator            http://www.linuxdoc.org

Free Dmitry Sklyarov!  http://www.freesklyarov.org
Washington DC Protests http://www.lupercalia.net/dmca

Re: [Scrollkeeper-devel] ScrollServer

[David M. <da...@lu...>]

On Fri, Sep 07, 2001 at 12:36:26AM -0500, Dan Mueth wrote:
> 
> On Thu, 6 Sep 2001, David Merrill wrote:
> 
> > Greetings ScrollKeeper Hackers,
> >
> > I'm putting together a Python based front end to the ScrollKeeper
> > database which I'm calling ScrollServer. It is in a preliminary stage
> > but anyone who wants to look at it is welcome to.
> >
> > ScrollServer loads the extended contents list into an object
> > hierarchy, and then provides an HTML interface to the documents using
> > the SimpleHTTPServer class which comes with Python.
> >
> > The idea is that rather than needing the Gnome Help Browser or
> > Konqueror to get to the database, you can use any browser, including
> > Lynx at the command line.
> >
> > Today, it only supports a single view (a hierarchical list of the
> > documents by their section) and local html files.
> 
> This sounds like a really great project.   I'm happy to see somebody
> working on this already :)

It has been fun so far, and it will be important to some of us who
want our help at the command line.

> > Questions:
> >
> > Do you plan to prepend file:// to the source file location?
> 
> Yes.  I think we left this out in early releases but I believe it was
> added at some point - perhaps the development version in CVS.

Can I get a cvs account set up?

> > When do you plan to support http:// (remote files)
> >
> > Do you plan to support ftp:// at any point?
> 
> This is not really high on my personal list of priorities.  However, I
> would expect that anybody who wants to add this could do so at any time.
> It certainly makes things more interesting and powerful.  It also makes
> things a bit more complicated because you have to consider the behavior
> when docs dissappear or one's entire internet connectivity goes down.

It's higher on mine. So I guess that means if I want it I have to do
it myself. :-)

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                   da...@lu...
Collection Editor & Coordinator            http://www.linuxdoc.org

Free Dmitry Sklyarov!  http://www.freesklyarov.org
Washington DC Protests http://www.lupercalia.net/dmca

Re: [Scrollkeeper-devel] leaving the project

[John F. <jf...@in...>]

On Fri, Sep 07, 2001 at 06:41:18AM +0100, Laszls Kovacs wrote:
> Hi All,
> 
> I wanted to let people know that I can not work on Scrollkeeper anymore.
> It is part of working for a regular wage that I do not have 100% control
> on what do I work on and people who pay for my work decided that I
> should work on something else. 
> 
> This was my first open source project and it was great to be part of it.
> I gained a lot of experience about both software and people.
> 
> I will stay on the mailing list and help whoever wants to continue the
> work I did. I will probably only read queries adressed directly to me
> rather than participating at design related discussion in the future.
> 
> Thanks for everything and all the best,
> 

:-(

I'm so sorry to hear this Laszlo. Thanks so much for the huge amount
of help you gave us (and *me* in particular) over the last year.

Hope you continue to have fun at your new task.

Cheers,
-- 
John Fleck
jf...@in... (h), http://www.inkstain.net/fleck/

[Scrollkeeper-devel] leaving the project

[<las...@su...>]

Hi All,

I wanted to let people know that I can not work on Scrollkeeper anymore.
It is part of working for a regular wage that I do not have 100% control
on what do I work on and people who pay for my work decided that I
should work on something else. 

This was my first open source project and it was great to be part of it.
I gained a lot of experience about both software and people.

I will stay on the mailing list and help whoever wants to continue the
work I did. I will probably only read queries adressed directly to me
rather than participating at design related discussion in the future.

Thanks for everything and all the best,

Laszlo

Re: [Scrollkeeper-devel] ScrollServer

[Dan M. <d-...@uc...>]

On Thu, 6 Sep 2001, David Merrill wrote:

> Greetings ScrollKeeper Hackers,
>
> I'm putting together a Python based front end to the ScrollKeeper
> database which I'm calling ScrollServer. It is in a preliminary stage
> but anyone who wants to look at it is welcome to.
>
> ScrollServer loads the extended contents list into an object
> hierarchy, and then provides an HTML interface to the documents using
> the SimpleHTTPServer class which comes with Python.
>
> The idea is that rather than needing the Gnome Help Browser or
> Konqueror to get to the database, you can use any browser, including
> Lynx at the command line.
>
> Today, it only supports a single view (a hierarchical list of the
> documents by their section) and local html files.

This sounds like a really great project.   I'm happy to see somebody
working on this already :)

> Questions:
>
> Do you plan to prepend file:// to the source file location?

Yes.  I think we left this out in early releases but I believe it was
added at some point - perhaps the development version in CVS.

> When do you plan to support http:// (remote files)
>
> Do you plan to support ftp:// at any point?

This is not really high on my personal list of priorities.  However, I
would expect that anybody who wants to add this could do so at any time.
It certainly makes things more interesting and powerful.  It also makes
things a bit more complicated because you have to consider the behavior
when docs dissappear or one's entire internet connectivity goes down.

> When will you add man pages?
>
> When will you add info pages?
>
> Do you have, or wish to have, a script that searches for man/info
> pages and adds them to the database? If so, how should it work?

I'm still unsure of how we want to deal with man and info pages.
ScrollKeeper doesn't have a whole lot to add here, since I doubt anybody
will want to write up OMF files for every man and info page out there.
I am guessing we will want to use some sort of a script which looks at
certain paths and extracts the info naturally embedded in these formats.
While this will be much more limitted than what we can do with
DocBook/OMF, I think it will still be a nice feature.  This is another
really good project for any hacker who is interested.

> How would you feel about a project whose package did nothing except
> install meta-data into the SK database? I'm thinking I could provide
> links to all the LDP docs in the local database just by having a
> `package' (.deb on debian) which adds the meta=data.

This is an interesting interim idea.  Eventually we would want to have the
metadata ship with the docs.  In the mean time, this sounds like a fine
idea.  I'm not sure if it is much less work than just making new packages
of the docs.

As soon as we support remote documents (http://, ftp://), it may make a
sense to have special packages of metadata for remote documents.  For
example, we could have ldp-remote-docs-1.noarch.rpm which just has a bunch
of OMF files which point to documents on the LDP web server.  I'm not sure
how well this works though since SK would have to download them all in
order to create the index files and other generated metadata files.  It
might work better to have remote metadata servers which your local machine
communicates with, just passing the metadata back and forth until the user
identifies which parts of which documents they want to read.

> Would you like to include the LDP meta-data in SK as it is shipped?

I don't see how this is possible, since the location(file://???), version,
existance, etc. of the file will vary with distribution.  I guess the FHS
helps us in terms of its location, but version and existance may still be
a problem.  I think shipping the metadata with the documents is the best
approach.

> Do you think any of this functionality, specifically the Python based
> object hierarchy, belongs as part of ScrollKeeper itself?

I'll assume "no" until you illustrate the contrary ;)

> Do you plan to implement search functionality, or is that the
> responsibility of each browser?

I think we would eventually like to support searching in ScrollKeeper,
although it will probably mean we use some existing text indexing program
like medusa to do all the work.  I think the reason why it belongs in (or
under) ScrollKeeper is that when we eventually have the ability for two
ScrollKeeper systems to communicate and share metadata, we will want one
server to ask the other to do a search and not to pass all the documents
across the net to do the search.

I'm not sure how well-suited medusa is for this task... I've been told it
would not need too much modification to accept a list of files to index.
I'm also not sure what other indexing apps are out there.  Hmmm...
Finding the right text indexing tool and hooking it into ScrollKeeper
seems like yet another project for a new hacker who wants to help out :)

Of course I'd *really* like to see all the functionality for ScrollKeeper
0.3.x get worked out and tested, and a stable 0.4.0 come out.  The new
features are really a huge improvement over 0.2 but need a lot of testing
and possibly a fair amount of work yet.  (Care to comment on the current
status Laszlo and Mary?)

Dan

[Scrollkeeper-devel] ScrollServer

[David M. <da...@lu...>]

Greetings ScrollKeeper Hackers,

I'm putting together a Python based front end to the ScrollKeeper
database which I'm calling ScrollServer. It is in a preliminary stage
but anyone who wants to look at it is welcome to.

ScrollServer loads the extended contents list into an object
hierarchy, and then provides an HTML interface to the documents using
the SimpleHTTPServer class which comes with Python.

The idea is that rather than needing the Gnome Help Browser or
Konqueror to get to the database, you can use any browser, including
Lynx at the command line.

Today, it only supports a single view (a hierarchical list of the
documents by their section) and local html files.

Questions:

Do you plan to prepend file:// to the source file location?

When do you plan to support http:// (remote files)

Do you plan to support ftp:// at any point?

When will you add man pages?

When will you add info pages?

Do you have, or wish to have, a script that searches for man/info
pages and adds them to the database? If so, how should it work?

How would you feel about a project whose package did nothing except
install meta-data into the SK database? I'm thinking I could provide
links to all the LDP docs in the local database just by having a
`package' (.deb on debian) which adds the meta=data.

Would you like to include the LDP meta-data in SK as it is shipped?

Do you think any of this functionality, specifically the Python based
object hierarchy, belongs as part of ScrollKeeper itself?

Do you plan to implement search functionality, or is that the
responsibility of each browser?

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                   da...@lu...
Collection Editor & Coordinator            http://www.linuxdoc.org

Free Dmitry Sklyarov!  http://www.freesklyarov.org
Washington DC Protests http://www.lupercalia.net/dmca

[Scrollkeeper-devel] Building the unstable ScrollKeeper

[Dan M. <d-...@uc...>]

Hi,

In order to build the unstable ScrollKeeper from CVS, as well
as the upcoming 0.3 release, one needs to have the latest
DocBook/SGML tools installed as specified in the LSB.
Starting with 7.1, Red Hat has moved over to these tools.  I'm
not sure whether any other distributions have made the move yet
or when they plan to.  (Anybody know?)  Even if you have RH 7.1, you will
need to upgrade/install a few packages.

To upgrade a Red Hat distribution, you should uninstall,
upgrade, and install the following:

Remove:
        docbook
        stylesheets
        jade
        (gnome-doc-tools if you have it)

Upgrade:
        sgml-common
        openjade
        jadetex

Install:
        libxml2
        libxml2-devel
        libxslt
        libxslt-devel
        xml-i18n-tools >= 0.8.4
        perl-SGMLSpm (neede by docbook-utils)
        sgml-tools
        docbook-utils
        docbook-utils-pdf
        docbook-style-dsssl
        docbook-dtd30-sgml
        docbook-dtd31-sgml
        docbook-dtd40-sgml
        docbook-dtd41-sgml
        docbook-dtd41-xml
        docbook-dtd412-xml
        (gnome-doc-tools-2 if you hack on GNOME)

Optional:
        psgml

To make things a bit easier, I have uploaded most of these RPMs to:
     http://scrollkeeper.sourceforge.net/sk_kit5/
since the sourceforge ftp site was misbehaving :(

This should be sufficient to get things working on Red Hat.
Note that if you use a modified DocBook DTD, like GNOME 1.x
does, then you should build docs with "jw -c /etc/sgml/catalog
file.sgml -o dir" instead of db2html.  The stable (1.x) version
of ScrollKeeper should still work fine with these newer tools.

If anybody has any problems or amendments to this information,
please email me or this list.

If anybody has information about how to get things working on
other distributions, please email this list with instructions.

Dan

PS: I'll be out of touch of email for a couple days, so I won't be able to
respond to replies right away.

Re: [Scrollkeeper-devel] Configurability of OMF_DIR

[Dan M. <d-...@uc...>]

On Sun, 15 Jul 2001, L=E1szl=F3 Kov=E1cs wrote:

> Hi,
>
> I added /etc/scrollkeeper.conf with an extensive default value, and thi=
s
> is processed by Scrollkeeper now. The priorities are, the "-o" flag
> overwrites everything, then OMF_DIR environment variable, then
> /etc/scrollkeeper.conf, then scrollkeeper-config --omfdir.

Awesome.  The feature list of 0.3 over 0.2 is getting huge.

> I couldn't figure out how to make configurable as I don't know how to
> make a new configure option (like --omfdirs or similar). If anybody
> knows, please let me know.

You mean for autoconf, right?  I think you would do it like:

AC_ARG_WITH(omf-dirs, [  --with-omfdirs=3DDIR   Location of OMF
directories])

if test "x$with_omfdirs" =3D x ; then
  omfdirs=3D/usr/share/omf:/usr/local/share/omf
else
  omfdirs=3D$with_omfdirs
fi

AC_DEFINE_UNQUOTED(OMFDIRS, "$omfdirs")

For more examples check out gnome-core which does a lot of this.

Dan

Re: [Scrollkeeper-devel] Scrollkeeper file format improvements?

[Dan M. <d-...@uc...>]

On Sun, 15 Jul 2001, L=E1szl=F3 Kov=E1cs wrote:

> I just noticed that I didn't finish this thread. So final suggestion is=
:
>
> From:
>
> <tocsect1 linkid=3D"intro">Introduction
>      <tocsect2 linkid=3D"whatisscrollkeeper">What is ScrollKeeper?
>      </tocsect2>
> <tocsect1>
>
> To:
>
> <tocitem target=3D"intro">Introduction
>      <tocitem target=3D"whatisscrollkeeper">What is ScrollKeeper?
>      </tocitem>
> <tocitem>
>
> Comments?

Looks fine to me.

Dan

Re: [Scrollkeeper-devel] Configurability of OMF_DIR

[<las...@Su...>]

Hi,

I added /etc/scrollkeeper.conf with an extensive default value, and this
is processed by Scrollkeeper now. The priorities are, the "-o" flag
overwrites everything, then OMF_DIR environment variable, then
/etc/scrollkeeper.conf, then scrollkeeper-config --omfdir.


I couldn't figure out how to make configurable as I don't know how to
make a new configure option (like --omfdirs or similar). If anybody
knows, please let me know.

Laszlo

Re: [Scrollkeeper-devel] Scrollkeeper file format improvements?

[<las...@Su...>]

> > Second the TOC:
> >
> > Functionally JavaHelp and Scrollkeeper files are the same so there is
> > only a little room for changes with obvious benefit.
> >
> > Scrollkeeper format is:
> >
> > <tocsect1 linkid="intro">Introduction
> >     <tocsect2 linkid="whatisscrollkeeper">What is ScrollKeeper?
> >     </tocsect2>
> >     <tocsect2 linkid="aboutthisdoc">About This Document
> >     </tocsect2>
> >     <tocsect2 linkid="authors">Authors
> >     </tocsect2>
> >     <tocsect2 linkid="scrollkeeperlicense">ScrollKeeper License
> >     </tocsect2>
> > </tocsect1>
> >
> > The numbering of the tocsects caused me tremendous problems while
> > writing the TOC extractor stylesheet (although that was my first ever
> > stylesheet, it is not that difficult actually). I think we should get
> > rid of those numbers regardless of other changes. The only help browser
> > using Scrollkeeper currently that I know of is Nautilus and it doesn't
> > use those numbers at all. No code change would be needed there if the
> > numbers go.
> 
> Sounds reasonable.  I think the reason they are there are because DocBook
> uses <sect1>, <sect2>, etc.  It would be interesting to know the reason
> why DocBook numbers their sections.  I suspect it is (a) for the author,
> since they read and write the markup and having numbers helps keep them
> from getting confused, and (b) <books>, <articles>, etc. have strict rules
> on how they can be sectioned.  Neither of these really apply here, so I
> think we can do away with the numbers if there is any incentive to do so,
> such as making things simpler.
> 
> > The JavaHelp TOC file is:
> >
> > <tocitem image="toplevelfolder" text="Java Development Environment">
> >     <tocitem target="jde.intro">Introduction to JDE Online Help />
> >     <tocitem text="IDE Tutorial" target="tut.starttoc">
> >         <tocitem text="Introducing JDE" target="tut.intro" />
> >         <tocitem text="Tutorial One" target="tut.quickstart" / >
> >         <tocitem text="Tutorial Two" target="tut.edit" />
> >         <tocitem text="Tutorial Three" target="tut.errors" />
> >     </tocitem>
> > </tocitem>
> >
> > It holds the same info as Scrollkeeper's, if there is no technical
> > reason against it, I would support switching to it.
> 
> Somebody mentioned on this list a little while back that one should not
> have "running text" as an attribute.
> 
> Dan

I just noticed that I didn't finish this thread. So final suggestion is:

From:

<tocsect1 linkid="intro">Introduction
     <tocsect2 linkid="whatisscrollkeeper">What is ScrollKeeper?
     </tocsect2>
<tocsect1>

To:

<tocitem target="intro">Introduction
     <tocitem target="whatisscrollkeeper">What is ScrollKeeper?
     </tocitem>
<tocitem>

Comments?

Laszlo

[Scrollkeeper-devel] Re: relocatable package support

[<las...@Su...>]

Dan Mueth wrote:
> 
> A little bit of browsing around linux.redhat.rpm turned up
> RPM_INSTALL_PREFIX as the variable which stores the prefix which will be
> used.  I'm not sure if PREFIX is overwritten, but even if it is it should
> be easy enough to store it as another variable name.  So, let's assume we
> always have access to the default and relocated prefix.  (Here I'm
> assuming other packaging systems are at least as good as RPM ;)
> 
> I think two main systems have been proposed:
> 
> 1) Do not include the prefix in the OMF file until post-install time.  We
> won't need the pre-install step. At post-install time, the
> scrollkeeper-update-url script is run which modifies the OMF files and
> inserts the prefix into the URLs.  In this case, relocatable and
> non-relocatable packages are handled identically.
> 
> 2) Include the prefix in the OMF file with scrollkeeper-preinstall, as we
> do now.  For relocatable packages only, one adds an additional
> post-install call to a script, scrollkeeper-update-url, which replaces the
> unrelocated prefix with the relocated one.  In this case, unrelocated and
> relocated packages are still handled pretty much the same except that one
> (simple) extra line is added to the spec file.
> 
> I don't see any technical problems with either of these approaches.  (Does
> anybody?)
> 
> So, I'm inclined to use whichever one is simplest for package authors to
> understand and implement.  I think #1 is probably simpler even though it
> introduces a second post-install script, since it gets rid of
> scrollkeeper-preinstall and uses the same method for both relocatable and
> non-relocatable packages.
> 
> We could allow people to choose either of the two, but I think that just
> complicates things.
> 
> Dan

I prefer (1), it is simpler to implement and simpler to use.

Laszlo

Re: [Scrollkeeper-devel] Configurability of OMF_DIR

[<las...@Su...>]

Dan Mueth wrote:
> =

> On Thu, 28 Jun 2001, L=E1szl=F3 Kov=E1cs wrote:
> =

> > One more thing, with this we would have three ways of specifying OMF
> > file locations.
> >
> > We have:
> >
> > - and environment variable OMF_DIR
> > - the scrollkeeper.conf variable OMF_DIR
> > - the -o flag of scrollkeeper-update
> >
> > This is probably too much. I think the environment variable should go=

> > away and maybe the -o flag also. If -o stays then the final set of
> > directories should be the unification of the -o list and the OMF_DIR
> > list from scrollkeeper.conf.
> >
> > Thoughts?
> =

> We certainly need to keep scrollkeeper.conf, so distributions can set u=
p a
> reasonable system.  The OMF_DIR variable is very nice for people
> developers, who set up different paths with development or stable
> versions.  It is also the only nice way for users to set up their own
> databases in their home directory.  I suppose you could have a
> .scrollkeeper file in a user's home directory instead of having OMF_DIR=
,
> but that doesn't really work for systems where you want to switch back =
and
> forth between using two different databases (as done by developers with=

> stable and unstable prefixes).  So, I think we really should keep the
> environment variable too.
> =

> I believe we originally introduced the -o flag so that when a person is=

> building an RPM they create a database in a path under the BUILDROOT.  =
In
> this case, using scrollkeeper.conf would do the wrong thing.  I'm not
> sure if we can simply set OMF_DIR before running scrollkeeper-update.  =
It
> seems like keeping the -o flag is a little more elegant.
> =

> So, I think we should keep all three of these.
> =

> Dan

Ok, sounds good.

Laszlo

Re: [Scrollkeeper-devel] Configurability of OMF_DIR

[Dan M. <d-...@uc...>]

On Thu, 28 Jun 2001, L=E1szl=F3 Kov=E1cs wrote:

> One more thing, with this we would have three ways of specifying OMF
> file locations.
>
> We have:
>
> - and environment variable OMF_DIR
> - the scrollkeeper.conf variable OMF_DIR
> - the -o flag of scrollkeeper-update
>
> This is probably too much. I think the environment variable should go
> away and maybe the -o flag also. If -o stays then the final set of
> directories should be the unification of the -o list and the OMF_DIR
> list from scrollkeeper.conf.
>
> Thoughts?

We certainly need to keep scrollkeeper.conf, so distributions can set up =
a
reasonable system.  The OMF_DIR variable is very nice for people
developers, who set up different paths with development or stable
versions.  It is also the only nice way for users to set up their own
databases in their home directory.  I suppose you could have a
.scrollkeeper file in a user's home directory instead of having OMF_DIR,
but that doesn't really work for systems where you want to switch back an=
d
forth between using two different databases (as done by developers with
stable and unstable prefixes).  So, I think we really should keep the
environment variable too.

I believe we originally introduced the -o flag so that when a person is
building an RPM they create a database in a path under the BUILDROOT.  In
this case, using scrollkeeper.conf would do the wrong thing.  I'm not
sure if we can simply set OMF_DIR before running scrollkeeper-update.  It
seems like keeping the -o flag is a little more elegant.

So, I think we should keep all three of these.

Dan

[Scrollkeeper-devel] Re: relocatable package support

[Dan M. <d-...@uc...>]

A little bit of browsing around linux.redhat.rpm turned up
RPM_INSTALL_PREFIX as the variable which stores the prefix which will be
used.  I'm not sure if PREFIX is overwritten, but even if it is it should
be easy enough to store it as another variable name.  So, let's assume we
always have access to the default and relocated prefix.  (Here I'm
assuming other packaging systems are at least as good as RPM ;)

I think two main systems have been proposed:

1) Do not include the prefix in the OMF file until post-install time.  We
won't need the pre-install step. At post-install time, the
scrollkeeper-update-url script is run which modifies the OMF files and
inserts the prefix into the URLs.  In this case, relocatable and
non-relocatable packages are handled identically.

2) Include the prefix in the OMF file with scrollkeeper-preinstall, as we
do now.  For relocatable packages only, one adds an additional
post-install call to a script, scrollkeeper-update-url, which replaces the
unrelocated prefix with the relocated one.  In this case, unrelocated and
relocated packages are still handled pretty much the same except that one
(simple) extra line is added to the spec file.

I don't see any technical problems with either of these approaches.  (Does
anybody?)

So, I'm inclined to use whichever one is simplest for package authors to
understand and implement.  I think #1 is probably simpler even though it
introduces a second post-install script, since it gets rid of
scrollkeeper-preinstall and uses the same method for both relocatable and
non-relocatable packages.

We could allow people to choose either of the two, but I think that just
complicates things.

Dan

[Scrollkeeper-devel] Re: Configurability of OMF_DIR

[Karl E. <ke...@gm...>]

L=E1szl=F3 Kov=E1cs <las...@su...> writes:

> > It rather /opt/gnome/share/omf than /opt/omf ;)  Maybe,
> > /opt/kde/share/omf can't hurt (prepared for the future).

> Maybe it should be configurable somehow? So that packagers during build
> can specify what they want there?

Sounds good.  Something like a configure option:

    --with-omf-dirs=3D/usr/share/omf:/opt/gnome/share/omf

or

    --with-additional-omf-dirs=3D/opt/gnome/share/omf

Nevertheless it's needed to provide reasonable defaults.

--=20
work : ke...@su...                          |                   ,__o
     : http://www.suse.de/~ke/             |                 _-\_<,
home : ke...@gm...                     |                (*)/'(*)

Re: [Scrollkeeper-devel] Configurability of OMF_DIR

[<las...@Su...>]

Dan Mueth wrote:
> 
> One other thing which we should deal with pretty soon is configuration of
> the OMF directories.  We started with the path determined at build time as
> $prefix/share/omf under which all OMF files must be placed.  Then we added
> the OMF_DIR environment variable to allow one to specify multiple paths in
> order of preference.
> 
> What we really want is a system-wide default which can have multiple paths
> and which can be set to something reasonable by the distribution.  I think
> SuSe Linux had a problem with how they installed and configured GNOME and
> ScrollKeeper which forced one to have to make a symbolic link for your
> docs to work, given that we did not provide another way to do this.
> 
> I propose we add a configuration file in /etc which defines this
> path.  How about /etc/scrollkeeper.conf.  For now, we just have one
> variable to define:
> OMF_DIR=path1:path2:path3
> 
> What is a good default path?  Perhaps:
> OMF_DIR=/usr/share/omf:/usr/local/share/omf:/opt/omf
> 
> Am I missing some paths we should have in there?
> 
> Comments?
> 
> Dan

One more thing, with this we would have three ways of specifying OMF
file locations.

We have:

- and environment variable OMF_DIR
- the scrollkeeper.conf variable OMF_DIR
- the -o flag of scrollkeeper-update

This is probably too much. I think the environment variable should go
away and maybe the -o flag also. If -o stays then the final set of
directories should be the unification of the -o list and the OMF_DIR
list from scrollkeeper.conf.

Thoughts?

Laszlo

Re: [Scrollkeeper-devel] Re: Configurability of OMF_DIR

[<las...@Su...>]

Karl Eichwalder wrote:
> 
> Dan Mueth <d-...@uc...> writes:
> 
> >> I propose we add a configuration file in /etc which defines this
> > path.  How about /etc/scrollkeeper.conf.  For now, we just have one
> > variable to define:
> > OMF_DIR=path1:path2:path3
> 
> Thanks for investigating!
> 
> > What is a good default path?  Perhaps:
> > OMF_DIR=/usr/share/omf:/usr/local/share/omf:/opt/omf
> 
> It rather /opt/gnome/share/omf than /opt/omf ;)  Maybe,
> /opt/kde/share/omf can't hurt (prepared for the future).
> 

Maybe it should be configurable somehow? So that packagers during build
can specify what they want there?

Laszlo

Re: [Scrollkeeper-devel] Configurability of OMF_DIR

[<las...@Su...>]

Dan Mueth wrote:
> 
> One other thing which we should deal with pretty soon is configuration of
> the OMF directories.  We started with the path determined at build time as
> $prefix/share/omf under which all OMF files must be placed.  Then we added
> the OMF_DIR environment variable to allow one to specify multiple paths in
> order of preference.
> 
> What we really want is a system-wide default which can have multiple paths
> and which can be set to something reasonable by the distribution.  I think
> SuSe Linux had a problem with how they installed and configured GNOME and
> ScrollKeeper which forced one to have to make a symbolic link for your
> docs to work, given that we did not provide another way to do this.
> 
> I propose we add a configuration file in /etc which defines this
> path.  How about /etc/scrollkeeper.conf.  For now, we just have one
> variable to define:
> OMF_DIR=path1:path2:path3
> 
> What is a good default path?  Perhaps:
> OMF_DIR=/usr/share/omf:/usr/local/share/omf:/opt/omf
> 
> Am I missing some paths we should have in there?
> 

I think for Solaris something like /opt/gnome-2.0/share/omf will be the
one, but we'll see that later on.

Laszlo

[Scrollkeeper-devel] Re: relocatable package support

[<las...@Su...>]

> > There would be one more needed:
> >
> > 4. Update the url in a set of OMF files in the same subdirectory
> > structure with urls from docs specified by a directory only. Both the
> > base filename (2) and the relative filename (3) should work in this
> > case.
> 
> This would be the preferred way to do things.

> Hmm...  I think it would be helpful to figure out a little more about what
> information we have access to for passing to the post-install script.  We
> can either have the OMF file originally contain the full non-relocated
> path.  Or, it could have the part of the path without $prefix and then
> sk-update-url could just add the prefix.  Or, ...
> 
> I think the best solution would require that the post-install script have
> access to the unrelocated and relocated prefixes.  Then we would do
> everything exactly as we did before and if somebody wants to make it
> relocatable they just add a post-install script which basically just does
> a search and replace on the prefix strings.

We should have access to the target root directory to be used in order
to build the parameters of scrollkeeper-update-url.

On further thinking maybe we are overdoing the relocation support. What
about the following:

- The preinstall script is either used to set an absolute path or a
relative one to $prefix as url
- If an absolute path is set then that is the path, no postinstall
change is done
- If a relative path is used than it should form a correct full path
together with $prefix

This would be the internal algorithm and the only interface provided for
postinstall url update would be:

scrollkeeper-update-url $omf_dir $prefix

This sounds simple so maybe I missed something, but anyway what do you
think? Is there any situation this wouldn't cover?

We could even get rid of preinstall if we follow this as those absolute
and relative paths mentioned above could be hardcoded in the OMF file.
Only that if the developer wants to change the general directory layout
of the project they will have to edit the OMF files while if
scrollkeeper-preinstall is still there they are OK with editing
Makefile.am only.



Laszlo

[Scrollkeeper-devel] Re: Configurability of OMF_DIR

[Karl E. <ke...@gm...>]

Dan Mueth <d-...@uc...> writes:

>> I propose we add a configuration file in /etc which defines this
> path.  How about /etc/scrollkeeper.conf.  For now, we just have one
> variable to define:
> OMF_DIR=path1:path2:path3

Thanks for investigating!

> What is a good default path?  Perhaps:
> OMF_DIR=/usr/share/omf:/usr/local/share/omf:/opt/omf

It rather /opt/gnome/share/omf than /opt/omf ;)  Maybe,
/opt/kde/share/omf can't hurt (prepared for the future).

-- 
work : ke...@su...                          |                   ,__o
     : http://www.suse.de/~ke/             |                 _-\_<,
home : ke...@gm...                     |                (*)/'(*)

[Scrollkeeper-devel] Re: Basics of relocatable packages

[Karl E. <ke...@gm...>]

Dan Mueth <d-...@uc...> writes:

> This is all more of an exercise for me since I use Red Hat and thus
> never use relocatable packages.

I don't use relocatable either and relocatable packages are not a
general feature on SuSE Linux; maybe, some packages under /opt are
relocatable.  GNOME packages are not; they rely on /etc/opt/gnome.

> I would like to get this all right on the first try though ;)

:)

-- 
work : ke...@su...                          |                   ,__o
     : http://www.suse.de/~ke/             |                 _-\_<,
home : ke...@gm...                     |                (*)/'(*)

[Scrollkeeper-devel] Re: relocatable package support

[Dan M. <d-...@uc...>]

On Wed, 27 Jun 2001, Laszlo Kovacs wrote:

> First, I think we should rename the scrollkeeper-update-identifier
> script to scrollkeeper-update-url.

Good point. We are only updating the one attribute of the element.

> There would be one more needed:
> 
> 4. Update the url in a set of OMF files in the same subdirectory
> structure with urls from docs specified by a directory only. Both the
> base filename (2) and the relative filename (3) should work in this
> case.

This would be the preferred way to do things.

> The user should be able to do something like this:
> 
> scrollkeeper-update-url $prefix/share/omf/scrollkeeper
> $prefix/doc/scrollkeeper
> 
> and this should do everything they need.

:) 

> This can become quite complicated to be used together with
> scrollkeeper-preinstall, it will need a good documentation.

Hmm...  I think it would be helpful to figure out a little more about what
information we have access to for passing to the post-install script.  We
can either have the OMF file originally contain the full non-relocated
path.  Or, it could have the part of the path without $prefix and then
sk-update-url could just add the prefix.  Or, ...

I think the best solution would require that the post-install script have
access to the unrelocated and relocated prefixes.  Then we would do
everything exactly as we did before and if somebody wants to make it
relocatable they just add a post-install script which basically just does
a search and replace on the prefix strings.  

So, does anybody know whether we will have access to both of the prefixes
(before and after) in the packaging systems we care about?

Dan

[Scrollkeeper-devel] Configurability of OMF_DIR

[Dan M. <d-...@uc...>]

One other thing which we should deal with pretty soon is configuration of
the OMF directories.  We started with the path determined at build time as
$prefix/share/omf under which all OMF files must be placed.  Then we added
the OMF_DIR environment variable to allow one to specify multiple paths in
order of preference.

What we really want is a system-wide default which can have multiple paths
and which can be set to something reasonable by the distribution.  I think
SuSe Linux had a problem with how they installed and configured GNOME and
ScrollKeeper which forced one to have to make a symbolic link for your
docs to work, given that we did not provide another way to do this.

I propose we add a configuration file in /etc which defines this
path.  How about /etc/scrollkeeper.conf.  For now, we just have one
variable to define:
OMF_DIR=path1:path2:path3

What is a good default path?  Perhaps:
OMF_DIR=/usr/share/omf:/usr/local/share/omf:/opt/omf

Am I missing some paths we should have in there?

Comments?

Dan