Gentoo Archives: gentoo-dev

From: Francesco Riosa <vivo75@×××××.com>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds
Date: Wed, 28 Dec 2011 13:13:26
Message-Id: CAD6zcDzTL2LeEwe-DRyH7b=UqBm+7TJ1xMgz_Nb0zQiuzkuNnQ@mail.gmail.com
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.

Replies