1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
eselect-wine implementation notes
=================================
Just bit of ramblings, nothing interesting for most people here
unless want an overview to work on the module or rewrite again.
Ideas
-----
* ``/usr/bin`` wrappers:
- pros: mininal need for changes, and could select like python-exec
with ``/etc`` configs and/or env vars
- cons: we don't know what wrappers are needed, wine variants or
versions could use more binaries or less and become messy to handle,
plus still need to handle man pages and such
* ``PATH``/``MANPATH``/``XDG_DATA_DIRS``-based:
- pros: *mostly* no modifications needed bare normal ``/etc/env.d`` files
- cons: does not handle some still needed ``/usr`` links and users have to
``source /etc/profile`` every single updates(!) for new ``PATH``, also
``PATH`` use in general could become an issue if used by too many eselect
modules (not that it's so bad if just used by packages with many bins)
* ``/usr`` live symlinks/updates (legacy model):
- pros: no sourcing ``/etc/profile`` ever fwiw
- cons: requires some degree of safety to know what we can touch, so
former ``eselect-wine`` used a register/deregister model, hardcoded
known variants, and saved links in config files (error prone and
sometimes left users needing to manually fix it at times, modifying
live ``/usr`` is also often frowned upon and this overdid it)
* ``PATH``-based with ``/etc/eselect/wine/bin`` links (current):
- pros: no need to ``source /etc/profile`` more than once, and does not
modify ``/usr`` (``/usr/bin/wine`` link can be installed by the ebuild
for e.g. ``binfmt`` compat), ``/etc/eselect/wine`` can be deleted safely
and re-generated cleanly on a whim
- cons: sourcing ``/etc/profile`` once still requires informing users, and
implementation still a bit complex despite half+ size of the previous
Notable ebuild installation paths
---------------------------------
* ``usr/include/wine-<variant>-<version>`` (-> ``/usr/include/wine`` for compat)
* ``usr/lib/wine-<variant>-<version>``
- ``bin/`` (usable in ``PATH`` as-is, but will lack variant links)
- ``wine/`` (-> ``/usr/lib/wine`` for compat, albeit this one is not
typically needed given ``winebuild`` will find the right location)
* ``usr/share/wine-<variant>-<version>`` (usable as ``XDG_DATA_DIRS``)
- ``man/`` (usable in ``MANPATH``)
* ``usr/bin/*-<variant>-<version>`` (optional, not used *here* anymore)
Legacy ebuilds may split between ``usr/lib64`` and ``usr/lib``, i.e. rather than
have ``wine/{i386,x86_64}`` in ``/usr/lib/<slot>``, will be split as such:
* ``usr/lib/<slot>/wine/i386-windows``
* ``usr/lib64/<slot>/wine/x86_64-windows``
(not supported anymore, current eselect will warn they are being ignored)
If need to auto-detect installations, it is recommended to check if
``usr/lib/wine-*-[0-9]*/bin/wine`` exists and use the matching ``wine-*``
to look at other directories (variant name should not have ``-``).
Current implementation overview
-------------------------------
``eselect-wine`` ebuild's env.d adds ``/etc/eselect/wine/bin`` to ``PATH``,
and similar for ``MANPATH``/``XDG_DATA_DIRS`` which provides static
locations that will not need ``source /etc/profile`` every changes.
Can freely work on that directory, clean it up, add variants suffixes,
etc... without worrying about mangling ``/usr``.
Like previous implementation, still allows per-variant versioning, e.g.
* ``winecfg-vanilla`` -> ``/usr/bin/wine-vanilla-7.0`` (shell wrapper)
* ``winecfg-vanilla-7.0`` -> ``/usr/lib/wine-vanilla-7.0/bin/winecfg``
* ``winecfg`` -> ``/usr/bin/wine-vanilla-7.0`` (*could* be a symlink to ^)
Versioned wrappers like ``winecfg-vanilla-7.0`` are installed by Wine
ebuilds and can be modified *there* if any quirks need to be handled.
So, for consistency, calling the wrapper even for plain ``winecfg``.
Wrappers are needed because wine treats ``argv[0]`` specially. May be
workable around for a pure ``PATH`` solution, but would likely require
yet more ``eselect-wine`` compatibility code in ebuilds. Alternatively,
could consider removing variant link support altogether.
Originally wanted to not have a ``wine.conf`` and read links for the
previous slots and updates, but unless wrappers are in ``/usr/lib/<slot>``
that would be unreliable.
These aside, ``eselect-wine`` ebuild will have created ``/usr/bin/wine``,
``/usr/lib/wine``, and ``/usr/include/wine`` symlinks that points to
locations in ``/etc/eselect/wine``. This allows updating them without
modifying ``/usr`` directly. Would be possible to work without these
but may confuses some build systems and ``/usr/bin/wine`` is a typical
location for ``binfmt`` to look at.
``XDG_DATA_DIRS`` is not currently very useful (only one .desktop), but
would be relevant if want to move things back from ``wine-desktop-common``.
One issue about ``.desktop`` is that legacy eselect used to handle
``update-desktop-database``. Given it's now a private cache file only
created for Wine in ``/usr/share/<slot>/applications`` it may make more
sense to have ebuilds generate it in ``src_install()`` (tracked, allowing
cleanup and directory removal). Not that missing cache for 1 ``.desktop``
means much. Also, per-variant ``XDG_DATA_DIRS``/``.desktop`` is not handled
(aka only main is active), this would be messy as far as MimeTypes
priorities go anyway.
ebuilds only need to run a single ``eselect wine update --if-unset`` in
``src_postinst`` and ``src_postrm`` (yes **post** rm now), no registering
process.
Migration handling
------------------
Need some degree of compatibility with older ``eselect-wine`` given older
installed Wine ebuilds or those from overlays will call this in e.g.
``src_prerm()`` with old arguments (could sit there for years).
To complicate things, in ``prerm`` the files still exists and so we end up
auto-detecting them and not actually cleaning.
So, still recognize these:
* ``register``: no-op, return true
* ``deregister``: likewise
* ``update``: ignore e.g. ``--all``/``--vanilla`` arguments, some ebuilds
may end up updating twice until migrated but that's ok
``unset`` also existed, but to my knowledge only the ``eselect-wine`` ebuild
ever used this (``prerm``) and this should never be used with the new one.
``eselect-wine`` ebuild can handle calling the old one for most cleanups,
additionally ``active`` -> ``eselect-wine-migration`` is supported to attempt
to keep same slots selected. Users will need to ``source /etc/profile`` (once)
for ``PATH`` updates, but otherwise *should* see no negative impacts.
Support code for these can be cleaned up in 2025 or later, no urgency
albeit it will cleanup ``eselect wine help`` output and tidy the
``eselect-wine`` ebuild. Meanwhile Wine ebuilds are encouraged to ``IDEPEND``
on ``>=app-eselect/eselect-wine-2`` and drop deprecated usage.
Normally migration should be smooth, but there is no mechanism implemented
to cleanup ``/usr/bin`` and ``/usr/share/man`` with an old version's **broken**
``/etc/eselect/wine`` (e.g. missing data while links are still in ``/usr/bin``).
Searching for dead links may help if needed (e.g. ``find /usr/bin -xtype l``).
Fortunately, dead links are normally ignored in ``PATH`` and won't shadow.
Note downgrading ``eselect-wine`` after migrating is not very supported as it
requires re-registering each slots again manually. Re-upgrading should not
be an issue though.
|
GitWeb