Tag: package

查詢 Debian 與 Ubuntu 官方的 apt repository 的版本資訊

因為在寫「Python 3 的支援週期」這篇時需要查不同作業系統版本下的 python3-minimal 版本資訊，一開始是到 packages.ubuntu.com 上查，但上面只列出了目前還有支援的作業系統的套件。

所以就到 Ask Ubuntu 上面問：「How to search package information on unsupported Ubuntu distribution」。

看起來有兩個方法可以拉到歷史資料，一個是 devscripts 裡面的 rmadison，直接帶入要查的套件名稱就可以了：

$ rmadison python3-minimal

另外一個是到 https://ubuntu-archive-team.ubuntu.com/madison.cgi 這邊查，這個位置也是 rmadison 預設的 backend，資料應該是一樣的。

而加上 -u debian 可以改查 Debian 這邊的資訊，用 -h 可以看到還有那些 alias 可以用。

目前 Ubuntu 這邊可以查到最舊的版本是 trusty (14.04)，如果要更舊的版本資訊，需要去 launchpad.net 上面翻，像是 https://launchpad.net/ubuntu/precise/+package/python3-minimal 這個。

Tailscale 放鬆免費版的使用限制，以及商業版的計算方式

昨天在 Hacker News 上注意到的：「Changes to Tailscale Pricing and Plans (tailscale.com)」，Tailscale 宣佈了新的免費與收費方式 (直接叫做 Pricing v3)：「Pricing v3, plans, packages, and debugging」。

這次有許多改變，首先是免費版本來只能一個使用者使用，現在變成三個使用者可以在同一個 tailnet 裡面，這對於超級早期的 startup 方便不少，另外家庭用戶也可以受益。

另外一個是擴大「免費」的定義，本來的「免費」只有在完全免費的方案裡面用，一個人是免費，但五個人會收五個人的費用；現在變成「既然在 Pricing v3 我說三個人以下免費，那五個人的方案裡面還是有三個免費的名額，我就只收額外的兩個人的費用」，而且只有 active user 才會收：

That is, if you have a 5-person team at work, the first three are still free. You’d pay for only the 2 additional users (and only if they’re active, more on that below).

然後是拔掉限制 (包括「No more limits on subnet routers」與「No more limits on admin accounts」)，以及放鬆限制 (包括「More free nodes, and twice as many nodes per user」)。

所以看起來 Tailscale 現在的策略是成長，趁這波調價時做了一波 PR...

由 pnpm 做出來的效能比較：npm、yarn 以及 pnpm

找資料的時候看到 pnpm 有在做幾個常見的 javascript package manager 的比較：「Benchmarks of JavaScript Package Managers」。

裡面測了九個項目，其中前八個剛好就是 cache 的有無、lockfile 的有無以及 node_modules 的有無，這三者的組合剛好八個，最後一個是測 update 的速度。

pnpm 因為用了 hard link，我先跳過去，只先關注 npm 與 yarn 的差異。

其中幾個比較重要的項目是 (由最重要開始列)：

  • with cache, with lockfile, with node_modules：這個會是一般開發的情境。
  • update：套件有更新時的時間。
  • with lockfile：這個會是第一次 clone 下來後的環境，以及 CI 的環境。

在一般開發環境下，npm 比 yarn 快一些，這點讓我比較意外，我知道 npm 這幾年一直有在改善效率，但沒想到會在 benchmark 下反超，這個是以前 yarn 很大的宣傳點，現在已經不見了。

第二個是 update (upgrade) 的部份，這邊 yarn 比 npm 快一些。

第三個因為是 CI 環境，或是第一次 clone 時的環境，慢通常可以被接受，不要差太多就好，而這邊 npm 比 yarn 快一些。

但不管是哪個，差距都不像以前那麼大了，就效率上來說，官方的 npm 已經沒有太明顯的缺點，因為效率的差異而去選擇 yarn 的理由已經不存在了。

用 fpm 這個工具包 .deb 安裝

先前在「Using Cloudflare R2 as an apt/yum repository」這邊看到的工具，其中一個是 fpm，可以快速包裝成各種套件格式 (符不符合 community standard 就是另外一回事晴了)。

在「deb - Debian package format」這邊就有提到像是之前 HashiCorp 都只有丟 binary 出來時，要怎麼打包。

先抓 binary zip 檔下來，然後直接用 fpm 指定版號與要丟的 prefix，他就幫你包起來：

$ wget https://releases.hashicorp.com/terraform/1.0.10/terraform_1.0.10_linux_amd64.zip
$ fpm -s zip -t deb --prefix /usr/bin -n terraform -v 1.0.10 terraform_1.0.10_linux_amd64.zip

