LWN: Comments on "Improving .deb"

Improving .deb

excors — Wed, 26 Jun 2019 10:32:43 +0000

> As I understand, uncompressing certain .xz archives (perhaps large archives) *can* require a lot of RAM

I don't believe it depends on the archive size, just on the dictionary size that was chosen when compressing, because the decompressor has to construct that dictionary in RAM. The man page says the default compression mode ("xz -6") uses an 8MB dictionary, and the most expensive preset ("xz -9") uses 64MB, though with custom settings it can support up to 1.5GB. Compression takes roughly 10x more RAM.

(For comparison, zlib(/gzip/etc) uses a 32KB dictionary by default, which is partly why modern algorithms can perform so much better.)

Improving .deb

fest3er — Wed, 26 Jun 2019 02:50:20 +0000

I was just thinking something like this: use a FS that performs compression. Sounds like SquashFS might work nicely, if it achieves an acceptable level of compression. Ideally, there'd be little need to pre-decompress the pkg; just loop-mount it and use rsync to install the files.

As I understand, uncompressing certain .xz archives (perhaps large archives) *can* require a lot of RAM

Haiku have created what sounds like a novel approach to packages. For most user packages, there's no need to unpack and install files. As I understand, the pkg file is simply put where it belongs; once there, its contents become available to the system. To remove the pkg, delete the pkg file. I've no idea how they made it work (perhaps some form of FS union).

Improving .deb

ceplm — Mon, 10 Jun 2019 06:33:01 +0000

> The state management for package install/upgrade/uninstall is more robust and intuitive for deb being one of the really big ones.

You know that's like twenty years out-of-date complaint, right? And the only meaning of the word "intuitive" is "what I am used to and I hate anything changing", right?

Improving .deb

dfsmith — Thu, 06 Jun 2019 21:36:21 +0000

Wouldn't you trust both or neither? If they match, yay! If not, the zip is corrupted (and shouldn't have passed the signature check).

Improving .deb

rahulsundaram — Thu, 06 Jun 2019 20:50:11 +0000

> It's hard nosed packaging policy that makes it work.

I agree with that view. That has nothing to do with the format of the archive. It is much more higher level.

>"CentOS just downloads it's easy - Debian's too big!"

Not sure what that means. Net installation works just fine in either.

Improving .deb

amacater — Thu, 06 Jun 2019 19:42:29 +0000

Yes, sorry, I didn't mention Jurix and so on that became SUSE. Every distribution I've seen adopt RPM - back to and including Linux-FT version 2 - has botched it. Red Hat botched it a couple of times where updates became impossible.

