1 |
Hi all, |
2 |
|
3 |
As I was the one wanting amd64-fbsd profiles 'stable' to ensure a sane |
4 |
deptree, and seeing the number of (re)keywording bugs growing and |
5 |
growing while I don't have time to process them and no-one else is doing |
6 |
it, I just switched them to 'dev' state. |
7 |
|
8 |
For users, this means they can no longer expect packages to have a |
9 |
correct dependency tree with ~amd64-fbsd keywords: packages can now |
10 |
have missing optional, or even mandatory, deps making them |
11 |
uninstallable in some cases. |
12 |
|
13 |
For developers, this means broken dependencies for amd64-fbsd changed |
14 |
from a repoman error to an optional warning; meaning that in most cases |
15 |
developers won't even notice their package has broken deps on this arch. |
16 |
|
17 |
While I don't think there is any general rule, what I would recommend |
18 |
is the following: |
19 |
- If you have a package whose amd64-fbsd keywords have been dropped |
20 |
between version N and N+1, keep version N in tree as long as it does |
21 |
not annoy you, then drop it. |
22 |
- If you introduce a new version that would create a broken deptree |
23 |
(and run repoman -d to notice it), keep ~amd64-fbsd keywords if the |
24 |
missing dep is optional, drop keywords otherwise. |
25 |
- Since, from my experience, most developers will not even notice |
26 |
broken deps on amd64-fbsd, filling (re)keywording bugs for amd64-fbsd |
27 |
is optional. Anyone wanting to restore its "stable" state will have |
28 |
to run a full check on the entire tree anyway. |
29 |
|
30 |
If anyone is interested in taking over the arch and restoring its |
31 |
"stable" status, you are very welcome, but for now it is just |
32 |
annoying more and more fellow developers in this state. |
33 |
|
34 |
Best regards, |
35 |
|
36 |
Alexis. |