Glom: missing dependency - PostgreSQL

Thanks for your bugreport.

gda2-postgres enables glom to talk to postgresql servers. a server on your local box is not necessarily required.

Or did I get your bug report wrong?

I see the problem. Glom connects to postgreSQL databases, but does not necessarily (although this is how I'm using it) require a *local* postgre database. Hence no dependency.

A metapackage "glom-local" with the postgreSQL dependency would get around this.

As things stand, it is confusing for those using glom locally.

As I said in the mail to you already: I don't think that's a good solution. It's like having a <mail-client>-local package which required a fully-fledged mail server. We should better have a 110% rocking documentation on how to get it working. Although I'm willing to hear other views on this.

Having talked to quite some people about it, I made up my mind: I'll not change the dependencies in this case. It just doesn't make sense.

Changing from conglomerate to glom.

Well, I tried.

Reopening, because Glom 1.3/1.4 now really needs PostgreSQL to self-host database. If PostgreSQL is not installed then users will quickly have problems.

I'm not quite sure: isn't there still the "old method" that doesn't require postgres? What I'd really love to do is: not depend on postgres (because it will upset users, who work on another postgres host), but patch glom to install potsgres, if they choose to use the selfhosting feature.

Murray: what do you think?

I'm not quite sure: isn't there still the "old method" that doesn't require postgres?

Yes, but the UI offers the new way and makes the new way the default, so users will experience badness/crashes.

> What I'd really love to do is: not depend on postgres (because it will upset users, who work on
> another postgres host),

Could you give an example of such a situation? If they installed Glom then they probably want what Glom needs.

One problem you probably do have is that the regular debian/Ubuntu postgres installation causes a postgres instance to be run at start up (though the user can stop it in the Services control panel). That makes sense if you install postgres directly, but it's not needed or used by Glom.

> but patch glom to install potsgres, if they choose to use the selfhosting feature.

That's an idea, but I want self-hosting to be the default, not an additional option.

On Mi, 2007-01-17 at 16:48 +0000, Murray Cumming wrote:
> Yes, but the UI offers the new way and makes the new way the default, so
> users will experience badness/crashes.

What if clicking on the "let's do it the new way" button would spawn the
process that installs postgres? (We already patched gnome-system-tools
to do that.)

> Could you give an example of such a situation? If they installed Glom
> then they probably want what Glom needs.

Users A and B work on their company laptops and use the postgres server
on machine C, which is in their office.

I wouldn't want them to install postgres, if they don't need it.

> One problem you probably do have is that the regular debian/Ubuntu
> postgres installation causes a postgres instance to be run at start up
> (though the user can stop it in the Services control panel). That makes
> sense if you install postgres directly, but it's not needed or used by
> Glom.

Phew, I think that's hard to disable. CCing Martin.

> That's an idea, but I want self-hosting to be the default, not an
> additional option.

It wouldn't be "an option", it'd install postgres the first time it's
unavailable and "use selfhosting" is clicked, but work out of the box
after that.

> What if clicking on the "let's do it the new way" button would spawn the process that installs postgres?

I'd live with that if I had to, but it's less than ideal. Software should work without a "make me work" button. Glom really isn't working if it can't self-host. That would be a client-only version of Glom, but I have no plans to make such a version for regular desktops, because there's no need.

There's also the problem that the admin would need to be present later after the admin thinks he has fully installed Glom, because full installation only happens when the user tries to actually use the application.

It's more or less justifiable as an option in gnome-system-tools where the feature is really not needed by default (the network time client) or where it's a choice of equivalent implementations (SMB or NFS networking). In that case it's not a "make me work" button.

> I wouldn't want them to install postgres, if they don't need it.

But why not? I think you are taking the opportunity to pick apart the implementation of an application just because you can, because the application reuses existing software instead of reinventing the wheel.

> One problem you probably do have is that the regular debian/Ubuntu
> postgres installation causes a postgres instance to be run at start up
> (though the user can stop it in the Services control panel). That makes
> sense if you install postgres directly, but it's not needed or used by
> Glom.

I am not going to change this -- people installing PostgreSQL usually do so because they want to use it, and Debian's/Ubuntu's philosophy is that things should 'just work' without fiddling with unnecessary configuration.

As a compromise, I propose this: glom Recommends: postgresql-8.2, so that it is handled as a dependency by all the standard packaging frontends, but if people know what they are doing, they can avoid installing it.