Deb "just works" but only because Debian puts a whole lot of policy in place and developers are constrained to work so that packages co-install, don't overwrite libraries from other packages and so on. It's hard nosed packaging policy that makes it work. [A colleague says "CentOS just downloads it's easy - Debian's too big!" but that's because Debian includes the world and its source ]

Improving .deb

hensema — Thu, 06 Jun 2019 09:38:41 +0000

> The database format of rpms is painful to deal with, and really rather impractical for some of the use cases described in the article, such as extracting the installer contents for manual installation on an unsupported system.

Rpm is using cpio as its archive format. Equally arcane as ar, but it does enable you to extract an rpm on foreign systems.

> Also, most of the linux installation professionals I know hate rpm with a passion and would much rather work with deb packages, for a host of reasons not directly relating to the file format itself.

So what you're saying it's better to invent a new format to avoid hurting feelings of those "professionals"?

Let's face it: Debian can still be Debian even if they switch their underlying package format to RPM. Or any other vaguely modern package format.

Refactoring .deb is a good thing, but it does make sense to shop around for existing solutions that work, are mature and maintained.

Improving .deb

Wol — Thu, 06 Jun 2019 08:55:15 +0000

> You can't do that with rpms - and anyway "whose version of rpm" - I'm old enough to remember when Red Hat broke rpm such that you couldn't install updates, when Mandriva introduced a "newer" version of rpm that was a fork by an erstwhile maintainer, that OpenSUSE rpms don't work well with anyone else's.

> Debian's strict policy on packaging and upgrades is what makes seamless upgrade from say, Debian 7 to Debian 9 remotely possible: if you're _really_ lucky, you might just be able to upgrade CentOS 6.8 to 7 or 7.6 to 8 but the rpm world is a reinstall to fix every problem.

What you miss here, is that (afaik) all distros that use deb are DERIVATIVES of debian, so they inherited debian's packaging rules.

OpenSUSE (at least its parent) PREDATES rpm, heck iirc it even predates Red Hat, so while it adopted the rpm program and file format, it already had its own, completely different, packaging rules.

Things are a lot better on that front now, I believe ...

(SuSE began as a Slackware derivative, then was derived from some other obscure distro, then became its own master.)

Cheers,
Wol

Improving .deb

brunowolff — Thu, 06 Jun 2019 03:55:19 +0000

Could squashfs-tools be used for this? That would provide random access. The dictionary is shared to at least some extent across files, so the size cost might not be that high. On linux you can mount the file system, though older kernels won't work with newer compression methods. But you can also extract the files without having to mount the file system.

Improving .deb

rahulsundaram — Tue, 04 Jun 2019 03:56:50 +0000

> I'm now wondering how much rpm-ostree might side-step this madness, if at all.

I am not sure I follow what you are wondering about here. The internal low level implementation details of RPM format obviously doesn't affect end users. What matters to end users is functionality like library and file based dependencies or boolean dependencies or weak dependencies etc.

ostree based systems don't use RPM at all and therefore dependencies don't really matter all that much on these systems for end users. What you get is a OS that is constructed and pushed to end users a single "immutable" image and everything else is supposed to be running of containers of some sort. rpm-ostree provides some level of compatibility with traditional RPM packages but the more you use them, the more you move away from the advantages that a immutable base image provides. Instead the recommend path is use wrapper like Fedora toolbox and within that you could just install plain rpm packages.

Improving .deb

pabs — Tue, 04 Jun 2019 03:03:28 +0000

The current state is that Debian uses sbuild and tarballs as the base of the build chroot.

why confine the discussion to Linux-based systems?

brouhaha — Mon, 03 Jun 2019 23:26:39 +0000

> What on earth do you think rpms are? Each rpm is a berkeley db hierarchical database.

The system-wide RPM database is a berkeley db.

An individual RPM file is just an RPM header prepended to a cpio archive.

Improving .deb

logang — Mon, 03 Jun 2019 22:22:12 +0000

Second this: I have a couple machines that have seen every release since Lenny (5.0 to 9.0) without any reinstall and many that have been around since Stretch. The fact that Debian makes this painless is a *huge* win seeing reinstalling is a lot more work and would probably require a new machine to be swapped in. Every two years I just upgrade every machine and it typically takes less than an hour per machine. If I had to reinstall, I probably wouldn't upgrade anything which is obviously wrong.

Improving .deb

jezuch — Mon, 03 Jun 2019 10:44:45 +0000

Right, I haven't considered package builders. I haven't actually used pbuilder much - it's too cumbersome and, as you notice, slow. Nowadays I do my builds in a chroot on a writable btrfs snapshot. I used to build on tmpfs but my SSD is fast enough and I needed the RAM for something else (gcc -flto can eat a lot of memory!). I wonder if Debian is considering using something similar on their build farms? (I really have no clue what's the current state there.)

But anyway, xz is relatively fast at decompression as all LZ77 type algorithms are. Is it not fast enough? On the other hand bandwidth is cheap these days so... :)

tar for outer wrapper - wasted space

brouhaha — Fri, 31 May 2019 23:40:46 +0000

Using tar for the outer wrapper is not going to waste much space for block padding, because the outer wrapper only contains three files. Tar defaults to 512B internal blocks and 10KiB I/O blocks. If I understand the modern tar format (ustar) correctly, at most the waste from partial blocks and the ends of the three files will be 1533 bytes (3 partial 512-byte blocks of 1 byte each, leaving 511 bytes wasted in each partial block). There will also be waste to round the entire archive to a 10KiB length, so that will be at most 10239 bytes, for a maximum total padding of 11,772 bytes. Assuming that the average file size mod 512 is uniformly distributed (which admittedly might not be a valid assumption), the average waste for the entire outer tarball wrapper should be around 6.5 KiB. There is also a 512B header for each file, which could perhaps be considered largely wasted space, in which case the average waste for the entire outer tarball wrapper should be around 8 KiB.

This seems like a problem only if the format changes include having a significant number of files nested directly in the outer wrapper, rather than in an inner compressed archive.

