celenity/Phoenix
8
198
Fork
You've already forked Phoenix
18

The wrong way to build a Debian package #315

Open
opened 2026年06月12日 06:44:03 +02:00 by Gnu1 · 7 comments
Collaborator
Copy link

Please explain your inquiry.

Unfortunately, the Phoenix file tree changes a lot in each version which making packaging very difficult.

And of course, the OBS repository package is also built from a modified tarball, which is not standard at all, instead of being built directly from the source tarball.

### Please explain your inquiry. Unfortunately, the Phoenix file tree changes a lot in each version which making packaging very difficult. And of course, the OBS repository package is also built from a modified tarball, which is not standard at all, instead of being built directly from the source tarball.

@Gnu1 wrote in #315 (comment):

Unfortunately, the Phoenix file tree changes a lot in each version which making packaging very difficult.

That's understandable, there have been a lot of changes recently, but the good news is things should hopefully mature/stabilize going forward. For reference, I don't think there have been any new major changes to the file tree since 2026年05月21日.1, and I wouldn't expect more major changes of that nature in the future.

Please let me know though if there's anything I can do from my end to help/make packaging easier.

And of course, the OBS repository package is also built from a modified tarball, which is not standard at all, instead of being built directly from the source tarball.

I assume you mean because we're shipping the release archive directly (instead of having the Debian package build the archive from source)?

@Gnu1 wrote in https://codeberg.org/celenity/Phoenix/issues/315#issue-5784170: > Unfortunately, the Phoenix file tree changes a lot in each version which making packaging very difficult. That's understandable, there have been a lot of changes recently, but the good news is things should hopefully mature/stabilize going forward. For reference, I don't *think* there have been any new major changes to the file tree since `2026年05月21日.1`, and I wouldn't expect more major changes of that nature in the future. Please let me know though if there's anything I can do from my end to help/make packaging easier. > And of course, the OBS repository package is also built from a modified tarball, which is not standard at all, instead of being built directly from the source tarball. I assume you mean because we're shipping the `release` archive directly *(instead of having the Debian package build the archive from source)*?
Author
Collaborator
Copy link

Hi

Please let me know though if there's anything I can do from my end to help/make packaging easier.

How can I build and prepare phoenix files to install?

I assume you mean because we're shipping the release archive directly (instead of having the Debian package build the archive from source)?

I mean you are making phoenix from a pre-built tarball. you should make it from the original source!

Hi >Please let me know though if there's anything I can do from my end to help/make packaging easier. How can I build and prepare phoenix files to install? >I assume you mean because we're shipping the release archive directly (instead of having the Debian package build the archive from source)? I mean you are making phoenix from a pre-built tarball. you should make it from the original source!

@celenity
while something like this is doable

git clone --depth=1 git@codeberg.org:celenity/Phoenix.git Phoenix
cd Phoenix
git checkout 2026年06月10日.1
export PHOENIX_LINUX_ONLY=1
bash +x scripts/get_sources.sh && bash +x scripts/build.sh

as far as i undestand the build scripts this still pulls a bunch of binary build dependencies (see get_sources_phoenix.sh), for a "compile" which is essentially only text transformation and copy operations (why would anything beyond coreutils and system python be necessary on linux?), which is not ideal; release archive is still created in outputs/ (no env var to not create it afaict), but all phoenix release files can be found in outputs/linux (outputs/ can be overridden with exporting PHOENIX_OUTPUTS=somewhere/else)

https://codeberg.org/celenity/Phoenix/src/branch/dev/scripts/ seem needlessly complicated, and cater specifically to the bespoke phoenix release process (e.g. pulling s3cmd), not to building from source locally. separating build scripts and ci scripts might be a good idea; something like #308 probably warrants a closer look. not necessarily relying on release archives would help #314 a bit too.