Glom should then check for the availability of pg_createcluster and use it to create a cluster that belongs to the user invoking glom. If pg_createcluster is not available, glom should ask the user to install a postgresql server.

On Thu, 2007-02-15 at 09:33 +0000, Martin Pitt wrote:
> > One problem you probably do have is that the regular debian/Ubuntu
> > postgres installation causes a postgres instance to be run at start up
> > (though the user can stop it in the Services control panel). That makes
> > sense if you install postgres directly, but it's not needed or used by
> > Glom.

Thanks for the response.

> I am not going to change this -- people installing PostgreSQL usually do
> so because they want to use it,

This will not change when people are using Glom.

The assumption you are actually making is "people installing PostgreSQL
usually want to configure it how it is currently configured". But things
change.

> and Debian's/Ubuntu's philosophy is that
> things should 'just work' without fiddling with unnecessary
> configuration.
>
> As a compromise, I propose this: glom Recommends: postgresql-8.2, so
> that it is handled as a dependency by all the standard packaging
> frontends, but if people know what they are doing, they can avoid
> installing it.

By default, synaptic does not install "recommends" packages.

> Glom should then check for the availability of pg_createcluster and use
> it to create a cluster that belongs to the user invoking glom. If
> pg_createcluster is not available, glom should ask the user to install a
> postgresql server.

This is not "just work". This is "Do something extra that I don't
understand, with several ways to get it wrong, so that the application
does something useful and obvious".

This "The application that you have installed is not fully installed"
dialog will be the first experience of 99.9% of all people using Glom.
And I plan for that to be a lot of people.

--
Murray Cumming
<email address hidden>
www.murrayc.com
www.openismus.com

Glom 1.3.9 (just released) contains example code, based on the Debian/Ubuntu patches for gnome-system-tools, to install Postgres at runtime, at startup, and fail if it cannot be installed.

If you choose to use that code, your patch will be small - it will just remove some ifdefs and comment out a define.

I hope this is helpful. I don't like the user experience that it creates but it's better than no Glom.

Since there seems to be a strong argument for depending on PostgreSQL, I am willing to agree to a Dependency (instead of just Recommends:) for a better OOTB experience.

However, as I said, it makes sense for postgresql-X.Y. to create a default instance and I will not change this. So depending on how glom authenticates to that server you either need to modify the credentials of the existing instance or create a personal instance for the user, whichever do you think is more appropriate.

1. I installed Glom to see what its about.
2. I launch it.
3. I get a wizard.
4. I choose 'New from example'. It sounds like a good way to find out what its about.
5. I choose example_smallbusiness.glom
6. It asks for a name, I choose: 'test'
7. I choose 'create database in its own folder, to be hosted on this computer'
8. I click 'save'
9. First User wizard runs: I setup a name and password for the database
10. I click 'create'
11. I get a 'proccessing' window: its never done

Now reading this bug-report I understand whats its about. But the fact that I had to go here to find out is a bug.

This is a blocker. Glom will only be used by people who already know it. Others will just uninstall it, or post bug reports. And instead of just making postgre-sql a dependency, you will spent all day marking bug reports duplicate to this one.

On the other hand:
 - I don't want to install a full fledged database server
 - Well: i dont want it to always run, just when I launch glom
 - Why not just default back to the 'old way' mentioned above?

As of 20/2/2007 this bug is still very valid, and something needs to be done. (or at least get the package out of add/remove)

Another option: create extra meta-packages

 glom-client (only the client)
 glom (installs postgre-sql + glom-client)

Just out of curiosity: Can't glom with with sqllite or something?
Something that doesn't require a database server to launch at startup...

> Since there seems to be a strong argument for depending on PostgreSQL, I am willing to
> agree to a Dependency (instead of just Recommends:) for a better OOTB experience.

Many thanks.
Martin Pitt wrote:
> However, as I said, it makes sense for postgresql-X.Y. to create a default instance and I will
> not change this.

OK. I think this would require a fundamental discussion about how to do this in general for services in Debian. I think the install needs to ask the user sometimes. I can understand that that's a discussion you'd rather not spend time on right now.

> So depending on how glom authenticates to that server you either need to
> modify the credentials of the existing instance or create a personal instance for the user,
> whichever do you think is more appropriate.

