forked from gofed/gofed
-
Notifications
You must be signed in to change notification settings - Fork 0
/
PACKAGING_STATUS
45 lines (37 loc) · 2.05 KB
/
PACKAGING_STATUS
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
====Open problems====
##########################################
# [1] - back-compatibility among updates #
##########################################
====Problem description====
In general tools can depend on different commits of the same dependency
(upstream project). If those commits are not back-compatible with each other,
problems arise:
- we have to package all those commits in order to be able to built every tool
- we have to do this for every branch (5 at the moment)
- developer usually use "go get" to install the latest source codes (which
commit it is?; should we force a list of commits of each deps for each pkg?)
- we need latest commits because of kubernetes and other tools being under
heavy development (unused subpackages should be deleted; which are used?)
- we have to keep a number of subpackage as low as possible otherwise we end
with a packaging nightmare. Having 10 subpackages for one package for all 5
branches ends with 50 builds. Each branch can require different commits.
With security patch we have to fix up to 50 subpackages.
- if we subpackage each commit, how many subpackages are we going to have? In
order to minimize this number, we will need a way how to determine which
symbols are used from each package (not trivial).
- name convention for subpackages? Prefix or sufix all subpackages with
a commit?
====Suggested solution====
Bundle all dependencies breaking back-compatibility
====Notes====
- If different commits of the dependency are subpackaged, maintainer has to fix
all subpackages on his own. On the other hand if they are bundlel in each
tool, responsibility for fixing is broken up between each maintainer.
At the end we still have the same number of [sub]packages to be fixed.
- devel subpackages are used only for building, not developing. Thus we can not
guarantee update/upgrade path. Or when you update/upgrade, you can replace
your source codes with back-incopattible ones.
##################################
# [2] - vendored vs dependencies #
##################################
====Problem description====