Resistance is Futile - Using zypper to "upgrade" CentOS/RHEL to openSUSE/SLES
a project by RBrownSUSE
Updated almost 5 years ago. 23 hacker ♥️.

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?

Join this project

Looking for hackers with the skills:

packaging zypper dracut machinery

This project is part of:

Hack Week 11

Activity

  • about 10 years ago: im_unbob liked this project.
  • about 10 years ago: a_faerber liked this project.
  • about 10 years ago: mvidner liked this project.
  • about 10 years ago: xgonzo liked this project.
  • about 10 years ago: jjolly liked this project.
  • about 10 years ago: gsanso liked this project.
  • about 10 years ago: lslezak liked this project.
  • about 10 years ago: whdu liked this project.
  • about 10 years ago: abonilla liked this project.
  • about 10 years ago: abonilla liked this project.
  • about 10 years ago: abonilla liked this project.
  • about 10 years ago: abonilla liked this project.
  • about 10 years ago: extropian liked this project.
  • about 10 years ago: dmacvicar liked this project.
  • about 10 years ago: jafr liked this project.
  • about 10 years ago: thutterer liked this project.
  • about 10 years ago: FunkyPenguin joined this project.
  • about 10 years ago: deneb_alpha liked this project.
  • about 10 years ago: RBrownCCB liked this project.
  • about 10 years ago: gsanso joined this project.
  • about 10 years ago: michal-m liked this project.
  • about 10 years ago: e_bischoff liked this project.
  • about 10 years ago: KGronlund liked this project.
  • about 10 years ago: dmdiss liked this project.
  • about 10 years ago: RBrownSUSE liked this project.

    • All Activity

    Comments

    • bmwiedemann
      about 10 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

      • RBrownSUSE
        about 10 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.

    • ZeDestructor
      about 10 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...

      • RBrownSUSE
        about 10 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

    Update Haskell ecosystem in Tumbleweed to GHC-9.10.x by psimons

    Description

    We are currently at GHC-9.8.x, which a bit old. So I'd like to take a shot at the latest version of the compiler, GHC-9.10.x. This is gonna be interesting because the new version requires major updates to all kinds of libraries and base packages, which typically means patching lots of packages to make them build again.

    Goals

    Have working builds of GHC-9.10.x and the required Haskell packages in 'devel:languages:haskell` so that we can compile:

    • git-annex
    • pandoc
    • xmonad
    • cabal-install

    Resources

    • https://build.opensuse.org/project/show/devel:languages:haskell/
    • https://github.com/opensuse-haskell/configuration/
    • #discuss-haskell
    • https://www.twitch.tv/peti343

    Packaging Mu on OBS by joeyli

    Description

    Packaging Microsoft Mu project

    Goals

    Packaging Mu RPM on OBS.

    Resources

    https://microsoft.github.io/mu/

    https://github.com/microsoft/mu

    https://github.com/microsoft/mu_basecore

    https://github.com/microsoft/mutianoplatforms

    https://github.com/microsoft/mutianoplus

    https://github.com/microsoft/mu_plus

    Hackweek 22: Look at Microsoft Mu project

    https://hackweek.opensuse.org/22/projects/look-at-microsoft-mu-project

    https://drive.google.com/file/d/1BT31i7z3qh13adj9pdRz3lTUkqIsXvjY/view?usp=drive_link

    Framework laptop integration by nkrapp

    Project Description

    Although openSUSE does run on the Framework laptops out-of-the-box, there is still room to improve the experience. The ultimate goal is to get openSUSE on the list of community supported distros

    Goal for this Hackweek

    The goal this year is to at least package all of the soft- and firmware for accessories like the embedded controller, Framework 16 inputmodule and other tools. I already made some progress by packaging the inputmodule control software, but the firmware is still missing

    Resources

    As I only have a Framework laptop 16 and not a 13 I'm looking for people with hardware that can help me test

    Progress:

    Update 1:

    The project lives under my home for now until I can get an independent project on OBS: Framework Laptop project

    Also, the first package is already done, it's the cli for the led-matrix spacer module on the Framework Laptop 16. I am also testing this myself, but any feedback or questions are welcome.

    You can test the package on the Framework 16 by adding this repo and installing the package inputmodule-control

    Update 2:

    I finished packaging the python cli/gui for the inputmodule. It is using a bit of a hack because one of the dependencies (PySimpleGUI) recently switched to a noncommercial license so I cannot ship it. But now you can actually play the games on the led-matrix (the rust package doesn't include controls for the games). I'm also working on the Framework system tools now, which should be more interesting for Framework 13 users.

    You can test the package on the Framework 16 by installing python311-framework16_inputmodule and then running "ledmatrixctl" from the command line.

    Update 3:

    I packaged the framework_tool, a general application for interacting with the system. You can find it some detailed information what it can do here. On my system everything related to the embedded controller functionality doesn't work though, so some help testing and debugging would be appreciated.

    Update 4:

    Today I finished the qmk interface, which gives you a cli (and gui) to configure your Framework 16 keyboard. Sadly the Python gui is broken upstream, but I added the qmk_hid package with the cli and from my testing it works well.

    Final Update:

    All the interesting programs are now done, I decided to exclude the firmware for now since upstream also recommends using fwupd to update it. I will hack on more things related to the Framework Laptops in the future so if there are any ideas to improve the experience (or any bugs to report) feel free to message me about it.

    As a final summary/help for everyone using a Framework Laptop who wants to use this software:

    The source code for all packages can be found in repositories in the Framework organization on Github

    All software can be installed from this repo (Tumbleweed)

    The available packages are:

    • framework-inputmodule-control (FW16) - play with the inputmodules on your Framework 16 (b1-display, led-matrix, c1-minimal)

    • python-framework16_inputmodule (FW16) - same as inputmodule-control but is needed if you want to play and crontrol the built-in games in the led-matrix (call with ledmatrixctl or ledmatrixgui)

    • framework_tool (FW13 and FW 16) - use to see and configure general things on your framework system. Commands using the embedded controller might not work, it looks like there are some problems with the kernel module used by the EC. Fixing this is out of scope for this hackweek but I am working on it

    • qmk_hid (FW16) - a cli to configure the FW16 qmk keyboard. Sadly the gui for this is broken upstream so only the cli is usable for now

    Ansible for add-on management by lmanfredi

    Description

    Machines can contains various combinations of add-ons and are often modified during the time.

    The list of repos can change so I would like to create an automation able to reset the status to a given state, based on metadata available for these machines

    Goals

    Create an Ansible automation able to take care of add-on (repo list) configuration using metadata as reference

    Resources

    Results

    Created WIP project Ansible-add-on-openSUSE

    "autoremove" functionality for zypper by e_bischoff

    The purpose would be to have the equivalent of Ubuntu's "apt-get autoremove" functionality.

    When you install package P, it might draw in dependancies D1, D2, ... Dn automatically.

    When you later uninstall P, the dependancies D1, D2, ..., Dn might remain on your system.

    If you keep installing and uninstalling packages, after a while your system remains cluttered with things you don't need.

    The idea would be to mark all dependancies that were installed but not explicitely requested as "installed automatically". Then a command like "zypper autoremove" could remove them at once if they are not needed anymore.

    Approaches seen online

    After scouring forms for solutions these are some alias's used to replicate the functionality

    1. zypper packages --unneeded | awk -F'|' 'NR==0 || NR==1 || NR==2 || NR==3 || NR==4 {next} {print $3}' | grep -v Name | sudo xargs zypper remove --clean-deps

    2. This one is a script and has bashisms bash mapfile -t unneeded < <(zypper --quiet pa --unneeded | awk '$1 == "i" { print $5, "-", $7 }') (( ${#unneeded@]} )) && sudo zypper --quiet rm --clean-deps --details "${unneeded@]}"

    3. sudo zypper rm $(zypper pa --unneeded | awk '/i / {print $3}' FS='|' | uniq | tr -d ' ')

    Based on testing zypper packages --orphaned provides packages that are not in any repo, even if a user has explicitly installed them, so --orphaned may not be the way to go, instead focusing on --unneeded

    SUSE Prague claw machine by anstalker

    Project Description

    The idea is to build a claw machine similar to e.g. this one:

    example image

    Why? Well, it could be a lot of fun!

    But also it's a great way to dispense SUSE and openSUSE merch like little Geekos at events like conferences, career fairs and open house events.

    Goal for this Hackweek

    Build an arcade claw machine.

    Resources

    In French, an article about why you always lose in claw machine games:

    We're looking for handy/crafty people in the Prague office:

    • woodworking XP or equipment
    • arduino/raspi embedded programming knowledge
    • Anthony can find a budget for going to GM and buying servos and such ;)