Improving .deb

patrakov — Fri, 31 May 2019 14:58:47 +0000

In this particular case, there is a policy how to name packages providing shared libraries, and a lintian check that enforces it. E.g., under this policy, a package that provides libncurses.so.6 must be named libncurses6. So this is a case of convention over configuration, but the end result is the same.

Improving .deb

bojan — Fri, 31 May 2019 08:49:28 +0000

I actually upgrade my Fedora systems every 6 months. The point being, if the distro decides to have a policy of upgrades, then it's possible regardless of the underlying packaging.

Red Hat decided they didn't want to support upgrades from RHEL 5 to 6, but 6 to 7 (for some products) and from 7 to 8 is possible:

https://access.redhat.com/solutions/637583
https://access.redhat.com/documentation/en-us/red_hat_ent...

Improving .deb

nim-nim — Fri, 31 May 2019 08:30:48 +0000

The article ponders multi gig deb limitations and you point to a page that complains a few bytes are wasted in rpm metadata. Really?

You have all the tools to manipulate rpm files under Linux, you can even open them in generic non-Linux archiving tools like 7zip and it will *just* *work* (yes you will lose rpm-specific metadata. Just like you will lose iso-specific metadata when treating isos like a giant archive. If you absolutely refuse to use native rpm tools just uncompress the source rpm, the whole package is described in a human-readable spec file, you don't absolutely need to read the binary transformation of this same info).

The rpm installation/update process has a mind-numbing amount of entry points, with very specific (and weird) ordering, but the average packager does not have to think about them. When you *do* need to think about them, because the software being packaged has special needs, you’re happy to have them available (or, like pretty much everyone, you decide it’s all too complex, and try to do your own better simpler thing, and months later, when you've exhausted all the weird corner cases required by your software, and actually understand the problem space, you switch to native rpm-provided facilities, because now you actually understand why they need to behave the way they do. Of course some people are too lazy to actually fix all corner cases, or too proud to admit they were wrong, so they will push garbage that does not make use of the tech capabilities, and complain rpm is awful). It's the same difference between an init tech with barebones facilities, that requires you to write giant custom scripts to work (SysV init), and something with built-in capabilities, that requires knowing the manual to call the built-in capabilities correctly (systemd).

And the rest is just the packaging policies and rules of each distro, which are not the same, so anyone looking at the packages done by other distros will be lost and unhappy, and only people that mistake their habits with natural laws of nature will seriously complain about it (yes, Debian packaging is weird and crufty too when looked at by outsiders). And two rpm distros won't do things the same way because they don't have the same opinions, and so would two deb distros.

The rpm format is actually nice enough many distributions adopted it and do their own different thing with it. And yes it also provides automation facilities in form of macros, so you don't have to do it all by hand, and distros with different opinions and objectives will automate things differently, what's the problem with that? It's like complaining not two Firefox users install the same extensions, and it's too hard to understand why two Firefoxes do not behave the exact same way.

Improving .deb

amacater — Fri, 31 May 2019 08:05:21 +0000

Take a CentOS machine with no third party proprietary RPMS but maybe some EPEL (built by Fedora for RHEL/CentOS) installed and updated to be running CentOS 5.10 - that ran out of support in 2017 - so only two years out of support. Try to upgrade it to CentOS 6 - pretty much guarantee you'll fail - there's no upgrade path. If by some lucky chance, you can hand craft it: move to CentOS 6.8 and do the same to move it to 7 - that's two current distributions. Now move it to 8. Four distributions with a long term lifecycle - three of them concurrent and fully supported -but no upgrade path through them.

If you keep your Fedora fully maintained then you'll be upgrading every 12 months or so and will lose support for your version at best every 18 months.

Now take a neglected Debian 7 - some two years out of support. Move it to 8 which is on long term support. Move it to 9. [In a month or so, you can move it to 10 when Buster comes out, maybe.] That includes the sysvinit-systemd transfer which needs a reboot. That takes you from kernel 3.10 - 4.4 seamlesly and 4.19 next month. Oh, and for fun, do this with no network access. You might do this with CentOS: you _can_ do this with DVD images and Debian :) [And yes, it's an "uphill, both ways in the snow" kind of story - but it's real, and there are lots of machines out there that are "only" two years out of support and have to be maintained and upgraded without data loss. ].

Improving .deb

nim-nim — Fri, 31 May 2019 07:11:40 +0000

Well PAX tar (POSIX.1-2001) was specified more than 20 years ago, is supported by tools (even if GNU tar does not use it as default write format) and as far as I know has all the legacy limitations lifted.

Are there still reasons not to use it?

Improving .deb

bojan — Fri, 31 May 2019 04:20:58 +0000

I use rpm as both a user and a packager. Are there issues? Sure, sometimes. Do things generally work? Yep.

So, I have no idea why folks go on these long rants to point out how everything Debian has an almost saint like quality and everything else is pure junk. The fact is that both systems are in widespread use and they work, each with their own limitations.

Improving .deb

wahern — Fri, 31 May 2019 02:18:40 +0000

Yes, RPM is manifestly serviceable. But my experience comes not as a user but as a packager. It's been over a year since I last had to package using RPM and have mostly tried to put it all behind me. Suffice it to say that the only thing the RPM format and RPM tooling has going for it is that from a distance it looks enticing--simpler, cleaner, more convenient. It's none of those things when you get up close, though. And don't get me started on Yum/DNF....

> Who would have thought that a package format that is 22 years old would be like that. :-)

