Proposed: libpcre

[Havoc Pennington]

On Sat, 2004-08-07 at 21:49, Brad Hards wrote:
> 
> So I'm not really sure how you intend that platform can provide a better 
> user-level experience

freedesktop.org can't fix all the issues covered by the HIG, agreed, as
my DesktopCon slides discuss a bit.

However, we can fix certain things such as drag and drop not working,
inconsistent MIME associations, etc.

> You need to be careful about providing so little that you aren't doing 
> anything.

Not a risk, in my view. We have a lot of very clear useful candidates
for the 1.0 release.

> > My definition is that it's a "substrate for platforms" or "backend for
> > toolkits" - in other words it should basically contain the *shared*
> > dependencies of Qt, GTK+, XUL, WINE and other common desktop toolkits.
> Then on that basis, libpcre is a reasonable part of the substrate.

How many of those libs use libpcre today? ;-) GTK is thinking about it,
I know.

On my system (with Qt, GTK, and XUL installed) only grep seems to depend
on pcre, though I would not be surprised if XUL has an internal copy.

> > In other words, I'm often not expecting anyone to code to
> > freedesktop.org libraries directly, or exclusively; the fact that we
> > won't include a toolkit is the most obvious example.
> substrate for development or substrate for users? Perl is required to build 
> lots of applications, but isn't used in many.

Including perl in the freedesktop.org platform would be pretty silly, in
my opinion. Some build requirements such as pkg-config that are
relatively freedesktop.org specific and actively part of the freedesktop
developer community, maybe we should include them. Adding automake and
perl and gettext though sounds pretty suspect.

> > But I also don't think we should include things like an ODBC-style
> > database layer, a scripting language, an IDE, or whatever. Let's stick
> > to our core competency.
> SQLlite is emerging as a common dependency...

If so, more evidence that "common dependency" should not be the
definition of the freedesktop.org platform. 

As I understand it our goal is a coordinated release of stuff in active
and de facto use by the toolkits and desktops. One aspect of
coordination is that we can't coordinate a package unless it's actively
part of the discussion and the release process. So a third-party
non-desktop package such as pcre could perhaps be listed as a
dependency, but it should not be part of the freedesktop.org release.

Similarly, GNOME depends on gettext, but gettext is not coordinated as
part of or affected by the GNOME release process.

I'm not sure how GNOME release team treats gettext differently, but
surely it's at least de facto in a somewhat different bucket than
gnome-panel.

Again, *not* trying to provide a complete platform on freedesktop.org.
The goal should be to assemble the many packages that are currently de
facto underlying the major toolkits and desktops and test/release them
as a whole, so those desktops can effectively say "requires
freedesktop.org 1.0" rather than "requires <long list of stuff>"

However note that "test/release" is a verb that requires package
maintainer involvement... it's not something we can apply to third-party
stuff.

I'm sure GNOME/KDE release teams have already basically answered this
question of how to treat dependencies that aren't part of the release
itself, maybe we should stop here and just go find out what they do.

Havoc