== Summary ==
System units are managed through presets
[https://fedoraproject.org/wiki/Features/PackagePresets since F18] and
by policy, presets are carried by the fedora-release package. This
policy is now extended to user units.
== Owner ==
* Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in waw pl
== Detailed Description ==
The preset mechanism for user units was already in place, but we were
missing the actual preset files, and the default was "enable *"
instead of "disable *" as for system services.
Systemd will now provide a
/usr/lib/systemd/user-preset/99-default-disable.preset that marks user
services as disabled by default. Any user services which should be
enabled will be to get an appropriate preset in
/usr/lib/systemd/user-preset/90-default-user.preset or a spin-specific
file. Most packages already call into the preset mechanism, but those
which don't will be adjusted to do that.
This is essentially a fix for
https://bugzilla.redhat.com/show_bug.cgi?id=1468501. There is no good
reason to treat user services different than system services in this
regard. On the systemd side this change is very simple, but all
packages that provide user units need to be reviewed to check if they
are enabled after the change if appropriate.
== Benefit to Fedora ==
User and system services are handled in the same way.
Local configuration may be used to override which services should be
enabled after upgrade. In particular, "local" in this context may mean
"per-spin" or "per-user".
== Scope ==
* Proposal owners:
** review all packages that provide user services in Fedora and submit
PRs when changes are needed
** add a new presets file to the fedora-release package for user units
** submit a proposal to FPC to update the guidelines (essentially to
say "... and the same for user services.").
* Other developers:
** FPC: review (and accept ;)) the guidelines changes
** other maintainers: verify that units in their packages are enabled
or not as appropriate after package installation
* Release engineering: n/a
* Policies and guidelines: a pull request will be submitted
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Should not be user visible. Some units which are are currently enabled
by mistake will not be enabled anymore on new installations.
== How To Test ==
Install a new system (or uninstall and reinstall some packages).
Verify that the appropriate units are enabled for the user session.
== User Experience ==
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Revert the changes.
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
A pull request for the packaging guidelines will be submitted.
== Release Notes ==
He / Him / His
Fedora Program Manager
Ruby upstream is implementing more and more stuff directly in Ruby. We
already had issues, that build of Ruby required Ruby when we did some
modifications . In subsequent ticket, one of Ruby committers said :
> ... snip ...
> BASERUBY is already a build requirement
> ... snip ...
> I would like to implement more of Ruby using Ruby, so miniruby may
depend on prelude one day.
With recent changes, such as , I am afraid that the day has come.
Previously, if you wanted to patch lets say "gem_prelude.rb", it was
enough to patch it. But now you *need* Ruby to process it into
miniprelude.c. There are possibly 4 ways out of this.
1) Build Ruby in two stages. a) build (mini)ruby, apply patches b) build
Ruby using the previously built (mini)ruby.
2) Use previous version of Ruby available in Fedora to bootstrap Ruby.
But this does not work ATM, at least when RubyGems are installed. And
upstream is doing what they can to make RubyGems inseparable .
3) Prepare patches locally and apply the required changes also to the
pregenerated files. But the problem here is, that the patches might
unpredictably fail between updates. I don't think that they keep any
API/ABI promises for the tools used to generate those files.
4) Don't use the upstream tarball, but generate it from sources with
I think we should probably start to take look at 1), specifically into
the *miniruby* variant if that is enough. If that is done, the 2) could
optionally blend in. And in the mean time use 3) because otherwise I
really don't know how to integrate the ABRT hook support. I don't like
4) at all, unless we have some Fedora standardized way of doing so.
On the positive side, 1(2) would allow us to stay better in line with
"Pregenerated code" guidelines , because there is already quite a lot
of pre-generated code shipped in Ruby release tarball.
On 07. 12. 19 11:53, Henrique Castro wrote:
> Pymol is a package that, integrated with python-rdkit and other python packages,
> makes the lives of people working with drug discovery (and chemistry in general
> too) much easier. Unfortunately, the package is broken and not even build into
> F31. The maintainer has not replied to a BZ ticket open months ago.
> At this point, the absence of the package is realy making an impact in science
> made with Fedora.
Unfortunately, pymol needs an active maintainer. Since it is retired, any Fedora
packager can request it to be unretired and become the owner of it.