[gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds

[gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds

[Francesco Riosa]

Disclaimer: this is just one idea that come at lunch, and sharing (in
a short pause before my demanding daughter request me) here to not
forget in the next busy days.

Seem to me that append a time slice to the function, in the name or as
a parent function that call the underling function can solve most of
the versioning/deprecation problems

how could it work:

1) package manager record the time it start an emerge "transaction",
and share it via the environment with ebuilds and eclasses. The time
could be faked by an argument via command line too.
2) the bash functions which are "versioned" this way chose the right one
3) package manager save the build time in the binpkg and in /var/db
for unmergin and other purposes

notice, the time must be a fixed one, the one @ which emerge @world
start or a provided one, not a varying one alas  gettimeofday()

pro of this approach (in random order)
- new function can be tested in tree faking a future date, no overlays
needed, no masks, users and PM can see future changes sooner
- automatic versioning, expired functions can be kept in eclass or
ebuild for any chosen time with little waste
- joining date of build and time versioned eclasses can make debugging easyer
- in case user encounter a bug which has not been spotted/reported
prior to the function activation become easy to fake a past date as
emerge date and leave the developers the time to fix properly
- future changes are defined in code, where everyone can see them

cons
- require package manager changes
- must be done resilient to developer errors like overlapping slices of time

toughs?
Francesco R.

Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds

[Zac Medico]

On 12/28/2011 05:12 AM, Francesco Riosa wrote:
> Disclaimer: this is just one idea that come at lunch, and sharing (in
> a short pause before my demanding daughter request me) here to not
> forget in the next busy days.
> 
> Seem to me that append a time slice to the function, in the name or as
> a parent function that call the underling function can solve most of
> the versioning/deprecation problems
> 
> how could it work:
> 
> 1) package manager record the time it start an emerge "transaction",
> and share it via the environment with ebuilds and eclasses. The time
> could be faked by an argument via command line too.
> 2) the bash functions which are "versioned" this way chose the right one
> 3) package manager save the build time in the binpkg and in /var/db
> for unmergin and other purposes

You're idea is irrelevant for binary packages and unmerge of installed
packages, since they make use of environment.bz2 which contains a
snapshot of the eclass functions / environment from build time.
-- 
Thanks,
Zac

Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds

[Zac Medico]

On 12/28/2011 05:12 AM, Francesco Riosa wrote:
> Seem to me that append a time slice to the function, in the name or as
> a parent function that call the underling function can solve most of
> the versioning/deprecation problems

I've overheard Arfrever discussing a similar approach in funtoo's irc
channel, where the ebuild would set a variable prior to inherit if it
wants to use a specific eclass API. For the python eclass, he's planning
to have ebuilds set the PYTHON_ECLASS_API variable to use the new API.
When the variable is unset, the eclass will default to the older API.
-- 
Thanks,
Zac

Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds

[Francesco Riosa]

2011/12/28 Zac Medico <zmedico@gentoo.org>:
> On 12/28/2011 05:12 AM, Francesco Riosa wrote:
>> Disclaimer: this is just one idea that come at lunch, and sharing (in
>> a short pause before my demanding daughter request me) here to not
>> forget in the next busy days.
>>
>> Seem to me that append a time slice to the function, in the name or as
>> a parent function that call the underling function can solve most of
>> the versioning/deprecation problems
>>
>> how could it work:
>>
>> 1) package manager record the time it start an emerge "transaction",
>> and share it via the environment with ebuilds and eclasses. The time
>> could be faked by an argument via command line too.
>> 2) the bash functions which are "versioned" this way chose the right one
>> 3) package manager save the build time in the binpkg and in /var/db
>> for unmergin and other purposes
>
> You're idea is irrelevant for binary packages and unmerge of installed
> packages, since they make use of environment.bz2 which contains a
> snapshot of the eclass functions / environment from build time.
>
The environment would contain all the versioned functions but it will
also contain the timestamp of the original merge possibly solving the
dilemma

Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds

[Francesco Riosa]

2011/12/28 Zac Medico <zmedico@gentoo.org>:
> On 12/28/2011 05:12 AM, Francesco Riosa wrote:
>> Seem to me that append a time slice to the function, in the name or as
>> a parent function that call the underling function can solve most of
>> the versioning/deprecation problems
>
> I've overheard Arfrever discussing a similar approach in funtoo's irc
> channel, where the ebuild would set a variable prior to inherit if it
> wants to use a specific eclass API. For the python eclass, he's planning
> to have ebuilds set the PYTHON_ECLASS_API variable to use the new API.
> When the variable is unset, the eclass will default to the older API.

There is a fundamental difference, with "timeslices" it's not the
ebuild that select the implementation but the point in time it's used,
or the user forcing a fake time. From what I've read Artfever approach
require changes in every ebuild and keeping old functions forever. On
the other hand it may be risky to change the preferred interface from
the eclass and not the ebuild.

Thanks for reviewing,
Francesco

Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds

[Brian Harring]

