ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: shannonskipper@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:96707] [Ruby master Misc#16483] How about stopping new *.tar.bz2 releases?
Date: Wed, 08 Jan 2020 00:38:25 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-83695.20200108003824.7b6d5490340697fd@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-16483.20200106070219@ruby-lang.org

Issue #16483 has been updated by shan (Shannon Skipper).


If bz2 removal goes forward, it might be nice to deprecate now but not remove until later. It'd be ideal to have working versions of RVM, ruby-install and ruby-build in wide distribution before bz2 goes away. If we change the tools now but don't remove bz2 for a few years, I think it'd go smoother without having users tempted to bypass checksums.

For ruby-install, users will have to upgrade the tool itself to move off bz2. It uses a different repo, ruby-versions, for checksums, so it already has xz, etc. But, the choice of bz2 is hardcoded in ruby-install. Currently, bz2 is used for Ruby and Rubinius and tar is used for MRuby, JRuby and TruffleRuby. Only small code changes are necessary, but everyone would have to upgrade the tool rather than just using the --latest flag to fetch the latest Ruby metadata like normal. Since metadata isn't handled in the tool itself, ruby-install isn't updated frequently. Users tend not to upgrade often and it doesn't have a self-update mechanism.

RVM has bz2 md5 and sha512 checksums hardcoded inline, so it's just the RVM repo to update to new checksums. RVM already has tooling to support alternative decompression, but I'm not sure where all else bz2 might be intertwined. It's probably not too bad after changing a bunch of checksums. Users would need to get an updated version of RVM for bz2 support too, but that's also the normal upgrade mechanism for access to new Ruby metadata—so it's normal for RVM users to upgrade fairly often.

----------------------------------------
Misc #16483:  How about stopping new *.tar.bz2 releases?
https://bugs.ruby-lang.org/issues/16483#change-83695

* Author: znz (Kazuhiro NISHIYAMA)
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
Current ruby releases generate `*.tar.gz`, `*.tar.bz2`, `*.tar.xz`, and `*.zip`.
But I think we can stop generating `*.tar.bz2`.

I think `*.tar.bz2` are less merit.
For better size, `*.tar.xz` exist.
For better compatibility, `*.tar.gz` and `*.zip` exist.

I check some programming languages source package archives.

- https://jdk.java.net/13/ tar.gz zip
- https://gcc.gnu.org/mirrors.html tar.gz tar.xz
- https://www.python.org/downloads/source/ tgz tar.xz
- https://nodejs.org/dist/v12.14.0/ tar.gz tar.xz (and 7z zip for win)
- https://www.perl.org/get.html tar.gz
- https://www.php.net/downloads.php tar.bz2 tar.gz tar.xz

`tar.bz2` are rare.

How about stopping `*.tar.bz2` since next release?

(I know [ruby-build](https://github.com/rbenv/ruby-build) use `*.tar.bz2`. And it can use `*.tar.gz`)



-- 
https://bugs.ruby-lang.org/

      parent reply	other threads:[~2020-01-08  0:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-16483.20200106070219@ruby-lang.org>
2020-01-06  7:02 ` [ruby-core:96681] [Ruby master Misc#16483] How about stopping new *.tar.bz2 releases? zn
2020-01-06  7:59 ` [ruby-core:96684] " shevegen
2020-01-06  8:50 ` [ruby-core:96686] " XrXr
2020-01-06 18:15 ` [ruby-core:96692] " eregontp
2020-01-07  4:38 ` [ruby-core:96699] " hsbt
2020-01-07  7:10 ` [ruby-core:96700] " shannonskipper
2020-01-08  0:38 ` shannonskipper [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-list from there: mbox

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

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

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

  git send-email \
    --in-reply-to=redmine.journal-83695.20200108003824.7b6d5490340697fd@ruby-lang.org \
    --to=ruby-core@ruby-lang.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.
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).