Debian package users! The Debian package format is old and wrinkly, but it has aged incredibly well in terms of forethought and capabilities. The tooling is more complex but that's because the ecosystem is layered. Many of the biggest headaches in the land of Yum and RPM (sections, macros, file contents, dependencies, building, ...) are insurmountable and force everybody and everything to accommodate the limitations. (Ignorance is bliss, though!) For every headache one can identify in the land of .debs and Apt there are *both* dirty hacks and clean changes in approach that resolve them; rarely are you stopped in your tracks with the realization you simply cannot accomplish something functionally.

IMO the Debian packaging ecosystem continues to evolve and improve. There are improvements to the RPM ecosystem, but they asymptotically move RPM toward a wall.

Detailing all the issues here would be impractical (and I don't have the memory for it, only the scars), but if you have time carefully go through the history of the development of Modularity (you may need to use Wayback Machine to see how the project specifications changed) and you'll see how RedHat had to backtrack and literally reinvent Modularity late in the RHEL8 development cycle after they realized they couldn't surmount various limitations to RPM, particularly with regards to build-time and run-time dependency management. I remember a co-worker raving about how awesome it would be and me being incredulous that they could pull it off, and lo-and-behold it turned out that they couldn't.

Improving .deb

bojan — Fri, 31 May 2019 01:15:18 +0000

Well, my Fedora 30 box must be on fire then, I'm sure. After all, I've been upgrading it since Red Hat Linux 6.0 (no, not RHEL 6 - the actual RHL 6.0), with at one point cross-grading to x86_64 from i386/i686 (totally not recommended, not supported and yet quite doable). And yet, it all still works. But, I'll delete it all right now, because it obviously is broken beyond repair. Oh, wait...

So, RPM has been tinkered with since its inception and now has a whole lot of baggage caused by various design errors, improvements, folks finding ways to bend it in new and useful ways. Shocking stuff. Who would have thought that a package format that is 22 years old would be like that. :-)

More planned, BTW: https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zst...

why confine the discussion to Linux-based systems?

compenguy — Fri, 31 May 2019 00:11:22 +0000

> And don't get me started with the in-built database in MSI.

What on earth do you think rpms are? Each rpm is a berkeley db hierarchical database.

> The whole Windows experience is so complicated in comparison with a Linux system. In Linux, the main effort is creating good build scripts. In Windows, you are always writing custom actions to supplement the installer itself, its dependencies and runtimes.

Actually, there are a lot of technical parallels between MSI design and execution and rpm design and execution. If you look at the order that rpm scripts are run during upgrade, it's a really mind-bending process and feels really unnatural. But it is, in fact, very very efficient with disk writes/erases especially when not all the files in the package might be changing. An MSI installer with a late-scheduled RemoveExistingProducts executes actions in a sequence _very_ similar to rpms.

In fact, if PowerShell, Wix, and Burn had been invented about a decade prior, the MSI installer development experience would have looked a good bit more like rpm than it currently does.

