This is being solved.

*** This bug has been marked as a duplicate of bug 1493479 ***

OK, to clarify things... :)

(In reply to Lukas Slebodnik from comment #0)
> Description of problem:
> Enabling services in %post is forbidden in Fedora according to Stephen
> Gallager and fedora wiki pages.

Please provide the links for any claims (the wiki pages) next time. :) I usually  do not have time to go looking for them on the Internet. Thank you. ;)

> And reason is: because this will break things if you're running in an
> installer environment (and there's no reliable way to detect when you are or
> are not in the installer environment).

OK, finally you have stated the problem itself. Nevertheless, as I told you before - 'fedora-import-state.service' is often needed during boot process to bootup correctly, and this service has to be enabled by default for now:
https://bugzilla.redhat.com/show_bug.cgi?id=1493479#c10

Also, we are not using simple %post or %postun for this. We are actually using this:

# This should be removed in Rawhide for Fedora 29:
%triggerun -- initscripts < 9.78
if [ $1 -gt 1 ]; then
  systemctl enable fedora-import-state.service fedora-readonly.service &> /dev/null || :
  echo -e "\nUPGRADE: Automatically re-enabling default systemd units: fedora-import-state.service fedora-readonly.service\n" || :
fi

That's actually a trigger, which is fired up only once - when doing an upgrade to newer version initscripts, while the version 9.77 (or older) is being uninstalled.

AFAICT, during Fedora 27 installation, there shouldn't be any upgrade of initscripts package.

The only relevant time when this triggers should be run is either during upgrade to F27/F28 from previous Fedora releases, or via 0-day updates for F27. For both these cases, the trigger is needed, as I have already described.

> Please use right way with enabling services in preset files.

Have you actually try upgrading of initscripts without the trigger (and with correct fedora-release package, which has these services enabled by default in /usr/lib/systemd/system-preset/90.default)?

I have tried it before, and what I have ended up with was:
 * correct 'fedora-release' package (with services enabled by default)
 * updated 'initscripts' package (9.78)
 * fedora-import-state.service and fedora-load-modules.service DISABLED

That's why we went with the usage for trigger, so many users do not end up with unbootable system - they certainly wouldn't love us for that...

> And BTW it is not allowed to ship own preset files in fedora. Please do that
> in right package (fedora-release). I let you file a ticket to other
> component and I'll be waiting for fixing this BZ.

Ehm, did you even read what I have sent you before? Because it certainly does seem like it. As I already told you, this is being taken care of.

You obviously fail to see the context here, and I have already spent a quite some time on this discussion. Unless you can tell me on how to achieve what we need in a better way, there's nothing more to discuss... :)

Have a nice day,

 -- Dee'Kej --

It is not a duplicate. Main point is to get rid of calling "systemctl enable"
from rawhide. 

I know that it need to be in f27 but this  BZ is for rawhide.

(In reply to David Kaspar [Dee'Kej] from comment #2)
> OK, to clarify things... :)
> 
> (In reply to Lukas Slebodnik from comment #0)
> > Description of problem:
> > Enabling services in %post is forbidden in Fedora according to Stephen
> > Gallager and fedora wiki pages.
> 
> Please provide the links for any claims (the wiki pages) next time. :) I
> usually  do not have time to go looking for them on the Internet. Thank you.
> ;)
> 
> > And reason is: because this will break things if you're running in an
> > installer environment (and there's no reliable way to detect when you are or
> > are not in the installer environment).
> 
> OK, finally you have stated the problem itself. Nevertheless, as I told you
> before - 'fedora-import-state.service' is often needed during boot process
> to bootup correctly, and this service has to be enabled by default for now:
> https://bugzilla.redhat.com/show_bug.cgi?id=1493479#c10
> 
> Also, we are not using simple %post or %postun for this. We are actually
> using this:
> 
> # This should be removed in Rawhide for Fedora 29:
> %triggerun -- initscripts < 9.78
> if [ $1 -gt 1 ]; then
>   systemctl enable fedora-import-state.service fedora-readonly.service &>
> /dev/null || :
>   echo -e "\nUPGRADE: Automatically re-enabling default systemd units:
> fedora-import-state.service fedora-readonly.service\n" || :
> fi
>
Sure you need to have it in f27 due to upgrades.

