safely override packager-uxp.mk

Users and developers helping users with generic and technical Pale Moon issues on all operating systems.

Moderator: trava90

Forum rules
This board is for technical/general usage questions and troubleshooting for the Pale Moon browser only.
Technical issues and questions not related to the Pale Moon browser should be posted in other boards!
Please keep off-topic and general discussion out of this board, thank you!
tom__

safely override packager-uxp.mk

Unread post by tom__ » 2019-12-17, 06:37

What is the best way to override (srcdir)/toolkit/mozapps/installer/packager-uxp.mk without having to worry about conflicts? Could I perhaps put an alternative packager in (srcdir)/application/(appdir)/mozapps/installer/packager.mk ? I'd like to be able to revision control my packager without stepping over the UXP RCS.
Last edited by tom__ on 2019-12-17, 07:00, edited 1 time in total.

New Tobin Paradigm

Re: safely override packager-uxp.mk

Unread post by New Tobin Paradigm » 2019-12-17, 06:52

That would be disastrous for packaging because you obviously don't know how the system works. Also you don't seem to understand the tree structure either. The moral of this story is, of course.. Don't mess with the build systems. They will murder your soul.

What for and why are you wanting to mess with packaging?

tom__

Re: safely override packager-uxp.mk

Unread post by tom__ » 2019-12-17, 07:06

New Tobin Paradigm wrote:
2019-12-17, 06:52
you obviously don't know how the system works. Also you don't seem to understand the tree structure either.
That's why I'm asking.
New Tobin Paradigm wrote:
2019-12-17, 06:52
What for and why are you wanting to mess with packaging?
I am not ready to move to XZ yet over Bzip2. XZ is not as widely supported in the system's I'm using and I'm not aware of a good parallel drop-in-compatible implementation yet. Bzip2 on the other hand is widely supported and 100% userspace compatible parallel implementations exist. The slightly higher compression ratios of XZ compared to the widespread support and speed of parallel bzip2 don't balance out for me yet on the Linux platform.
Last edited by tom__ on 2019-12-17, 07:15, edited 1 time in total.

New Tobin Paradigm

Re: safely override packager-uxp.mk

Unread post by New Tobin Paradigm » 2019-12-17, 07:14

Well that is utterly baseless bullshit conjecture.. But nevermind that for the moment. Just use ./mach mozpackage and it will run the original routine like nothing ever changed.

tom__

Re: safely override packager-uxp.mk

Unread post by tom__ » 2019-12-17, 07:17

New Tobin Paradigm wrote:
2019-12-17, 07:14
Just use ./mach mozpackage and it will run the original routine like nothing ever changed.
Sure, I saw that in the code but as I understand it that's going to get deprecated sooner or later. Plus the new uxp packager is much cleaner and I'd like to make sure everything works fine on that going forward.

New Tobin Paradigm

Re: safely override packager-uxp.mk

Unread post by New Tobin Paradigm » 2019-12-17, 07:19

Based on what are you making that assumption?

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 1498
Joined: 2018-10-28, 19:56
Location: Georgia

Re: safely override packager-uxp.mk

Unread post by athenian200 » 2019-12-17, 08:30

The thing is, the decision was already made to move to XZ packaging on Linux. The community was consulted and approved the change.

If at some point in the future the mozpackage feature is deprecated (I haven't heard of any plans to do so) and you are still not prepared, you would simply need to do one of the following things:

1. [Recommended] Migrate to a different distro or newer version that supports XZ.

2. [Alternative] Compile a copy of XZ on the distribution that lacks it, backporting it if needed.

3. [Last resort] Create the package on a machine that does have xz available, unxz the resulting package, and then bzip the tar file. This could be done with a simple shell script if you want to automate it, no need to touch the build system.

There are plenty of workarounds you could do on your own for this particular situation. I'm not really sure why the change alarms you given that tarballs have been moving to XZ as the new packaging standard for a while now, and that there is precedent for this in the move from gzip to bzip2. The people on the systems you're talking about really should have been better prepared.
"The Athenians, however, represent the unity of these opposites; in them, mind or spirit has emerged from the Theban subjectivity without losing itself in the Spartan objectivity of ethical life. With the Athenians, the rights of the State and of the individual found as perfect a union as was possible at all at the level of the Greek spirit." -- Hegel's philosophy of Mind

tom__

Re: safely override packager-uxp.mk

Unread post by tom__ » 2019-12-17, 08:42

Please just tell me the proper place to put application specific package script or point me towards some developer documentation. I'm really not up to explain all the fine details and in/outs of my infrastructure right now. I understand it's a unpopular compression scheme in the PaleMoon community. Thants why I'm asking how to provide my own application-specific packager override instead of submitting this upsteam, although if you would be interested in a patch that checks the build paramaters for a preferred packer format on *nix that's something I can provide.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35474
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: safely override packager-uxp.mk

Unread post by Moonchild » 2019-12-17, 09:31

tom__ wrote:
2019-12-17, 08:42
Please just tell me the proper place to put application specific package script or point me towards some developer documentation
It has been given in this very thread.
New Tobin Paradigm wrote:
2019-12-17, 07:14
Just use ./mach mozpackage and it will run the original routine like nothing ever changed.
Just because we default to .xz in our projects doesn't mean the original packaging routine called with that command will be deprecated. Assuming that is really a sign of PMSD.
UXP is a platform and broad applicability scope is, and will always be, part of its design.
I'm really not up to explain all the fine details and in/outs of my infrastructure right now.
And you don't have to. But also don't expect us to explain all the fine details and ins/out of the complex build system when there is no need at all for hacking it.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

Locked