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