Glom will simply ignore the existing instance. It always uses an unused port for its own instance.

Ralf wrote:
[snip]
Now reading this bug-report I understand whats its about. But the fact that I had to go here to find out is a bug.
[snip]

Ralf, Martin had already said how he'd like to fix it, and I already added code to detect incomplete installations, with optional code to complete the install at runtime. Both have disadvantages, neither of which are too awful.

Ralf wrote:
> Just out of curiosity: Can't glom with with sqllite or something?
> Something that doesn't require a database server to launch at startup..

Because
a) That's extra code to write and maintain. I won't do that as long as I don't see a benefit.
b) That's an extra meaningless choice for the user to be confronted with.
c) That would be a loss of functionality compared with postgres. In particular, it would not allow multiple users to simultaneously use the same database.

However, you are free to add this feature, though it's unlikely to be accepted as a user-visible feature in the main Glom code base.

Thanks for the testing and interest, even if I seem unfriendly above.

"Thanks for the testing and interest, even if I seem unfriendly above."

You didn't seem unfriendly. Yet now, i'm guessing you were at least a little bit annoyed with my comments. I din't understand that you were already agree-in on anything, it looked like it was an open discussion. So, I just wrote down my literal experience. I thought it'd be usefull.

This is fixed in the latest Ubuntu upload. Postgres is now a dependency. Thanks.

I was going to add a bugreport just now about being forced to install postgresql-8.2 to use glom when i've seen this. Am I wrong or the glom description sais it's a "database designer and user interface"? There isn't a word talking about a full featured database server.

The description even sais that, to use the self-hosting feature, "please install postgresql-8.2 locally also".

You have two options:
 1.- Modify the description to state that glom installation features the full postgresql server (and I look for a different client to use with my network server because I'm using glom now for a tpv alike environment and don't want a server on each thin client that hardly can run the client).
 2.- Modify the package dependencies to not install postgresql (that seems to be the opposed of what everybody want so I doubt that you are going to do this).

We are going for 1), once Gutsy opens.

Wouldn't everybody be best served by a meta-package?

 glom-desktop depends on glom-client and postgre-sql
 glom-client doesn't depend on postgre-sql

This way the choice is obvious, glom-desktop for those who just want to use it on their machiene and glom-client for those that only want to access an external server.

2007/4/18, Ralf Nieuwenhuijsen <email address hidden>:
>
> Wouldn't everybody be best served by a meta-package?
>
> glom-desktop depends on glom-client and postgre-sql
> glom-client doesn't depend on postgre-sql
>
> This way the choice is obvious, glom-desktop for those who just want to
> use it on their machiene and glom-client for those that only want to
> access an external server.
>

Or better, a "glom" virtual package depending on glom-client and postgresql.
That way the "glom" name is preserved fully functional in the "default"
install while leaving a path to install the client without a server using
the "-client" suffix.

I personally can make my own packages for my development environment (feisty
on amd64 at this moment) with the modified dependencies, but I can't afford
to make packages for all the different system where glom can run and I offer
support (ppc for example). Having a way to user glom as a client coming with
the system will make my life easier. Hadn't it will make me to look for a
different solution, since the important thing (in my case at least) is to
access the database itself from many places, not the interface (even when
glom makes a very good interface and makes it easy for the users).

> forced to install postgresql-8.2 to use glom
[snip]
 > don't want a server on each thin client that hardly can run the client).

The Postgresql binary is an implementation detail that should not be of interest to users. The problem here is not that Postgresql is installed, but that an unnecessary and unused instance of Postgresql is _started_ when it is installed just for Glom.

2007/4/18, Murray Cumming <email address hidden>:
>
>
> The Postgresql binary is an implementation detail that should not be of
> interest to users. The problem here is not that Postgresql is installed,
> but that an unnecessary and unused instance of Postgresql is _started_
> when it is installed just for Glom.
>

Why would I want a program installed that i wouldn't want to run EVER?

May be for you it isn't very important to have a bunch of MB wasted in your
hard disk, but think for a moment in use cases different from yours. What
happens when you have a system fetching a disk image through network to boot
from that? Each extra MB is a waste of bandwidth and each new client adds
more waste.

Even when you have enough HD, it adds time and bandwidth usage in each
update for something you doesn't need at all.