@celenity while something like this is doable ```bash git clone --depth=1 git@codeberg.org:celenity/Phoenix.git Phoenix cd Phoenix git checkout 2026年06月10日.1 export PHOENIX_LINUX_ONLY=1 bash +x scripts/get_sources.sh && bash +x scripts/build.sh ``` _as far as i undestand the build scripts_ this still pulls a bunch of binary build dependencies (see `get_sources_phoenix.sh`), for a "compile" which is essentially only text transformation and copy operations (why would anything beyond coreutils and system python be necessary on linux?), which is not ideal; release archive is still created in `outputs/` (no env var to _not_ create it afaict), but all phoenix release files can be found in `outputs/linux` (`outputs/` can be overridden with exporting `PHOENIX_OUTPUTS=somewhere/else`) https://codeberg.org/celenity/Phoenix/src/branch/dev/scripts/ seem needlessly complicated, and cater specifically to the bespoke phoenix release process (e.g. pulling `s3cmd`), not to building from source locally. _separating build scripts and ci scripts might be a good idea_; something like https://codeberg.org/celenity/Phoenix/pulls/308 probably warrants a closer look. not necessarily relying on release archives would help https://codeberg.org/celenity/Phoenix/issues/314 a bit too.

@Gnu1 wrote in #315 (comment):

How can I build and prepare phoenix files to install?

For the current process, after getting the dependencies and cloning the Phoenix repo, you'd want to:

  1. Set the environment variable PHOENIX_LINUX_ONLY to 1 (so that only the Linux configs are built)
  • You could set this by running ex. export PHOENIX_LINUX_ONLY=1 before the scripts, or by creating a file named env_override.sh at the root of the repo, and adding that line there.

  1. Run scripts/get_sources.sh.

  2. Run scripts/build.sh.

Done :). The archive containing your outputs will be located in the outputs directory.

I mean you are making phoenix from a pre-built tarball. you should make it from the original source!

Is that really the norm for Debian packages though? ex. if I install Firefox from a package manager, I don't think it would build the browser from source on my system?

In general, I'm not entirely sure what value this would provide, especially given the fact that at its core, Phoenix's files are just basic text/configuration files. Seems like it'd also add extra/unnecessary dependencies on ex. Python for the package. So IDK, maybe there's something I'm missing though.

@degausser wrote in #315 (comment):

(why would anything beyond coreutils and system python be necessary on linux?)

There really isn't.

I'll also note that it's possible use your own Python/system Python if preferred, instead of downloading it from get_sources.sh, by setting PHOENIX_PYTHON to point to your desired location of Python, and by creating your own virtual environment + setting PHOENIX_PYENV_DIR to the path of that environment (I would definitely like to document this though, as well as the other variables).

release archive is still created in outputs/ (no env var to not create it afaict)

I can definitely add an env var for that if you think it'd be useful.

(e.g. pulling s3cmd)

get_sources should only get Python and UV by default - I excluded s3cmd from the default option due to this exactly. The only time s3cmd should be downloaded is if you run get_sources.sh s3cmd - if it's being downloaded otherwise, that's definitely a bug, so please LMK if it is.

separating build scripts and ci scripts might be a good idea

That's fair, I could probably look into that. The only CI-specific scripts currently are prep.sh and push.sh (+ push_phoenix.sh).