生出來的 terraform_1.0.10_amd64.deb 就可以直接 apt install 或是 dpkg -i 裝進去。

看起來可以是個快速先解決問題的工具，之後遇到沒有提供 apt repository 的套件可以用這個方式先打包起來裝，後續移除也比較簡單，不用靠文件來記錄一堆細節...

Gitea 1.17.0 支援 Package Registry

看到「Gitea 1.17.0 is released」這個，Gitea 1.17.0 開始提供 Package Registry 的功能，支援的包括了：

  • Composer (PHP)
  • Conan (C++)
  • Container
  • Generic
  • Helm
  • Maven (Java)
  • npm (JavaScript)
  • NuGet (.NET)
  • PyPI (Python)
  • RubyGems (Ruby)

基本上常見的都有支援？相比於 GitLab 的 Package Registry 是少了 Debian 這個，其他的看起來都有...

不過少這個好像剛好是我用的到的...

把 Snap 包裝成 Flatpak 格式的工具

前幾天看到「unsnap」這個工具，可以把 Snap 套件轉成 Flatpak 套件，不過裡面有提到目前軟體的成熟度還沒有很高：

Let's say it's "Pre-alpha", as in "It kinda works on my computer".

但看起來會是個可以玩看看的東西，目前 Flatpak 的市場份額的確是愈吃愈多...

HashiCorp 家的軟體看起來都支援 APT repository 了

以前 HashiCorp 家的軟體大多都是自己下載 binary 後放到 /usr/bin 或是 /usr/local/bin 下使用，剛剛翻了一下 Nomad 與 Vault，看起來都支援 APT repository 了：「https://apt.releases.hashicorp.com」；另外也有 RPM repository：「https://rpm.releases.hashicorp.com」。

這樣下個禮拜分享會的投影片也要改一改了...

另外看了一下架構，從錯誤訊息觀察，看起來後面是 Amazon S3，前面是 Fastly 的 CDN。

Arch Linux 決定把套件壓縮演算法從 xz 換成 Zstandard

看到 Arch Linux 的公告，他們決定把套件的壓縮演算法從 xz 換成 Zstandard：「Now using Zstandard instead of xz for package compression」。

從 xz 換成 Zstandard 主要的原因在於不用犧牲太多空間 (多 0.8% 的空間)，但解壓縮的速度可以大幅提昇 (提昇 13 倍)：

zstd and xz trade blows in their compression ratio. Recompressing all packages to zstd with our options yields a total ~0.8% increase in package size on all of our packages combined, but the decompression time for all packages saw a ~1300% speedup.

看起來是不斷發酵... 在幾個月前隔壁棚的 Fedora 先換過去了，計畫在「Changes/Switch RPMs to zstd compression」這邊可以翻到，而 issue tracking system 上的記錄可以參考「Issue #350: F31 System-Wide Change: Switch RPMs to zstd compression - release-notes - Pagure.io」。

看起來會是趨勢了...

pipenv 的凋零與替代方案 poetry

看到「If this project is dead, just tell us」這個，裡面討論到了 pipenv 的前景愈來愈讓人疑惑，要官方給個意見，結果下面就馬上有人建議跳槽到 poetry。

剛好前陣子看到另外一篇文章「My Python Development Environment, 2020 Edition」，裡面也提到了他把 pipenv 換成 poetry，而且提到了 pipenv 的問題：

pipenv → poetry. This move’s more complex. I stoped using Pipenv for a couple of reasons:

  • Governance: the lead of Pipenv was someone with a history of not treating his collaborators well. That gave me some serious concerns about the future of the project, and of my ability to get bugs fixed.
  • Bugs and rapid API changes. About a year ago, Pipenv had lots of bugs, and a rapid pace of change introducing or changing APIs. I ran into minor issues at least once a week. Nothing was seriously bad, but it generally felt fairly unstable. I kept having to update various automated deploy workflows to work around issues or changes to Pipenv.

看起來 tech stack 裡面要把 pipenv 轉移抽離了...

GitHub 推出 Package Registry

GitHub 推出了「GitHub Package Registry」，可以代管自己開發的軟體。

目前支援 npm (Node.js)、Docker、Maven (Java)、NuGet (.NET)、RubyGems (Ruby) 五個平台，

隔壁 GitLab 說我們早就有了而氣噗噗中：「Packaging now standard, dependency proxy next?」。

Anyway，省下一些事情，以前會透過 CI/CD 丟到像是 packagecloud.io 這樣的服務上讓內部使用，現在看起來 GitHub 上面可以解決一些簡單的情境...