You seem to take the point of view of an end user, but I take the view of an
admin/sysop and it's a problem for me to have postgresql installed in
systems I doesn't want it. But, hey! I'm only one of many! Maybe I'm
mistaken.

You can make what you want (installation of postgresql while installing
glom) in a way that makes it possible for other to install it without the
server (using the virtual packages and dependencies). Why are you so
reticent to allow people the choice? Is there anything I'm not aware of?

> Why would I want a program installed that i wouldn't want to run EVER?

If you install Glom, it's fair to assume that you are likely to need this part of Glom's implementation some time. Asking for Postgres not to be installed for Glom is equivalent to asking for libgnomeprint not to be installed because you never want to print from Gnumeric. Wanting to save a few MB would not be a good enough reason to do that.

You might prefer a client-only version of Glom. I plan to produce one at some time, though embedded use seems the only worthwhile place for it. But at the moment, a Glom without postgres is a broken Glom.

I do not deny that there is a problem with Ubuntu's installation of Glom. I'm trying to tell you that the problem is not in the implementation of Glom itself. The problem is that Ubuntu starts an instance that is not used.

I guess it is a quite typical scenario to install Glom in an office on multiple machines.
However, I would only want to have to install a central PostgreSQL copy (on a local server machine).

I think the postgresql server should be a suggested or recommended package, not a dependency.

As mentioned already, that would break Glom. Some of its (default) options would fail.

2007/4/18, Murray Cumming <email address hidden>:
>
> If you install Glom, it's fair to assume that you are likely to need
> this part of Glom's implementation some time. Asking for Postgres not to
> be installed for Glom is equivalent to asking for libgnomeprint not to
> be installed because you never want to print from Gnumeric. Wanting to
> save a few MB would not be a good enough reason to do that.

May be in your case it's true, but not in mine. Think in the scenery I
talked about before. A TPV alike environment.
The user are that, USERS, and only USE what i give then. The doesn't need to
create databases, they only need to USE what i give them.
That's why I NEED a glom without server.

Even in an office, if I have a sql server, I prefer to create some accounts
for the people who would need that (mainly developers or advanced users)
better than managing complains about local storages that they don't know how
to configure.

You might prefer a client-only version of Glom. I plan to produce one at
> some time, though embedded use seems the only worthwhile place for it.
> But at the moment, a Glom without postgres is a broken Glom.