@Gnu1 wrote in https://codeberg.org/celenity/Phoenix/issues/315#issuecomment-17984264: > How can I build and prepare phoenix files to install? For the current process, [after getting the dependencies and cloning the Phoenix repo](https://codeberg.org/celenity/Phoenix/src/branch/dev/docs/build.md), you'd want to: 1. Set the environment variable `PHOENIX_LINUX_ONLY` to `1` *(so that only the Linux configs are built)* - You could set this by running ex. `export PHOENIX_LINUX_ONLY=1` before the scripts, or by creating a file named `env_override.sh` at the root of the repo, and adding that line there. 2. Run `scripts/get_sources.sh`. 3. Run `scripts/build.sh`. Done :). The archive containing your outputs will be located in the `outputs` directory. > I mean you are making phoenix from a pre-built tarball. you should make it from the original source! Is that really the norm for Debian packages though? ex. if I install Firefox from a package manager, I don't think it would build the browser from source on my system? In general, I'm not entirely sure what value this would provide, especially given the fact that at its core, Phoenix's files are just basic text/configuration files. Seems like it'd also add extra/unnecessary dependencies on ex. Python for the package. So IDK, maybe there's something I'm missing though. ___ > @degausser wrote in https://codeberg.org/celenity/Phoenix/issues/315#issuecomment-17995202: > (why would anything beyond coreutils and system python be necessary on linux?) There really isn't. I'll also note that it's possible use your own Python/system Python if preferred, instead of downloading it from `get_sources.sh`, by setting `PHOENIX_PYTHON` to point to your desired location of Python, and by creating your own virtual environment + setting `PHOENIX_PYENV_DIR` to the path of that environment *(I would definitely like to document this though, as well as the other variables)*. > release archive is still created in `outputs/` (no env var to _not_ create it afaict) I can definitely add an env var for that if you think it'd be useful. > (e.g. pulling `s3cmd`) `get_sources` should [only get Python and UV by default](https://codeberg.org/celenity/Phoenix/src/commit/0c57ca2f686132b7bfaed4574baccf10700e6ee7/scripts/get_sources-phoenix.sh#L34) - I excluded `s3cmd` from the default option due to this exactly. The only time `s3cmd` should be downloaded is if you run `get_sources.sh s3cmd` - if it's being downloaded otherwise, that's definitely a bug, so please LMK if it is. > _separating build scripts and ci scripts might be a good idea_ That's fair, I could probably look into that. The only CI-specific scripts currently are `prep.sh` and `push.sh` *(+ `push_phoenix.sh`)*.
Author
Collaborator
Copy link

Is that really the norm for Debian packages though? ex. if I install Firefox from a package manager, I don't think it would build the browser from source on my system?

I mean in the build step, the users download a pre-built package.
In Debian, each project has a source package (.orig.tar, debian.tar, .dsc) and one or more binary packages (.deb)
the source package should(in official repo must) be the original upstream source.
You just can change the upstream source via patches or just can remove files.

In general, I'm not entirely sure what value this would provide, especially given the fact that at its core, Phoenix's files are just basic text/configuration files. Seems like it'd also add extra/unnecessary dependencies on ex. Python for the package. So IDK, maybe there's something I'm missing though.

Debian must ensure that every package can be built in a standard and minimal Debian distribution. Packages that are found in every Debian do not need to be added as dependencies.

>Is that really the norm for Debian packages though? ex. if I install Firefox from a package manager, I don't think it would build the browser from source on my system? I mean in the build step, the users download a pre-built package. In Debian, each project has a source package (.orig.tar, debian.tar, .dsc) and one or more binary packages (.deb) the source package should(in official repo must) be the original upstream source. You just can change the upstream source via patches or just can remove files. >In general, I'm not entirely sure what value this would provide, especially given the fact that at its core, Phoenix's files are just basic text/configuration files. Seems like it'd also add extra/unnecessary dependencies on ex. Python for the package. So IDK, maybe there's something I'm missing though. Debian must ensure that every package can be built in a standard and minimal Debian distribution. Packages that are found in every Debian do not need to be added as dependencies.
Contributor
Copy link

@degausser wrote in #315 (comment):

https://codeberg.org/celenity/Phoenix/src/branch/dev/scripts/ seem needlessly complicated, and cater specifically to the bespoke phoenix release process (e.g. pulling s3cmd), not to building from source locally. separating build scripts and ci scripts might be a good idea; something like #308 probably warrants a closer look. not necessarily relying on release archives would help #314 a bit too.

I'm using Makefile work-around for Gentoo ebuild:

PR: celenity/Phoenix-Gentoo#1
Ebuild:

src_compile() {
cp "${FILESDIR}"/Makefile "${S}"/Makefile || die
export PHOENIX_NIX=1
export PHOENIX_BUILD="${WORKDIR}/build"
export PHOENIX_OUTPUTS="${WORKDIR}/outputs"
export PHOENIX_PYTHON="${EPYTHON}"
emake build
}


Makefile: celenity/Phoenix-Gentoo@886734c6c0/www-misc/firefox-phoenix/files/Makefile

I think Makefile and Python scripts is the way.

