Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]

On Tue, 2005-07-19 at 12:01 -0400, Luis Villa wrote:
> On 7/19/05, Dan Winship <danw novell com> wrote:
> > On Tue, 2005-07-19 at 11:31 -0400, Luis Villa wrote:
> > > On 7/19/05, Alexander Larsson <alexl redhat com> wrote:
> > > > The naming of the packages could also be such that there is no chance of
> > > > conflicting with your vendor gnome, current version or later installed.
> > >
> > > I think Dan was suggesting (and certainly it is easier to produce)
> > > something that isn't a package at all, just a tarball of binaries and
> > > magic files, built into /opt/.
> > 
> > Real packages have a few benefits:
> >       * Can be installed with tools that the user is more likely to be
> >         familiar with (and in particular, can be easily installed with
> >         GUI tools on many distros)
> >       * Easy to remove, easy to upgrade without worrying about there
> >         being cruft left behind
> > 
> > But they don't need to be "good" packages in terms of integrating with
> > the rest of the distro. These are the sort of packages that can be
> > produced in 10 seconds given a tarball and a perl script.
> oh, oh. hadn't thought of that. Hrm, yeah, probably doable.

I have a patch against JHBuild that will create packages of GNOME.  It's
by no means perfect and isn't even complete yet, but it's getting there.
I mentioned it earlier in this thread:

I've only tried creating the packages on FC4, but the patch should work
just as well on other distros and could be easily modified to work on
non-RPM based distros.  The resulting packages all install (there were a
few hickups, but nothing serious).  The Gnome that results from
installing these packages however is not runnable.  This is likely due
to the things that James mentioned in another mail:

I would very much like to get this to the point where it can actually
produce installable packages of all of GNOME (or essentially anything
that is built with JHBuild).  The packages which are currently being
produced install to /opt/gnome2 and have names that won't conflict with
any distribution-supplied names (ie glib2-jhbuild, evolution-jhbuild,
etc.)  Naming them this way means that getting rid of them all should be
as simple as 'rpm -qa | grep jhbuid | xargs rpm -e'.  The version number
is just the date that they were built.  There is also dependency
information that I am generating from the module set.  So, the gtk+-
jhbuild package depends on the glib2-jhbuild package, etc.  Oh, and
there are no *-devel packages or anything, everything that a module
installs gets packaged together.  There would probably need to be one
more package which does the post-install things that James mentions,
installs a .jhbuildrc file somewhere, installs a GDM session file, etc.
I'll try to spend some time this week and see if I can get this thing to
a point where it is useful.


> > > [Note that if done well, I don't actually think distributing packages
> > > that conflict with your vendor GNOME is a problem, given proper
> > > warning labels all over the place.]
> > 
> > That requires more distro-specific smarts though, 
> Oh, of course. That's why this task drove Jacob insane. :)
> Luis
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]