Proposal about current status of GNOME
wblaszcz at bigpond.net.au
Wed Jul 29 14:36:47 PDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
Bruce Dubbs wrote:
> Randy McMurchy wrote:
>> Hi all,
>> There is an entity in the book named &gnome-version;. It is the major
>> part of a GNOME release. In the case of the current book it is 2.18.
>> We use this entity quite a bit in the URLs of GNOME packages. Wayne
>> is busy updating all the preliminary packages for GNOME. Most GNOME
>> support packages (libsoup for example) now use the current version
>> of gnome in the URL.
>> However, Wayne can't use the gnome-version entity because it would
>> break the libsoup URL.
> Create a gnome-target entity and use that until all the packages use it and then
> do a sed s/target/version/ when appropriate.
>> It is my opinion that GNOME is totally broken in current SVN. Enough
>> that I feel it should actually be commented out completely, until
>> GNOME is actually updated.
>> There are so many missing packages, and so many obsolete packages,
>> that I don't believe anyone could use the book to build GNOME unless
>> you are *very* experienced, in which case you don't need BLFS.
>> I propose we comment out GNOME from the book until it is ready. That
>> way I can bump the gnome-version entity to 2.26 and we can use the
>> entity in gnome support package URLs.
>> Anyone have a problem with this?
> I'm not sure what you want to comment out. There are many packages that require
> or at least can use Gnome libraries. The desktop may not work, but many of the
> libraries should be OK.
> I'd be more inclined to put in a big note detailing the status and update as we
> go. We could even go the entity route wit a note for each package needing
> update. Just a thought.
> -- Bruce
I was actually think along the same lines as Bruce, to have two entities
(old and new). My suggestion would be the following:
gnome-version = 2.26 and gnome-old-version = 2.18, then sed everything
to gnome-old-version first. The advantage over have two entities rather
than commenting everything out is that you can check in one package at a
time rather than the big bang approach, with the added bonus that others
can review the work as it comes out.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the blfs-dev