Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 0.3.0
    • Fix Version/s: None
    • Component/s: general
    • Labels:
      None

      Description

      We need to plan for adding native systemd support. Future Fedora and openSUSE versions will have this installed as default on a new install. Upgrading from 11.4 > 12.1 will retain sysv. Looking at what has happened in openSUSE 12.1 development will help a lot to guide adding the new bits.

        Activity

        Hide
        Julien Eid added a comment -

        Hey, I would love to take a look at this ticket. I recommend that we either version our repos to match distributions that have systemd and only include systemd for those repos or split our init scripts into noarch packages and have one package be sysvinit scripts and the other be systemd and you choose at install time which one you want. I would rather do the former and only include systemd scripts for packages of distributions that have systemd, like RHEL7.

        Looking over our gradle and make code, it appears we just call createrepo, but I don't see anyway currently to specify distribution specific ways of including files into packages. Maybe Konstantin Boudnik can shed more light on the best way to do this from build side?

        Show
        Julien Eid added a comment - Hey, I would love to take a look at this ticket. I recommend that we either version our repos to match distributions that have systemd and only include systemd for those repos or split our init scripts into noarch packages and have one package be sysvinit scripts and the other be systemd and you choose at install time which one you want. I would rather do the former and only include systemd scripts for packages of distributions that have systemd, like RHEL7. Looking over our gradle and make code, it appears we just call createrepo, but I don't see anyway currently to specify distribution specific ways of including files into packages. Maybe Konstantin Boudnik can shed more light on the best way to do this from build side?
        Hide
        jay vyas added a comment -

        i agree this is important. thanks for looking into it. Julien Eid

        Show
        jay vyas added a comment - i agree this is important. thanks for looking into it. Julien Eid
        Hide
        Sean Mackrory added a comment -

        IMO, we should decide at build-time whether the particular distros packages should use SysV init scripts or systemd. I wouldn't see that as something passed in by Make or Gradle, but a conditional that we trigger on in the spec file (search for the suse_version and mgaversion macros - they're used a lot) or rules file (I'm not so sure we've done this yet - but I believe packages should usually be built on the same distribution as what you're targeting, so perhaps we can use lsb_release, etc. in rules files?).

        This has the potential to be rather messy, since you're replacing which file gets included in the package and we'll have a bunch if if / else's everywhere, so we should look for some nice clean way to express that logic consistently across all services. Does systemd still use chkconfig for enabling / disabling services? Because if it doesn't, we also need to swap postinst and prerm scriptlets...

        Show
        Sean Mackrory added a comment - IMO, we should decide at build-time whether the particular distros packages should use SysV init scripts or systemd. I wouldn't see that as something passed in by Make or Gradle, but a conditional that we trigger on in the spec file (search for the suse_version and mgaversion macros - they're used a lot) or rules file (I'm not so sure we've done this yet - but I believe packages should usually be built on the same distribution as what you're targeting, so perhaps we can use lsb_release, etc. in rules files?). This has the potential to be rather messy, since you're replacing which file gets included in the package and we'll have a bunch if if / else's everywhere, so we should look for some nice clean way to express that logic consistently across all services. Does systemd still use chkconfig for enabling / disabling services? Because if it doesn't, we also need to swap postinst and prerm scriptlets...
        Hide
        Konstantin Boudnik added a comment -

        From the build point of view a distribution type is one of the externalities. Hence, build can only be reactively driven by the instructions provided at the package spec level. I am not the expert on the packaging, but I think we are can use platform specific defines like %arch in order to prevent particular bits and pieces from being included into a package. Or, otherwise, being included if needed.

        In general, I agree that we can do a way better job of splitting out noarch parts of our packages like you said above. If you feel like working on this - let's ping Peter Linnell to make sure he doesn't do it already Thanks!

        Show
        Konstantin Boudnik added a comment - From the build point of view a distribution type is one of the externalities. Hence, build can only be reactively driven by the instructions provided at the package spec level. I am not the expert on the packaging, but I think we are can use platform specific defines like %arch in order to prevent particular bits and pieces from being included into a package. Or, otherwise, being included if needed. In general, I agree that we can do a way better job of splitting out noarch parts of our packages like you said above. If you feel like working on this - let's ping Peter Linnell to make sure he doesn't do it already Thanks!

          People

          • Assignee:
            Peter Linnell
            Reporter:
            Peter Linnell
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:

              Development