why confine the discussion to Linux-based systems?
why confine the discussion to Linux-based systems?
Posted May 29, 2019 10:52 UTC (Wed) by hei8483j (guest, #124709)In reply to: why confine the discussion to Linux-based systems? by gus3
Parent article: Improving .deb
Posted May 31, 2019 0:11 UTC (Fri)
by compenguy (guest, #25359)
[Link] (1 responses)
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).
Posted Jun 3, 2019 23:26 UTC (Mon)
by brouhaha (subscriber, #1698)
[Link]
The system-wide RPM database is a berkeley db.
An individual RPM file is just an RPM header prepended to a cpio archive.
why confine the discussion to Linux-based systems?
why confine the discussion to Linux-based systems?