Re: Updated GNOME-2 packages?
Toralf Lund <[email protected]>
| Newsgroups | gmane.comp.gnome.os.redhat |
|---|---|
| Message-ID | <[email protected]> |
> On Thu, 2002-09-05 at 09:09, Toralf Lund wrote: > > > > > > Toralf Lund <[email protected]> writes: > > > > > A new gnomehide may be appearing that's based on rawhide, once we > > > > > release rawhide as a stable version. > > > > Stable rawhide? Is this something new? > > > > > > Eventually rawhide becomes a release, such as 7.3. This is what I > mean > > > by "when we release rawhide" > > Yes, of course. It struck me that that was perhaps what you meant, > after I > > sent my mail... > > > > > > > > > > It's probably possible to get the rawhide SRPMs to build on 7.3 > > > > > without _that_ much effort, but you'd have to know a lot about > gnome > > > > > and RPMs. > > > > The problem with Raw Hide is that there is so much there, and it's > > > > hard to find out what you need to update just one component of the > OS, > > > > like GNOME. Which is why I really liked GNOMEhide. Apart from that, > I > > > > think I'm getting close to knowing everything there is to be known > > > > about RPMs... > > > > > > > > Just a thought: How about setting up a "GNOME(hide) SRPMS" area, > > > > simply containing copies of the GNOME-related RPMs in Raw Hide? I > for > > > > one would find this very helpful; I don't think I would require > much > > > > more help to do the actual build, once I knew exactly what was > > > > involved. > > > > > > Right, I'll look at it. I can append a list of SRPMs for now, it > > > should be mostly accurate. > > Thanks. I had a go at building yesterday, and got a lot up and running, > > > but of course I'd overlooked about 1/3 of the dependencies, so your > list > > is very welcome. - I'm testing this on the new home computer I'm > building, > > which isn't connected to the Net yet. (Nope, I haven't had one of those > > > for years; I've generally got my share of during working hours.) > > > > BTW, something I don't like is the redhat-artwork dependency, which in > > turn means KDE and Qt are needed, but perhaps there is a simple way > around > > this? Building without redhat-menus was easy... > > > > - Toralf > > Yes. > My machine was completly without Qt and KDE, and it was not hard to > disable the kde-deps. but with some recent redhat-menus, i had no luck > (but i didnt try very hard). maybe redhat could split redhat-menus in > several packages (redhat-menus-kde; redhat-menus-gnome, ...). I think their grand, new idea is to have identical menus, with one common source, for both desktop environments. It's quite easy to build without redhat-menus, though, as the gnome-vfs2 SRPM contains the original (plain GNOME, not Red Hat) menu setup (obviously it does, it just contains the standard .tar.gz distribution), and even includes it in the binary rpm. The default build will, however (as far as I can tell), modify the code slightly so that the lib never reads this config, but instead looks an alternate one installed by redhat-menus on a different location. To revert this change, simply rpm -i the SRPM, then update so that the patch mentioning "relocate menus" is NOT applied (and remove redhat-menus dependency while you're at it), then rpm -bb <spec file> > > would be great. > > yours josef > > > >