Re: [Scrollkeeper-devel] What about the distributions?

[Eric B. <eb...@cy...>]

Ali Abdin wrote:
> 
> On Wed, 18 Oct 2000, Eric Bischoff wrote:
> 
> 
> Unfortunately - when people './configure;make;make install' they will
> miss out on this aspect.

You're right. This means the line in "install:" section should be enough
for updating the database on user's hard disk.

But you must also provide a mechanism to reflect those changes in the
database on packager's hard disk to the end-user's hard disk at
installation time.

Otherwise here is what will happen:

The packager installs the software on his hard disk. His database will
be created (since usually people package in /tmp, the database will be
created from scratch and only hold the entries for the software that is
being packaged).

So at the end the packager sees a new file, let's say
/tmp/usr/share/scrollkeeper/omf.xml. He has three choices:
- ignore the file, it means that he doesn't care about scrollkeeper or
doesn't want to or doesn't understand it or is too lazy to ask himself
the question... :-(
- put it into the %Files section of the specfile (or in the tgz on a
slackware). As soon as two packages use scrollkeeper there will be a
conflict UNLESS YOU GIVE EACH XML FILE A DIFFERENT, PACKAGE-RELATED NAME
- use a post-installation script that will merge this file with the
user's database on his hard disk.

So there are two opportunities for us:
1) Choose a naming convention that will ensure that each package has its
XML data stored in a separate file with a name of its own
2) Provide a kind of "scrollkeeper-merge" utility that will merge the
file on the packager's hard disk 

The first solution may hinder performance at database's browsing time.
The second solution means more work for the distributions :-( and may
hinder the distributions installlation time (post-installation scripts
are usually slow).

If those issues were discussed already, I apologize in advance, I had to
read quickly many old emails to get in pace with this list. Otherwise, I
think this issue is wort considering it.

> What you might need to do is to create some sort of
> system/cron-job/daemon in which scrollkeeper checks the local files
> installed - if it is missing it will remove them from its internal
> database.
>
> Otherwise you will need a big huge README in each project saying "please
> run scrollkeeper-install after 'make install' is done"

No, you're right, none of these are acceptable. We must update the
database in the Makefile AND provide a mechanism to packagers, should it
be have a clear naming convention for the slices of the database or a
post-installation script.

-- 
 Éric Bischoff   -   mailto:eb...@cy...
 __________________________________________________
                                           \^o~_.
     .~.                           ______  /( __ )
     /V\         Toys story         \__  \/  (  V
   //   \\                            \__| (__=v
  /(     )\                        |\___/     )
    ^^-^^                           \_____(  )
     Tux                        Konqui     \__=v
 __________________________________________________