As it is, though, Microsoft is trying not to invest anything in MSI in order to push their app store distribution model. Apple deprecated their pkg installation system probably almost a decade ago, again "because appstore", but they still can't manage to kill it - it's just too useful (although the pkg system is pretty scary in its own right).

Improving .deb

smoogen — Thu, 30 May 2019 18:44:14 +0000

yes it was a joke.. an old one that Debian would use ogg containers way before it would ever use cpio.. and vice versa that RPM would use ogg before it would use tar.

Improving .deb

imMute — Thu, 30 May 2019 17:22:57 +0000

All package building within Debian's buildd network is done using chroots (typically via a tool like pbuilder, sbuild, etc). I've found that you can get pretty big speedups by doing all that on a tmpfs. So, yes, disk IO is a big bottleneck for *users* of deb packages. But *builders* of those debs could benefit from speed increases elsewhere.

For example, pbuilder itself uses compressed tarballs to store an image of the rootfs at rest. Each time you want to build a package, that tarball has to be uncompressed and extracted. I've found that you can use cowbuilder instead (I'm not sure exactly how the "instead" happens - git-buildpackage does it automagically for me) which keeps everything uncompressed/untarred and uses COW filesystems to copy the "pristine" rootfs for each build. It's incredibly fast to get the chroot ready to use, and then I find myself waiting 2-3 minutes for apt to install all my dependencies (obtained from a cache on the same ramfs; *not* from a mirror).

Improving .deb

imMute — Thu, 30 May 2019 15:50:21 +0000

>Deb's tooling doesn't let you provide/require a SONAME, rather the tooling will look at known packages and use the name of the package that installs that lib as the dependency.

I wonder if this wouldn't be possible in debs with some creative use of Provides and Requires. A package containing a library that "provides" some SONAME could have a "Provides: SONAME-libfoo.so.2" on it. Packages that need that SONAME could add "Requires: SONAME-libfoo.so.2". Specific versioning would be tricky, since you can't know the exact versioning a providing package uses. I'm thinking epoch versions might throw a wrench in there... Also that the SONAME "version" number and the package version number (even just the "upstream" part) aren't always numerically the same.

Since everyone should already be using dh_makeshlibs / dh_shlibdeps, this might not even be too hard to prototype...

Improving .deb

imMute — Thu, 30 May 2019 15:41:51 +0000

As someone who maintains debian packages (for our company, not for Debian itself), uses Xilinx toolchains, AND has read a tiny bit about flatpack/snap/etc, I'm really torn.

As a pro-distribution guy, I like the benefits that package maintainers bring. On the other hand, I love that the Xilinx toolchain is entirely self contained: no need to mess around with figuring out which dependencies are needed (because god help them if they actually document those things). I totally see why flatpack (et. al.) are rapidly gaining popularity.

Improving .deb

eru — Thu, 30 May 2019 15:05:03 +0000

When comparing compressed archives that compress each file separately with compressing an uncompressed archive as a whole, it seems to me the kernel source is the best-case for the latter: almost all files are C sources belonging to the same software project, so they have lots of mutual similarity for the compressor to chew on, and C code also compresses well. By contrast, a deb or rpm usually contains mostly binaries and other binary data files, which are less similar and less compressible. I am sure the size difference would be much less between the two approaches, if real binary packages were used as the test material.

ar limits

mort — Thu, 30 May 2019 13:01:35 +0000

I once tried to package up all of Chromium, with debug symbols, as an ar archive for static linking. I definitely hit size limits.

Improving .deb

jond — Thu, 30 May 2019 11:08:27 +0000

That was a great (terrifying) read, thanks.

I'm now wondering how much rpm-ostree might side-step this madness, if at all.

Improving .deb

bokr — Thu, 30 May 2019 09:08:04 +0000

Seems like in a discussion of packaging, the gnu guix package features deserve a look?

Their base long-term dependency is the stability of the linux kernel ABI, as I understand it,
so old apps using old libraries can coexist with newer, so long as the kernel supports all
the syscalls involved (which Linus is pretty good at enforcing as the kernel evolves),

https://www.gnu.org/software/guix/manual/en/html_node/Fea...

Improving .deb

Tov — Thu, 30 May 2019 06:00:06 +0000

Huge proprietary applications should not use distribution package formats like .deb or .rpm anyway. More often than not they pollute the filesystem with their own idea of absolute directory structures, included libraries, broken dependencies and impossible un-installation.

