[patch] GConf Functions

CHANGELOG:
5th July
   - (Curtis Knight) script-utils: installDesktop :: Added 
'update-menus' command to logfile
     so after the removal of a package, the debian menu system (DMS) 
will show the change
   - (Curtis Knight) Created GConf interface functions in script-utils: 
installSchemaFile,
     removeSchemaFile, getConfigValue, setConfigValue, unsetConfigValue
   - (Curtis Knight) apkg-io: Changed outputStatus to allow functions to be
     used like a library when pipe is not in use

=====

The GConf functions could be changed ... like should the setConfigValue, 
unsetConfigValue be setConfigKey, unsetConfigKey instead.

Curtis

Index: CHANGELOG
===================================================================
RCS file: /autopackage/main/CHANGELOG,v
retrieving revision 1.204
diff -u -r1.204 CHANGELOG
--- CHANGELOG	4 Jul 2003 21:30:51 -0000	1.204
+++ CHANGELOG	5 Jul 2003 08:59:16 -0000
 <at>  <at>  -1,3 +1,11  <at>  <at> 
+5th July

Re: [patch] GConf Functions

Hi,

I'd like to get the next release out RSN, so unfortunately this patch
just missed 0.2.6 - however,  once we start working on 0.3 I'll merge it
in.

A few comments from having a read over of it:

Firstly, I don't fully understand what the key level GConf functions are
for. Do applications really need to set them at install time? Maybe they
do. If so then I think they should be renamed to make it more clear that
they are GConf related (so if in future we need to support other
registry-like config systems we can do so), a "gconf" prefix would do
that fine.

On the documentation comments for the functions:

- You don't need <p> tags
- The examples probably shouldn't talk about autopackage. Make up some
random app and use that instead, it's less confusing that way (for me at
any rate)

> +# Function will install to a user, but think twice before doing so.
> +# Installing a schema file for a user might be needed if ONLY installing autopackage
> +# tools for a user. User install of autopackage is not something currently allowed.

I don't understand that comment, sorry :(

The rest of it looks good at first reading.

Re: [patch] GConf Functions

On Saturday 05 July 2003 11:32, Curtis L. Knight wrote:
+# installSchemaFile <FILENAME> <BASEKEY>

It should be renamed to installGconfSchema or something.

> gconftool-2 --install-schema-file="$F"

This I don't understand. $1 is supposed to be the filename. But here you're 
treating all the other arguments as filename, and $1 and key name?

+# removeSchemaFile <FILENAME>
+# FILENAME: Location of GCONF schema file.
+#
+# Loads given schema filename to GConf and initializes for users.

I don't think that a function that's supposed to remove a schema should load 
or initialize stuff.

+# getConfigValue <KEY>

I think developers are better off using gconf-tool directly.
And this function should really be renamed to getGconfValue.

Actually I think only installGconfSchema should be part of the Autopackage 
library. Everything else GConf-related should be handled by the application 
or specfile writer, directly using GConf or gconf-tool. On top of that, there 
are two versions of GConf out there: the one for GNOME 1 and the one for 
GNOME 2. Autopackage shouldn't mess with them.

Re: [patch] GConf Functions

Mike Hearn wrote:

>Hi,
>
>I'd like to get the next release out RSN, so unfortunately this patch
>just missed 0.2.6 - however,  once we start working on 0.3 I'll merge it
>in.
>
>A few comments from having a read over of it:
>
>Firstly, I don't fully understand what the key level GConf functions are
>for. Do applications really need to set them at install time? Maybe they
>do. If so then I think they should be renamed to make it more clear that
>they are GConf related (so if in future we need to support other
>registry-like config systems we can do so), a "gconf" prefix would do
>that fine.
>
>On the documentation comments for the functions:
>
>- You don't need <p> tags
>- The examples probably shouldn't talk about autopackage. Make up some
>random app and use that instead, it's less confusing that way (for me at
>any rate)
>
>
>>+# Function will install to a user, but think twice before doing so.
>>+# Installing a schema file for a user might be needed if ONLY installing autopackage
>>+# tools for a user. User install of autopackage is not something currently allowed.
>>
>

Re: [patch] GConf Functions

Hongli Lai wrote:

>On Saturday 05 July 2003 11:32, Curtis L. Knight wrote:
>+# installSchemaFile <FILENAME> <BASEKEY>
>
>It should be renamed to installGconfSchema or something.
>
>>conftool-2 --install-schema-file="$F"
>>    
>>
>
>This I don't understand. $1 is supposed to be the filename. But here you're 
>treating all the other arguments as filename, and $1 and key name?
>  
>
The example is incorrect. The basekey should be shown as $1 with a list
of schema files following $2 $3 etc. Or maybe that is not intuitive, I
can adjust if needed. The basekey is used to manage possible namespace
collision.

>+# removeSchemaFile <FILENAME>
>+# FILENAME: Location of GCONF schema file.
>+#
>+# Loads given schema filename to GConf and initializes for users.
>
>I don't think that a function that's supposed to remove a schema should load 
>or initialize stuff.
>
I agree. The comments are not correct as initialization happens elsewhere.

Re: [patch] GConf Functions

> I saw that there was a long white section in the TODO file, but I had 
> not seen that a release was iminent. That is cool.

