forthebadge forthebadge Gem Version

This gem was last updated on the 11.11.2023 (dd.mm.yyyy notation), at 04:41:00 o'clock.

The repackage gem

Dependencies of the repackage gem

In the past the repackage gem specifically depended on four other external projects. In May 2022 this mandatory list of dependencies has been reduced to just one. However had, it is still recommended that two of the other three gems are installed as well.

The official list of dependencies thus recommended for the repackage gem is as follows, in alphabetical order:

  • colours
  • extracter
  • opn

However had, since as of November 2023, the colours gem is now optional. If it is installed on your system then it will be used; otherwise it will be silently ignored. Colours are nice to have, but the repackage gem must also work with colours not being available (e. g. the colours gem was NOT installed).

Clean working directory

As far as the repackage gem is concerned, a working directory is needed to extract an archive. On my home system this is:

/home/Temp/repackage/

For most other users this will be:

/tmp/repackage/

The reason why such a directory is necessary is so that we do not begin to pollute any other directory. Some archive files, in particular some .zip files, tend to be messy and incorrectly archived, extracting right into the current working directory as-is. This is not always what the user wants to see.

This is specified here in the event that you may wonder why there is code that checks for this - we have to determine which working directory is to be used.

The main class

This subsection will mention a few noteworthy tidbits about the main class of the repackage gem.

The name of the class is class Repackage::Repackage. The constant called DEFAULT_TARGET_FORMAT_TYPE will be used to determine initially into which target format the class shall repackage an existing archive. By default this will be set to the String '.tar.xz', thus meaning that an archive, such as .tar.gz, will be repackaged into a .tar.xz archive instead.

The constant WORKING_DIRECTORY is used to specify a distinct working directory. Currently the default will be at /tmp/repackage/, but this may be changed. On my own home system I am using /home/Temp/repackage/ instead, for instance. We thus have to preserve some flexibility here.

Executable at bin/repackage

Since as of May 2022 there is now an executable called repackage. It used to be called repackager, but I reconsidered; it seems simpler to remember that the gem here is called repackage; then people may easily and instantly know that there may be an executable called repackage, residing at bin/repackage, rather than a file residing at bin/repackager.

Contact information and mandatory 2FA coming up in 2022

If your creative mind has ideas and specific suggestions to make this gem more useful in general, feel free to drop me an email at any time, via:

shevy@inbox.lt

Before that email I used an email account at Google gmail, but in 2021 I decided to slowly abandon gmail, for various reasons. In order to limit the explanation here, allow me to just briefly state that I do not feel as if I want to promote any Google service anymore when the user becomes the end product (such as via data collection by upstream services, including other proxy-services). My feeling is that this is a hugely flawed business model to begin with, and I no longer wish to support this in any way, even if only indirectly so, such as by using services of companies that try to promote this flawed model.

In regards to responding to emails: please keep in mind that responding may take some time, depending on the amount of work I may have at that moment. So it is not that emails are ignored; it is more that I have not (yet) found the time to read and reply. This means there may be a delay of days, weeks and in some instances also months. There is, unfortunately, not much I can do when I need to prioritise my time investment, but I try to consider all feedback as an opportunity to improve my projects nonetheless.

In 2022 rubygems.org decided to make 2FA mandatory for every gem owner eventually:

see https://blog.rubygems.org/2022/06/13/making-packages-more-secure.html

Mandatory 2FA will eventually be extended to all rubygems.org developers and maintainers. As I can not use 2FA, for reasons I will skip explaining here, this means that my projects will eventually be removed, as I no longer have any control over my projects hosted on rubygems.org (because I can not use 2FA).

At that point, I no longer have any control what is done to my projects since whoever is controlling the gems ecosystem took away our control here. I am not sure at which point ruby became corporate-controlled - that was not the case several years ago, so something has changed.

Ruby also only allows 2FA users to participate on the issue tracker these days:

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

But this has been reverted some months ago, so it is no longer applicable. Suffice to say that I do not think that we should only be allowed to interact on the world wide web when some 'authority' authenticated us, such as via mandatory 2FA, so I hope this won't come back again.

Fighting spam is a noble goal, but when it also means you lock out real human people then this is definitely NOT a good situation to be had.