unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Mike Gerwitz <mtg@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: On packaging old versions of libraries
Date: Thu, 24 Aug 2017 23:27:19 -0400	[thread overview]
Message-ID: <87inhcuy20.fsf@netris.org> (raw)
In-Reply-To: <87tw0yl284.fsf@gnu.org> (Mike Gerwitz's message of "Wed, 23 Aug 2017 11:42:51 -0400")

Hi Mike,

Mike Gerwitz <mtg@gnu.org> writes:

> There is a game my kids love playing named Secret Mayro
> Chronicles.  Unfortunately, it's been unmaintained since 2012, and it
> was removed from Debian because it is no longer compatible with newer
> versions of libraries they package.[0]  There is a maintained fork of
> the game, but it's quite different from the original (intentionally).
>
> I have the option of compiling it using old libraries (I would have to
> compile the old libraries' dependencies as well, as needed), upgrade the
> game by backporting changes from the fork (which I honestly doubt I have
> the time for right now, but I'll look into it), or run the game within a
> VM/container running an old Debian version.
>
> I'm going to look into what is required to backport, but if I decided to
> go the first route, I would probably use Guix.  Would such a
> contribution be accepted considering it packages older libraries, which
> would add some cruft?  At the least, I would have to compile CEGUI 0.7,
> but that might need older versions of libraries itself to compile.

I don't see a problem with adding an older version of CEGUI, but if
other older libraries will be needed as well, I think we'd need to look
at the details before making a decision.  The main issue is that it
potentially adds to our maintenance burden with regard to security
updates.  If these older libraries are still being competently
maintained (e.g. by upstream or by a reputable distro), or if the
libraries in question are not security sensitive, then it's probably
fine.

In many cases, a dependency on an older library can be fixed with a
small patch.  I don't expect that the dependence on CEGUI-0.7 could be
eliminated that way, but if CEGUI-0.7 depends on other older libraries,
perhaps CEGUI-0.7 can be patched to avoid that.

I would encourage you to investigate further and let us know which older
libraries would be needed, and then we can discuss it further.

     Regards,
       Mark

      parent reply	other threads:[~2017-08-25  3:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-23 15:42 On packaging old versions of libraries Mike Gerwitz
2017-08-23 22:20 ` Roel Janssen
2017-08-24  4:35   ` Mike Gerwitz
2017-08-25  3:06 ` Eric Bavier
2017-08-25  7:07   ` Pjotr Prins
2017-08-25  3:27 ` Mark H Weaver [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87inhcuy20.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=guix-devel@gnu.org \
    --cc=mtg@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).