tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

plans for updating guile



Thomas and I have been discussing how to update guile, moving pkgsrc to
be based on 2.0 and moving to deprecate 1.8 and eventually remove it.
This note summarizes plans -- please let us know of comments or
objections.

* current situation

  - lang/guile is guile 1.8, installed normally
  - lang/guile20 is guile 2.0, installed in a subprefix
  - most packages depend on guile (1.8)

  - guile has a history of breaking compat on every major release (1.6,
    1.8, and 2.0 all caused guile-using packages to break until they
    were upgraded).    
  - guile 2.0 was first released over 5 years ago.
  - some guile packages are not maintained upstream (and don't work with
    2.0)

* approach

The basic approach is to somewhat heavy-handedly flip to 2.0 as normal,
accepting that there may be some breakage, and to move all guile-using
packages to 2.0 as quickly as possible.  Any upstream that does not have
a release that builds with 2.0 will be viewed as non-functional, but
we'll let things be broken for a bit instead of removing if there is any
interest.  This approach is a way to make progress with finite
resources; objections to lack of smoothness should be met with
volunteering to help :-)

* step 1: change to 2.0 as normal

  - change lang/guile to install in a subprefix (/usr/pkg/guile/1.8).
    Do not test all the packages that depend on them to see if they are
    ok.  Instead, assume they are mostly ok and will be migrated to 2.0
    anyway.

  - change lang/guile20 to install in /usr/pkg.  Do not rename it,
    because we are heading for lang/guile22 when that comes out, and
    guile is in the class of packages that are sufficiently incompatible
    that we need to version them.

  After this, everything should work as now, except that guile-using
  packages that don't build with 1.8 and subprefix will be broken.

* step 2: move packges to 2.0

  - for each guile-using package, move it to 2.0 if it mostly works.
    Start with guile-lib, g-wrap, and other libraries, which will cause
    others to break until they are moved.  As before, accept temporary
    brokenness.

  Note that this plan does not involve making 2.0 and 1.8 versions of
  guile-lib and g-wrap, and does not involve making guile like python.

* step 3: propose deletion of broken packages

  After step 2, there will be some packages that don't work with 2.0 but
  depend on packages that were moved to 2.0, but probably not very many.
  For each, either leave a BROKEN notation that it needs help, or
  propose deletion.

* step 4: propose deletion of unmaintained packages that can't use 2.0

  Some packages have non-functional upstreams and haven't had releases
  that work with 2.0.

  Current deletion proposal:

    - guile-gtk (not 2.0 compatible, not maintained upstream, replaced
      by guile-gnome)
    - wip/guile-scsh and wip/guilerxspencer (no functioning upstream)

* step 5: work on moving (working) packages using 1.8 to 2.0

  For each, either make it work or propose deletion.

* step 6: delete guile 1.8 package


Plan for guile 2.2 (decoupled in time from the above)

* step A: add a guile 2.2 package, with a subprefix
 

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index