On Thu, Dec 29, 2011 at 02:37:07AM +0000, Francesco Riosa wrote:
> 2011/12/28 Zac Medico <zmedico@gentoo.org>:
> > On 12/28/2011 05:12 AM, Francesco Riosa wrote:
> >> Seem to me that append a time slice to the function, in the name or as
> >> a parent function that call the underling function can solve most of
> >> the versioning/deprecation problems
> >
> > I've overheard Arfrever discussing a similar approach in funtoo's irc
> > channel, where the ebuild would set a variable prior to inherit if it
> > wants to use a specific eclass API. For the python eclass, he's planning
> > to have ebuilds set the PYTHON_ECLASS_API variable to use the new API.
> > When the variable is unset, the eclass will default to the older API.
> 
> There is a fundamental difference, with "timeslices" it's not the
> ebuild that select the implementation but the point in time it's used,
> or the user forcing a fake time. From what I've read Artfever approach
> require changes in every ebuild and keeping old functions forever. On
> the other hand it may be risky to change the preferred interface from
> the eclass and not the ebuild.

Respectfully, the proposals thus far (including python eclass bit) are 
going in the opposite direction of maintainability, simplicity, 
robustness.

People have problems as is dealing w/ eclasses changing and their 
dependencies in external repositories not being updated; this 
complicates that issue and introduces the same potential into 
gentoo-x86 itself.  That's not beneficial.

Thing to keep in mind beyond the potential for confusion the proposals 
entail were they implemented, is the implementation itself.  
Timeslices?  python eclass api versions (when people have problems 
figuring out the existing, *singular* version)?  These things aren't 
going to be simple which means more than likely, they're going to 
break, and more than likely it's going to be a PITA to maintain it.

Per the norm, I could be wrong, but reading these proposals, they 
really feel like they need to revisit the notion of 
maintainability/robustness as an actual full fledged implementation, 
beyond the (admittedly semi nifty) notion of versioned apis.

My 2 cents, hopefully not at my usual offensive level-
~harring

Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds

[Francesco Riosa]

2011/12/29 Brian Harring <ferringb@gmail.com>:
> On Thu, Dec 29, 2011 at 02:37:07AM +0000, Francesco Riosa wrote:
>> 2011/12/28 Zac Medico <zmedico@gentoo.org>:
>> > On 12/28/2011 05:12 AM, Francesco Riosa wrote:
>> >> Seem to me that append a time slice to the function, in the name or as
>> >> a parent function that call the underling function can solve most of
>> >> the versioning/deprecation problems
>> >
>> > I've overheard Arfrever discussing a similar approach in funtoo's irc
>> > channel, where the ebuild would set a variable prior to inherit if it
>> > wants to use a specific eclass API. For the python eclass, he's planning
>> > to have ebuilds set the PYTHON_ECLASS_API variable to use the new API.
>> > When the variable is unset, the eclass will default to the older API.
>>
>> There is a fundamental difference, with "timeslices" it's not the
>> ebuild that select the implementation but the point in time it's used,
>> or the user forcing a fake time. From what I've read Artfever approach
>> require changes in every ebuild and keeping old functions forever. On
>> the other hand it may be risky to change the preferred interface from
>> the eclass and not the ebuild.
>
> Respectfully, the proposals thus far (including python eclass bit) are
> going in the opposite direction of maintainability, simplicity,
> robustness.
>
> People have problems as is dealing w/ eclasses changing and their
> dependencies in external repositories not being updated; this
> complicates that issue and introduces the same potential into
> gentoo-x86 itself.  That's not beneficial.
>
> Thing to keep in mind beyond the potential for confusion the proposals
> entail were they implemented, is the implementation itself.
> Timeslices?  python eclass api versions (when people have problems
> figuring out the existing, *singular* version)?  These things aren't
> going to be simple which means more than likely, they're going to
> break, and more than likely it's going to be a PITA to maintain it.
>
> Per the norm, I could be wrong, but reading these proposals, they
> really feel like they need to revisit the notion of
> maintainability/robustness as an actual full fledged implementation,
> beyond the (admittedly semi nifty) notion of versioned apis.
>
> My 2 cents, hopefully not at my usual offensive level-
> ~harring
>
yeah, after a good sleep the problems of this approach are more clear,
it's a pity, it seemed really bright while eating my spaghetti.

Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds

[Jeroen Roovers]

On Wed, 28 Dec 2011 19:36:01 -0800
Brian Harring <ferringb@gmail.com> wrote:

> People have problems as is dealing w/ eclasses changing and their 
> dependencies in external repositories not being updated; this 
> complicates that issue and introduces the same potential into 
> gentoo-x86 itself.  That's not beneficial.

I agree with nearly all of that: introducing changes to an eclass
usually means going through the whole tree and fixing what breaks.
That's a lot more easy to fix than adding more layers of indirection
based on a variable's value and adjusting the value according to the
time the ebuild was written versus when the eclass was changed.

> Thing to keep in mind beyond the potential for confusion the
> proposals entail were they implemented, is the implementation
> itself. Timeslices?  python eclass api versions (when people have
> problems figuring out the existing, *singular* version)?  These
> things aren't going to be simple which means more than likely,
> they're going to break, and more than likely it's going to be a PITA
> to maintain it.

Last time I took tranquilisers and set myself up to read python.eclass,
I found that it still doesn't break at 80 characters. Apparently even
that can't be fixed in a timely fashion.

Assing even more layers of mystification like:

if [[ PYTHON_ECLASS_API = 2 ]]; then
	python_pkg_setup() {

or even:

python_pkg_setup() {
	if [[ PYTHON_ECLASS_API = 2 ]]; then

would be insane, in my opinion.

Also, from the perspective of an ebuild writer, setting

PYTHON_ECLASS_API=2
inherit python

would be meaningless lacking a very clear description of what the
number 2 means.


     jer