@degausser wrote in https://codeberg.org/celenity/Phoenix/issues/315#issuecomment-17995202: > https://codeberg.org/celenity/Phoenix/src/branch/dev/scripts/ seem needlessly complicated, and cater specifically to the bespoke phoenix release process (e.g. pulling `s3cmd`), not to building from source locally. _separating build scripts and ci scripts might be a good idea_; something like #308 probably warrants a closer look. not necessarily relying on release archives would help #314 a bit too. I'm using Makefile work-around for Gentoo ebuild: PR: https://codeberg.org/celenity/Phoenix-Gentoo/pulls/1 Ebuild: https://codeberg.org/celenity/Phoenix-Gentoo/src/commit/886734c6c0dc0a2818f7ea0cdc509c59a2e1632e171e0756cf4ae6df6b4bb33b/www-misc/firefox-phoenix/firefox-phoenix-2026年06月10日.1.ebuild#L44-L53 Makefile: https://codeberg.org/celenity/Phoenix-Gentoo/src/commit/886734c6c0dc0a2818f7ea0cdc509c59a2e1632e171e0756cf4ae6df6b4bb33b/www-misc/firefox-phoenix/files/Makefile I think Makefile and Python scripts is the way.
Author
Collaborator
Copy link

while running bash get_sources.sh (with export PHOENIX_LINUX_ONLY=1), the scripts starts downloading something(s).

Why does it do that?

< x-timer: S1783623571.537298,VS0,VE101
< content-disposition: attachment; filename=cpython-3.14.6+20260623-x86_64-unknown-linux-gnu-install_only_stripped.tar.gz
< content-type: application/octet-stream
< content-length: 36049152
< 
{ [5 bytes data]
 75 -- 26.0M 0 1 1 00:00:14 00:00:14 00:00:03 2503k ^C
while running `bash get_sources.sh` (with `export PHOENIX_LINUX_ONLY=1`), the scripts starts downloading something(s). Why does it do that? ``` < x-timer: S1783623571.537298,VS0,VE101 < content-disposition: attachment; filename=cpython-3.14.6+20260623-x86_64-unknown-linux-gnu-install_only_stripped.tar.gz < content-type: application/octet-stream < content-length: 36049152 < { [5 bytes data] 75 -- 26.0M 0 1 1 00:00:14 00:00:14 00:00:03 2503k ^C ```
Sign in to join this conversation.
No Branch/Tag specified
dev
pages
2026年07月08日.1
2026年06月10日.1
2026年05月21日.2
2026年05月21日.1
2026年04月27日.1
2026年03月31日.1
2026年03月30日.1
2026年02月23日.1
2026年02月16日.1
2026年01月21日.1
2025年12月23日.1
2025年11月27日.1
2025年11月07日.1
2025年10月26日.1
2025年10月12日.1
2025年10月03日.1
2025年09月07日.1
2025年08月06日.1
2025年07月30日.1
2025年07月11日.1
2025年06月24日.1
2025年06月12日.1
2025年06月10日.1
2025年06月06日.1
2025年06月02日.2
2025年06月02日.1
2025年05月11日.1
2025年04月27日.1
2025年04月15日.1
2025年04月11日.1
2025年04月02日.1
2025年03月25日.1
2025年03月20日.1
2025年03月12日.1
2025年03月05日.1
2025年02月28日.1
2025年02月21日.1
2024年02月18日.1
2025年02月14日.1
2025年02月13日.1
2025年02月01日.1
2025年01月30日.1
2025年01月27日.1
2025年01月24日.1
2025年01月22日.2
2025年01月22日.1
2025年01月20日.2
2025年01月20日.1
2025年01月19日.1
2025年01月14日.1
2025年01月13日.1
2025年01月12日.2
2025年01月12日.1
2025年01月06日.1
05January2025v1
20240103.2
20250103.1
20241229-1
20241225-1
20241216-1
20241211-1
20241204-1
20241203-1
31November2024v1
20241103-1
20240924-1
20240914-1
20240907-1
20240902-1
20240831-1
20240825-1
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
celenity/Phoenix#315
Reference in a new issue
celenity/Phoenix
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?