1 |
Disclaimer: this is just one idea that come at lunch, and sharing (in |
2 |
a short pause before my demanding daughter request me) here to not |
3 |
forget in the next busy days. |
4 |
|
5 |
Seem to me that append a time slice to the function, in the name or as |
6 |
a parent function that call the underling function can solve most of |
7 |
the versioning/deprecation problems |
8 |
|
9 |
how could it work: |
10 |
|
11 |
1) package manager record the time it start an emerge "transaction", |
12 |
and share it via the environment with ebuilds and eclasses. The time |
13 |
could be faked by an argument via command line too. |
14 |
2) the bash functions which are "versioned" this way chose the right one |
15 |
3) package manager save the build time in the binpkg and in /var/db |
16 |
for unmergin and other purposes |
17 |
|
18 |
notice, the time must be a fixed one, the one @ which emerge @world |
19 |
start or a provided one, not a varying one alas gettimeofday() |
20 |
|
21 |
pro of this approach (in random order) |
22 |
- new function can be tested in tree faking a future date, no overlays |
23 |
needed, no masks, users and PM can see future changes sooner |
24 |
- automatic versioning, expired functions can be kept in eclass or |
25 |
ebuild for any chosen time with little waste |
26 |
- joining date of build and time versioned eclasses can make debugging easyer |
27 |
- in case user encounter a bug which has not been spotted/reported |
28 |
prior to the function activation become easy to fake a past date as |
29 |
emerge date and leave the developers the time to fix properly |
30 |
- future changes are defined in code, where everyone can see them |
31 |
|
32 |
cons |
33 |
- require package manager changes |
34 |
- must be done resilient to developer errors like overlapping slices of time |
35 |
|
36 |
toughs? |
37 |
Francesco R. |