There is no need for an independent client only. The actual glom can act as
a client. You only neet to not include postgresql by force.
If the packages are made the way I said before (a "glom" package who tell
the sistem to install glom-client (call it glom-gui if you prefer, the name
isn't really important) and postgresql, and a "glom-client that install only
the glom itself) you have the two options at the same time, making happy you
and the office users and, at the same time, we the special cases. That way
the unaware user who install "glom" will get the gui AND the postgresql
server, but the "experienced user" (or we that have special uses) can choose
to install the "glom-client" without the server.

There is no need to be one way or another, we can have both of them without
a single modification in the actual codebase of glom. Only changing the
packaging.

I do not deny that there is a problem with Ubuntu's installation of
> Glom. I'm trying to tell you that the problem is not in the
> implementation of Glom itself. The problem is that Ubuntu starts an
> instance that is not used.

No, the problem isn't in the start of services installed, it's in the way
glom is packaged, that is what I'm saing since mi first post.

Sorry, I think I read some arguments only after committing my post (that is a bad habit).
I certainly agree that providing default options should be on (by default).

We seem to either fundamentally disagree or misunderstand each other.
- Ubuntu cannot install Glom without all of its dependencies, so that it fails on starting. No Ubuntu packaging (without a large source code patch) can change that.
- And as the upstream developer, I don't see a strong reason to cripple the application for some sets of users.

In general, I think you are concentrating on your own suggested solution without just telling us what the problem is. Your problem might be one of these:
- Glom is too big.
  I'd like numbers to support this argument.
- Glom does things that I don't need.
  This is true of all programs, I think, and doesn't seem like a major problem to me.
- Installing Glom on Ubuntu causes an unnecessary Postgres instance to be started.
  This is an actual bug (and should have a bug report)

2007/4/18, Murray Cumming <email address hidden>:
>
> We seem to either fundamentally disagree or misunderstand each other.
> - Ubuntu cannot install Glom without all of its dependencies, so that it
> fails on starting. No Ubuntu packaging (without a large source code patch)
> can change that.

That's cool, but you doesn't need a local postgresql server for glom to
start, only for some functionst to work.

- And as the upstream developer, I don't see a strong reason to cripple the
> application for some sets of users.

And I'm not asking that.

I ask that, the default install is a METAPACKAGE called GLOM, and that
package install a REAL package that contains the glom binary AND postgresql.
That way you have what you want, a full featured glom with local storage
working, but at the same time, I can install de GLOM BINARY ALONE.

May be a schema shows my point better.

GLOM.DEB (empty package that only contains dependencies for GLOM-BIN.DEB AND
POSTGRESQL.DEB)
GLOM-BIN.DEB (real package containing glom)
POSTGRESQL.DEB (real package containing postgre)

When you install glom (aptitude install glom), the dependencies make the
system install the THREE packages

                     / GLOM-BIN.DEB (here is what now is called glom with
all it's dependencies BUT postgresql)
GLOM.DEB |
                     \ POSTGRESQL.DEB (here is the real server)

When I as an experienced user choose to install glom-bin (aptitude install
glom-bin), a package with a different name, the dependencies install all
packages needed BUT postgresql (and then I can't use the local storage, but
I know it and choose that).

To do that you doesn't need to change nothing in glom, nor ubuntu needs to
change nothing in the package system, only the control files for the glom
packaging needs changes (files that the ubuntu package maintainer can modify
easily)

In general, I think you are concentrating on your own suggested solution
> without just telling us what the problem is. Your problem might be one of
> these:
> - Glom is too big.
> I'd like numbers to support this argument.
> - Glom does things that I don't need.
> This is true of all programs, I think, and doesn't seem like a major
> problem to me.
> - Installing Glom on Ubuntu causes an unnecessary Postgres instance to be
> started.
> This is an actual bug (and should have a bug report)

None of that, but another one you can't see. The WAY glom is PACKAGED is
WRONG. The packages can be made in a different way that make you and me
happy at the same time.

Is it that hard to understand? This isn't a glom problem, nor an ubuntu
problem, but a PACKAGING problem.

May be I'm not using the proper words, I'm spanish and am not using my
mother tongue. But I think it's easy to understand.

> That's cool, but you doesn't need a local postgresql server for glom to start, only for some functionst to work.

I am the Glom maintainer. I wrote the code that checks for postgres on startup. Trust me on this.

> But at the same time, I can install de GLOM BINARY ALONE.

Despite repeated explanation you continue to demand a Glom package that cannot work.

Hi,

Murray Cumming [2007-04-18 13:10 -0000]:
> - Installing Glom on Ubuntu causes an unnecessary Postgres instance to be started.
> This is an actual bug (and should have a bug report)

I object. People who install postgresql on their own usually expect to
have it working (after all, that's what packages are for), and a
backend for a per-user desktop application is not the main application
of a database server.

Of course you have some options here:

1) do some glom preinst magic to prevent the default instance from
   being created:

  mkdir -p /etc/postgresql/7.4/main
  touch /etc/postgresql/7.4/main/postgresql.conf

and remove the fake directory in the postinst again. Really hackish,
of course.

2) Remove the cluster in glom's postinst. Dangerous, though, since you
   could kill a production instance.

3) Just use the default instance for glom.

4) Ignore the default instance (it does not take too much space, after
   all) and create your own.

> > - Installing Glom on Ubuntu causes an unnecessary Postgres instance to be started.
> > This is an actual bug (and should have a bug report)
>
> I object. People who install postgresql on their own usually expect to
> have it working (after all, that's what packages are for), and a
> backend for a per-user desktop application is not the main application
> of a database server.

That's fine. I'm not suggesting that the solution is to stop that. I don't know what the exact solution is. I just think that it should be possible somehow. It is a bug.

2007/4/18, Murray Cumming <email address hidden>:
>
> I am the Glom maintainer. I wrote the code that checks for postgres on
> startup. Trust me on this.
>

Well, that's what happens to me for opening my mouth without having tried to
compile the last releases. The last I compiles/packaged was the 1.3.8 that
seems to be the last without the dialog saying glom needs postgresql to
start. Just tried the last and must eat my words.

I'm sorry for the inconveniences and the noise. Time for me to shut my mouth
and look for a different gui that fits my needs.

Sorry.

Glom in Ubuntu Gutsy now depends on postgresql-8.2, so this bug seems fixed to me.