Yup. I *wanted* to do it this weekend, but have found some problems that
need to be addressed first. So maybe sometime next week.

> You had a few comments. You were asking about the key level functions 
> and setting them at install time. I guess I do not see it that way. It 
> is more of a loading of a file but yes it is related directly to GConf. 
> In my mind I was making the functions that determine what was available 
> (GConf, ini) and using that system. I agree if it is related to GConf 
> only then the function name should resemble that.

Hmm, let me see if I understand. This is about autopackage itself using
GConf (or INI files) for configuration? What's wrong with the current
script based config system? Why would we want to use GConf for that
instead?

> So that becomes:
> Look for a configuration key value pair [getConfigValue] ---> 
> [getGConfValue] and/or [getIniValue]
> This is working with a premise that the configuration key values are 
> harmonized and the ability to use either an ini or GConf is availible.

For the application I don't think we can assume that.

> Your other comments lead to a scope discussion. The install and remove 
> schema files function would be used within the install script section of 
> a package. 

Testing needed for 0.2.6

Hi all,

Version 0.2.6 is available for your testing pleasure:

http://autopackage.org/downloads/autopackage-sumo-0.2.6.tar.bz2

It's quite big, as it contains the mplayer package as well as an
autopackage of libprefixdb.

Using it should be very simple, though you still have to manually run
setup to get autopackage on your system. In future, that'll be done
automatically (but it's not a hugely high priority right now so patches
for it are welcome).

Basically, if you get any errors, let us know along with a description
of your setup. If nobody has reported any problems within a few days, I
do the release. Detailed changelog will be available then. Lots changed
in this release, as normal a lot of work went into it. I hope it works
well for people :)

thanks -mike

Re: Testing needed for 0.2.6

Mike Hearn wrote:

>Hi all,
>
>Version 0.2.6 is available for your testing pleasure:
>
>http://autopackage.org/downloads/autopackage-sumo-0.2.6.tar.bz2
>
>It's quite big, as it contains the mplayer package as well as an
>autopackage of libprefixdb.
>
>Using it should be very simple, though you still have to manually run
>setup to get autopackage on your system. In future, that'll be done
>automatically (but it's not a hugely high priority right now so patches
>for it are welcome).
>
>Basically, if you get any errors, let us know along with a description
>of your setup. If nobody has reported any problems within a few days, I
>do the release. Detailed changelog will be available then. Lots changed
>in this release, as normal a lot of work went into it. I hope it works
>well for people :)
>
>thanks -mike
>
Hello Mike,

Thanks for the notice of the sumo. I did not receive any errors 
installing any package except for mplayer. I have attached the trace and 
I am including some various system data.

Re: Testing needed for 0.2.6

> Hello Mike,
> 
> Thanks for the notice of the sumo. I did not receive any errors 
> installing any package except for mplayer. I have attached the trace and 
> I am including some various system data.

Heya,

Basically the problem here is not with autopackage or bash - mplayer was
compiled against libpng.so.2, and you have libpng.so.3

We should really make this case clearer (when you have a package
installed but it's the wrong interface number). That'll have to wait for
another release though.

This is one of the problems with packaging stuff like mplayer. People
expect you to package every dependency too :( I expect if you check your
distro CDs/ftp sites you'll find an old libpng package, installing that
should fix it.

Perhaps for mplayer considering the symbol collisions mess that libpng
invariably causes at the moment we should statically link it. Otherwise
if mplayer then links against something else that uses libpng, badness
occurs.

> =====
> [curtis <at> KNIGHT-4 autopackage-sumo-0.2.6]$ /sbin/ldconfig -p | grep 
> 'libpng.so.3$'
>         libpng.so.3 (libc6) => /usr/lib/libpng.so.3
> [curtis <at> KNIGHT-4 autopackage-sumo-0.2.6]$ bash -version

Re: Testing needed for 0.2.6

I did a little bit of testing, and although it looks like everything
installed correctly, I did get the following errors when installing
foobar and mplayer:

# Installing desktop entries...
# Copying files to /usr/share/gnome/apps/
grep: /usr/share/applnk//foobar.desktop: No such file or
directory
/dev/shm/autopackage.35589637/meta/ <at> autopackage.org/tests/foobar:1.2.2/apkg-install-script:
line 52: /usr/share/applnk//foobar.desktop: No such file or directory
# Updating database ...

# Installing desktop entries...
# Copying files to /usr/share/gnome/apps/Multimedia
grep: /usr/share/applnk/Multimedia/mplayer.desktop: No such file or
directory
/dev/shm/autopackage.60313244/meta/ <at> mplayerhq.hu/mplayer:0.90/apkg-install-script: line 59:
/usr/share/applnk/Multimedia/mplayer.desktop: No such file or directory
# Updating database ...

The odd thing is that I didn't get these messages when I installed them
a second time (uninstall, then reinstall).  I don't really have the time
right now to walk through the code, but I'd be happy to send any more
info that might be useful.  In case it helps, I am running a RedHat 9
installation.

Also, I have a question.  If I uninstall a package that is required by
another package (say libprefixdb, which is required by mplayer), should
mplayer uninstall as well (or at least warn me that mplayer requires