1 |
On Thu, Nov 24, 2022 at 01:32:04AM +0000, Alexey Sokolov wrote: |
2 |
> > However, I tend to agree that the category should be named app-meta |
3 |
> > rather than sys-meta, because chances are that non-system packages will |
4 |
> > also make use of it. |
5 |
> > |
6 |
> > Ulrich |
7 |
> |
8 |
> Since these packages manage symlinks, make it app-symlink? |
9 |
|
10 |
Mentioned this in another post, but this is limiting what would make |
11 |
sense to be in there further. |
12 |
|
13 |
app -> what if it's library alternatives? |
14 |
symlink -> what if we need to use wrappers or some other solution? |
15 |
|
16 |
Not that we ever really match categories perfectly either way, but |
17 |
may as well stay generic rather than mismatch or create multiple |
18 |
sub-types. |
19 |
|
20 |
Some random ideas I had were 'alternatives', 'meta', 'select' |
21 |
'select-meta', not that I thought much about it. |
22 |
|
23 |
'meta' would essentially be like an entirely generic 'virtual' but |
24 |
just without PMS restrictions. While the ones with alternatives or |
25 |
select are more descriptive of what it's for without saying anything |
26 |
about how we're doing it or for what type of package. |
27 |
-- |
28 |
ionen |