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