That is exactly what we have appimage/snap/flatpak for!

Improving .deb

unixbhaskar — Wed, 29 May 2019 22:48:18 +0000

Proposals sound bloody good. But, do not make changes for the sake of changes. And importantly, which should not break the existing stuff, then all hell might break.

I think if not months, a few years down the line, surely there must be some change in this respect. No point to make a hasty decision.

Improving .deb

notriddle — Wed, 29 May 2019 20:32:37 +0000

Ogg?! I'd rather use a giant bencode dictionary; at least it doesn't have a bunch of superfluous features for A/V sync and stuff.

d7:control10:TARCONTENT4:data10:TARCONTENTe

Improving .deb

mathstuf — Wed, 29 May 2019 20:16:32 +0000

> After all, the only other modern application of this format is for static libraries (they are ar archives with object code files inside)

Even Windows static libraries are `ar` format (the linkable part of shared libraries are too, they just have some metadata which says "runtime load this .dll file").

rpm pains (orig: Improving .deb)

domo — Wed, 29 May 2019 18:53:40 +0000

I'd also vote down rpm 4 format...

In early 2010's I spend one month trying to figure out the rpm source code in order to
make it working elsewhere. While doing that I got some knowledge about the format,
and then got good enough replacement made using perl(1)

search for 'rrpmbuild' for code reference.

the format is quite complicated for human observer...

whatever the format is (IMO extending ar(5) is not best option, old tools cannot understand
it anyway, so something better could be deviced) it should be simple enough everyone
can easily do their own tools (or help extending the existing ones).

Best would be some new "extensible linux package format" (w/ sane format, no xml etc)
which could be adopted by all distributions. the format would have extensible package
metadata format, and then extensible file (metadata, including file contents) format.

Even I could device such a format, just that no-one would adopt implementation done
by random programmer very often...

Improving .deb

wahern — Wed, 29 May 2019 18:42:22 +0000

A big problem with Zip, IMO, is that the metadata for archived files is stored twice--in an index and as a header to each file. Which one do you use and trust? This creates a dilemma for metadata parsers and especially security scanners.

If you don't mind the uncleanliness and potential security issues of such redundant metadata, one can create an index for tar files, including compressed tar files. I've experimented with this (for both tar and tar+gzip), though nothing releasable. The upside is that adding an index could be done in a backward compatible manner--just another object in the outer archive that could be ignored.

Improving .deb

wahern — Wed, 29 May 2019 17:48:50 +0000

> There isn't a huge difference between rpms and debs at the end of the day.

That's not at all fair to Debian packages. You can make do with RPM and the RPM ecosystem (Yum, DNF), but it's still a pock marked hell scape. Here's a good jumping off point for the low-level sins of RPM specifically: https://xyrillian.de/thoughts/posts/argh-pm.html

Improving .deb

thoughtpolice — Wed, 29 May 2019 17:41:03 +0000

> So back to my main point, having the file size limit can force developers to do sensible things like solve the problems above.

If that was the case and how it worked in reality, they would have already fixed it. But they haven't: rather than getting a .deb package that can easily be installed like any others, they ship tarball installers with horrid self-extraction programs. In fact they probably wouldn't do it anyway even with that problem fixed, because they want one binary blob they ship to every platform, hence why they vendor everything under the sun. They have no interest in supporting multiple package formats. You're making a categorical error in thinking their goals (ship highly expensive, niche, proprietary software to users in controlled environments with support contracts) are the same as yours ("nice" Linux system integration). In fact the only people who suffer under this setup are the people who *do* want to be "nice" about Linux system integration, and ship .deb files of large programs/packages (for reasons that may not entirely be under their control.) Not Xilinx. And even if it wasn't a moot point, single device families (UltraScale+ IIRC) consume more space than is already allowed by a single .deb anyway, so there you go.

If you think a company like Xilinx that makes billions of dollars a year is going to change all of this because Debian has an artificial technical restriction on the size of .deb files: they won't, you're just not that important. They do not care about what Linux distro developers/users want or think is "ideal", and they have far more money and time than you do, so they can make it work. They have more money to burn than you have time to implement artificial technical restrictions to try and "force them" to behave. I don't know why people persist in believing this kind of trivial, easily-countered approach works: the entire premise relies on the faulty assumption that the dynamics of power are in your favor. They are not.