But if change is safe for f27 then it is safe for f26 as well (including changed preset in fedora-release) and then we can get rid of it from rawhide in fedora 28 (because upgrade from f25 -> f28 is unsupported)


> The only relevant time when this triggers should be run is either during
> upgrade to F27/F28 from previous Fedora releases, or via 0-day updates for
> F27. For both these cases, the trigger is needed, as I have already
> described.
>
Sure but this BZ is not for f27 but for rawhide.
 
> > Please use right way with enabling services in preset files.
> 
> Have you actually try upgrading of initscripts without the trigger (and with
> correct fedora-release package, which has these services enabled by default
> in /usr/lib/systemd/system-preset/90.default)?
>
> I have tried it before, and what I have ended up with was:
>  * correct 'fedora-release' package (with services enabled by default)

You cannot have correct fedora-release on rawhide; because that services are not enabled fedora-release-28-0.1.noarch so triggers do its job. But that's bug in different package.

The purpose of BZ is to get rid of trigger; because you will have already right state on f26 and f27 before upgrade so trigger will be useless on f28(rawhide ATM)

And I realize that it will take some time to get updates fedora-release + initscripts to f26. So I do not want to fix this BZ immediately.

(In reply to Lukas Slebodnik from comment #4)
> Sure you need to have it in f27 due to upgrades.
> 
> But if change is safe for f27 then it is safe for f26 as well (including
> changed preset in fedora-release) and then we can get rid of it from rawhide
> in fedora 28 (because upgrade from f25 -> f28 is unsupported)

Sorry, but what you just wrote does not make much sense to me. It seems you're still missing the point here...

The changes introduced for F27 will not go to F26! F26 is intended to be stable now, and we try to introduce changes to behaviour for new releases only.

To backport this into F26, the changes to 'fedora-release' would have to be made for F26 branch, which is very unlikely. As I said, F26 should be stable and doing changes to default settings (even though they would remain the same) is still more risky.

So, the first release where we make this change is F27. That means we have to support this possible ways of upgrading:

F25 -> F27
F26 -> F27
F26 -> F28

> Sure but this BZ is not for f27 but for rawhide.

You fail to see this problem in broader context, which is not something I can do anything about it.

> You cannot have correct fedora-release on rawhide; because that services are
> not enabled fedora-release-28-0.1.noarch so triggers do its job. But that's
> bug in different package.

Yes, and as Zbyszek already said - this is being taken care of, but I still don't see a point in this "argument" (actually more like a straw-man rather than argument).

> The purpose of BZ is to get rid of trigger; because you will have already
> right state on f26 and f27 before upgrade so trigger will be useless on
> f28(rawhide ATM)

No! If you have done some searching in Bodhi, you would see that this update IS NOT making it IN F26!

I will remove the trigger in Rawhide for F29, when the change will be present in stable Fedora for 2 releases, as it should be for any upgrades/changes.

> And I realize that it will take some time to get updates fedora-release +
> initscripts to f26. So I do not want to fix this BZ immediately.

I don't see a reason to backport these changes into F26 to risk breaking anything.

TO SUM UP:
 * you still haven't provided any reproducer/testcase that would show it is *actually* breaking anything
 * you seem to not see the broader context we have to take into account
 * this seems to be a more phylosophical rather than practical issue for you

To conclude - I'm not removing the triggers no sooner than in Rawhide for Fedora 29. Period. And unless there's actually something broken, I'm not looking for a fix for hypothetical bug that might not even occur. I have better things to do than be going over this over and over again.

(In reply to David Kaspar [Dee'Kej] from comment #5)
> (In reply to Lukas Slebodnik from comment #4)
> > Sure you need to have it in f27 due to upgrades.
> > 
> > But if change is safe for f27 then it is safe for f26 as well (including
> > changed preset in fedora-release) and then we can get rid of it from rawhide
> > in fedora 28 (because upgrade from f25 -> f28 is unsupported)
> 
> Sorry, but what you just wrote does not make much sense to me. It seems
> you're still missing the point here...
> 
> The changes introduced for F27 will not go to F26! F26 is intended to be
> stable now, and we try to introduce changes to behaviour for new releases
> only.
>
> To backport this into F26, the changes to 'fedora-release' would have to be
> made for F26 branch, which is very unlikely. As I said, F26 should be stable
> and doing changes to default settings (even though they would remain the
> same) is still more risky.
> 
> So, the first release where we make this change is F27. That means we have
> to support this possible ways of upgrading:
>

f27 is stable as well at the moment

I'm sorry but if you are able to support it in f27 then what is a problem to support it in f26? If you want to wait a month to ensure you didn't introduce
any regression into f27 then it is fine as well.

But I cannot see any technical reason why it should not be backported to f26
if it is already in f27. (I didn't ask to backport to f25 because it is really late for f25; because will be EOL in a month. f26 will be EOL in 8 months.

 
> F25 -> F27
> F26 -> F27
> F26 -> F28
> 
> > Sure but this BZ is not for f27 but for rawhide.
> 
> You fail to see this problem in broader context, which is not something I
> can do anything about it.
>

I discuss that with Stephen Gallagher and he explained me that problem in details. I do not think I miss anything here.

 
> > You cannot have correct fedora-release on rawhide; because that services are
> > not enabled fedora-release-28-0.1.noarch so triggers do its job. But that's
> > bug in different package.
> 
> Yes, and as Zbyszek already said - this is being taken care of, but I still
> don't see a point in this "argument" (actually more like a straw-man rather
> than argument).
> 

That 's off topic for this BZ.

> > The purpose of BZ is to get rid of trigger; because you will have already
> > right state on f26 and f27 before upgrade so trigger will be useless on
> > f28(rawhide ATM)
> 
> No! If you have done some searching in Bodhi, you would see that this update
> IS NOT making it IN F26!
> 

And that seems to be main misunderstanding.
But it seems you do not fell confident to backport it to f26.
Sure that's fie you are maintainer. I can have different opinion but most important is your decision.


> I will remove the trigger in Rawhide for F29, when the change will be
> present in stable Fedora for 2 releases, as it should be for any
> upgrades/changes.
> 

I you do not feel confident about your changes to backport to f26
I'm fine with that

But I want to keep tracking it when it will be removed from rawhide
Therefore this BZ cannot be closed as WONTFIX because you want to do that.
It's just question of time => therefore reopening ticket.

(In reply to David Kaspar [Dee'Kej] from comment #2)
> OK, to clarify things... :)
> 
> (In reply to Lukas Slebodnik from comment #0)
> > Description of problem:
> > Enabling services in %post is forbidden in Fedora according to Stephen
> > Gallager and fedora wiki pages.
> 
> Please provide the links for any claims (the wiki pages) next time. :) I
> usually  do not have time to go looking for them on the Internet. Thank you.
> ;)
> 
> > And reason is: because this will break things if you're running in an
> > installer environment (and there's no reliable way to detect when you are or
> > are not in the installer environment).
> 
> OK, finally you have stated the problem itself. Nevertheless, as I told you
> before - 'fedora-import-state.service' is often needed during boot process
> to bootup correctly, and this service has to be enabled by default for now:
> https://bugzilla.redhat.com/show_bug.cgi?id=1493479#c10
> 
> Also, we are not using simple %post or %postun for this. We are actually
> using this:
> 
> # This should be removed in Rawhide for Fedora 29:
> %triggerun -- initscripts < 9.78
> if [ $1 -gt 1 ]; then
>   systemctl enable fedora-import-state.service fedora-readonly.service &>
> /dev/null || :
>   echo -e "\nUPGRADE: Automatically re-enabling default systemd units:
> fedora-import-state.service fedora-readonly.service\n" || :
> fi
> 

I know you are busy but would you mind to fix it in rawhide? It is already f29 for some time :-). Or should I create pull-request?

Hello! :)

I will create a pull-request for it, so it's not forgotten. But I would prefer not to merge it before F28 GA is officially out, just to be sure. Then it should be IMHO save to remove the systemctl call in F29. :)

(In reply to David Kaspar [Dee'Kej] from comment #8)
> Hello! :)
> 
> I will create a pull-request for it, so it's not forgotten. But I would
> prefer not to merge it before F28 GA is officially out, just to be sure.
> Then it should be IMHO save to remove the systemctl call in F29. :)

Awesome.

And thank you for info about your plans.

https://github.com/fedora-sysv/initscripts/pull/170