a project by RBrownSUSE
zypper is magic
A number of experiments suggest that it may be feasible to run zypper from an openSUSE 'live' media against a 'foreign' RPM based OS installation (eg. CentOS) and then 'zypper dup' to openSUSE
Thanks to satsolver, openSUSE's heavy use of pkgconfig(), and our sometimes 'excessive' recommends, zypper always seems able to suggest a viable upgrade solution, replacing the foreign CentOS/RHEL packages with appropriate openSUSE ones
Rough edges
Of course, this wouldn't be a hackweek project if it 'just worked' - There are a number of rough edges that need serious effort before this idea is 'usable'
- dracut - making sure mkinitd gets rebuilt to replace the 'foreign' dracut with our own
- config files in different locations - a potential use case for Machinery?
- different package names - is satsolver really smart enough to figure out how to upgrade packages with different names?
- testing testing testing - this may work in the lab with very basic installations, does it really work in practice?
- not just RPM's? - could we get zypper/libzypp/satsolver to understand .debs enough to know how to replace them?
This project is part of:
Hack Week 11
Activity
Comments
-
about 11 years ago by bmwiedemann | Reply
at some point we also had zypper binaries for Fedora in https://build.opensuse.org/package/show/zypp:Head/zypper but those seem to have bitrotten
-
about 11 years ago by RBrownSUSE | Reply
The way I was thinking of tackling this was by using an openSUSE liveCD. That way I have a known zypper/libzypp stack and point it to the 'foreign' OS using zypper -R (chroot). Also opens a few doors such as maybe converting to btrfs and snapshotting in a sane and safe way to rollback if the 'upgrade' goes horribly wrong.
-
-
about 11 years ago by ZeDestructor | Reply
Why openSUSE instead of moving to a newer CentOS/RHEL? I'm genbuinely curious, and have been considering doing the opposite myself...
-
about 11 years ago by RBrownSUSE | Reply
Because openSUSE/SLE has a lot to offer which CentOS/RHEL do not. Quick examples - YaST, btrfs as a recommended filesystem for root, a huge library of packages in OBS and the platform to build your own, and a package manager that does RPM's 'right'. But right now, the only options for someone wanting to try jumping from one to the other is painful and probably involving reinstallation and lots of reconfiguration.. I want to see if we can make that easier - With zypper we can seamlessly jump not only from one version of our distribution to another (eg 12.3 to 13.1) but also from one 'type' of distribution to another (eg. regular openSUSE to rolling openSUSE Factory).. why shouldn't we also be able to jump from an entirely different distribution to openSUSE?
-
Similar Projects
GHC-9.14 and split Hadrian from GHC build by osukup
Description
Prepare openSUSE Tumbleweed project for new GHC Haskell compiler and separate builder (Hadrian) from GHC build
Goals
- have GHC-9.14 project with working compiler and if possible filled with packageset
- have Hadrian in own package built with bootstrap compiler to separate Hadrian bootstrap from ghc bootstrap
Resources
opensuse haskell package gen project
openSUSE on ZoL from OpenZFS project by jkohoutek
Idea is to have SUSE system with OpenZFS as root FS.
Why ZFS
Ways in which ZFS is better than BTRFS
Main goal
Have OpenZFS as install option in the installer and utilize zedenv Boot Environment Manager for SUSE updates install
Goals
- synergy of ZFS with dracut, so snapshots are correctly added to the grub
- synergy of zedenv with zypper
- before every update snapshot is created
- when new kernel or other package which requires reboot is about to be installed, the update will be processed to the new boot environment snapshot and grub configuration changed to boot to this new one
- integrate Root on ZFS as install option to the YaST
- configure Kiwi for the ZFS install images
Completed goals
- prepare ZFS pool compatible with openSUSE installation ✓
- install openSUSE with root on ZFS ✓
- boot to the prepared and installed system ✓
Resources:
File search subcommand for zypper by mook_work
Description
Zypper currently only supports searching for files in a few pre-defined prefixes (/usr/bin, /usr/sbin, etc.) via using rpm provides. This means that it is difficult to find files that are not in the explicit list.
Doing this in zypper itself seems difficult.
Goals
Create a zypper subcommand (plugin) that can download file lists as needed to search for file contents. As a stretch goal, have a secondary subcommand that can list files in packages regardless of whether they are already installed.
At this point, making the resulting code usable as part of zypper itself is not a goal, as it would probably take more time than available.
Resources
Upstream issue: https://github.com/openSUSE/zypper/issues/469
Stretch goal: https://github.com/openSUSE/zypper/issues/164
Subcommands: https://manpages.opensuse.org/Tumbleweed/zypper/zypper.8.en.html#SUBCOMMANDS
openSUSE on ZoL from OpenZFS project by jkohoutek
Idea is to have SUSE system with OpenZFS as root FS.
Why ZFS
Ways in which ZFS is better than BTRFS
Main goal
Have OpenZFS as install option in the installer and utilize zedenv Boot Environment Manager for SUSE updates install
Goals
- synergy of ZFS with dracut, so snapshots are correctly added to the grub
- synergy of zedenv with zypper
- before every update snapshot is created
- when new kernel or other package which requires reboot is about to be installed, the update will be processed to the new boot environment snapshot and grub configuration changed to boot to this new one
- integrate Root on ZFS as install option to the YaST
- configure Kiwi for the ZFS install images
Completed goals
- prepare ZFS pool compatible with openSUSE installation ✓
- install openSUSE with root on ZFS ✓
- boot to the prepared and installed system ✓
Resources: