Re: [gentoo-dev] Re: Live source based ebuild proposals

[Luca Barbato]

Second step, shortcomings.

Luca Barbato wrote:
> main problem:
> - have the possibility to track upstream w/out having to take a manual
> snapshot of their sources, but having portage automatically fetch them
> from their tree.

This issue isn't and shouldn't something that touches directly our 
normal users, tracking upstream isn't something a common user would do 
for any software, upstream releases should be more than enough for 
normal usage.

Keyword here being "normal".

Additional concern from ferdy is the fact you may want to track multiple 
  branches/repos for a software and those do not have a version target.

Ciaranm pointed out already that for such cases you may rely on useflags 
  to switch between tip repos/branches. I'm not sure useflag should 
trigger slot changes (see discussions about binutils usage of useflags), 
but still that is a simple and clean enough solution for a quite small 
corner case.

Alternatively one could set a virtual and use different package names. 
This solution is uglier but I guess would be ok for an overlay.

> current situation:
> - we have some eclasses that on unpack phase fetch the sources from the
> upstream server, prepare them and then the usual ebuild process follows.
> - in order to make an ebuild using those eclasses be valued as the
> highest possible, the simplest solution had been give it a version "high
> enough", namely -9999. That makes simple track a single tree per package.
> - The same could be done with any version component in order to try to
> track multiple instances, so to track what will be the next 1.5 version,
> somebody could create an ebuild as 1.4.9999 or 1.5_pre9999, 9999 being
> an arbitrary big number.

The main issues so far:
- you have to hand produce "high enough" version values
- you cannot track what did you install since you don't have such 
information
   - you cannot do reemerge (useful for revdep rebuilds)
- in order to refresh them you need either to rely on script or on sets 
hand produced or heuristically defined ("all ebuilds that inherit eclass 
svn go in svn set").
- since you fetch on unpack phase you cannot use emerge -f consistently

> -scm proposal:
> - use a component version that makes whatever before it valued as "the
> highest within that component", likely -r or _p do, that includes the
> case "the highest version in absolute" in order to arbitrary decide an
> "high enough" value, namely -9999.
> - from what you can find in the glep, the change is apparently purely
> cosmetic beside the hinted but not expressed possibilities having
> portage fully aware those ebuild manage something "live" could give.

The issues so far:
- it makes the definition of "high enough number" and marks ebuilds as 
live but doesn't address the other issues
- the glep is quite implicit and doesn't tell enough
- it requires changes that aren't exactly low impact for almost no 
return, at least apparently since the glep doesn't tell enough.

[I hope that explains better why this proposal had been on hold for this 
long and why the main requirement to reconsider it had been to add more 
informations in the glep]

> live-properity proposal:
> - have a property to make portage aware that the ebuild is using live
> sources.
> - it doesn't add components to the ebuild version but just marks the
> ebuild. So this proposal aims to improve portage internal management but
> doesn't add or detract anything regarding version resolution.

The issue so far:
- it just solves the fact ebuilds aren't marked as "live" but doesn't 
address any of the other problems.
- it has little impact on portage but also gives a little in itself

[That makes this proposal interesting since you may build on it 
solutions to the other issues with low impact as well]

> live-template proposal:
> - you still have a new version component, in this case either ".live" or
> "_live", but in the template.
> - it isn't used directly in resolution but it generates automatically a
> normal version that get resolved as usual.
> - tries to make sure there is a way to get reproducible results
> regarding installed packages by embedding the informations to get again
> the same sources. So you can also re-emerge the very same package again
> you emerged it once since it has a defined version number.
> - tries to give developers willing to track upstream and then provide
> snapshots the ability to do that automatically.

The issue so far:
- it tries to scratches all the itches at the same time.
- it could be as invasive as the -scm proposal but tries to address 
every issue in order to make worthy doing such radical changes in one go.
- The proposal itself hasn't covered many implementation and usage 
details yet.

[What puzzles me is that some people claims you cannot do something with 
live templates while you can with -scm]

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero