On Mon, Jan 13, 2014, Alexander Berntsen wrote:
> > Updating both in parallel isn't hard: once pkgcore is up to EAPI-5,
> > EAPI-6 isn't that much work (mostly bash afair.)
> If it is trivial: show us the code.
Ah that old canard. Tell you what: I hereby undertake to deliver
everything currently listed at [1] for pkgcore, once radhermit has
declared he's done on his round of work with pkgcore internals and
it's up to EAPI-5, as tested against ebuilds, ferringb has approved it,
and its portage formatter is good enough for update[2] to use it again,
on EAPI-5 ebuilds.
Sorry the latter is why I care, and I've always pushed for it, so
whether that annoys anyone else is not my problem. I will be involved
in testing that aspect, obviously, and may need to patch update for
other interactions with pmerge, so that will come first.
I will deliver that within a calendar month, or 30 days, of the above
happening, for QA and acceptance-testing, unless ferringb, radhermit
or dol-sen veto it, preferably in #pkgcore but see disclaimer at end.
To avoid confusion, in case more is added, I'll list them, so you can
hold me to my word later:
bash 4.2 #431340
nonfatal die #451938 -- truly lame to do this via a new func, imo
reads like working round the PMS, which /is/ insane. static libs in
/usr is nothing on that, when you think about it.
get_libdir #463586 Used in econf, but so far not available as
separate PM function
Doc install function (edocs) #459692
Allow DOCS="" #463736
Directory support for DOCS #481980
Query function for IUSE #449862
in addition, query IUSE_EFFECTIVE -- from [3] this is what should
be queried?
PATCHES support in default src_prepare #463692
Unpack .txz #458102
Case-fold extensions in unpack #476730
unpack() accept absolute paths #483244
epatch_user - a sane implementation as we discussed 2 years ago or so
Source eclasses only once #422533 -- amended at [4]
EJOBS #273101 - emake integration -- for other languages or build-
systems, the eclasses would have to handle it. They are not part
of the PM/ebuild.sh, so out of scope. (There is a qm as to whether
this is still desired 4 years later.)
non-bash, but i'll provide support script as and if req'd:
HDEPEND #317337 -- CHOST dependencies req at build-time (yaf way
of adding a borked LDEPEND if you ask me, but w/e.)
I won't do failglob (#463822) as it will make everyone's life a lot
harder in the long run, and turn off anyone who actually has real BASH
experience. AFAIC we want them in the same way as we want expert
pythonistas. I'll happily add Kent's idea though, at least for this
setting; he's a guy you should all listen to a lot more, imnsho.
I'd do it like this:
failglob will apply to the function it appears in, and any callee
functions, and must be paired with reglob (or w/e) to restore, which
will also restore a nullglob invocation. (reglob must be called
on all return paths before function return, if you're doing something
complex. Most functions won't be though, ime.)
If ferringb and radhermit are ok with it, I'll implement it. If not,
it'll be trivial to import the crappy version from portage.
> > At that point, put portage into feature-freeze, and only bugfix it.
> > Call a hiatus on new EAPIs for 6 months and put all effort into
> > making damn sure pkgcore is a drop-in replacement.
> I don't see this happening as it stands right now. Let's revisit this
> when pkgcore is more up to date.
Yes, "at that point".
Now you may think I'm talking before I can implement, what I accused
someone else of; feel free to. Those are mostly trivial to a BASH
scripter, and I write (and throw away) more complex things practically
every day.
See [2] if you need verification, though it's not a work-project any
more, and was never meant to be when I started it as a training
assignment. We do use it at work though, so I get to maintain it.
And there is no way we could have done the ABI /etc/warning stuff, if
we hadn't had pkgcore to test resolves with. portage was just too slow,
when we were paired and needed to flow, to implement quite major
stuff in hindsight; ferringb even mentioned a need for exactly that
sort of mechanism in Gentoo, on the list last feb/mar i think it was,
when I was on hiatus. I remember being annoyed I'd missed the
discussion when I got back to FLOSS stuff.
Porcelain and plumbing.
Feel free to step up and pitch in too. The more the merrier, and the
lighter the load. Note there are queries on some of the above, and
no clear definition of what EAPI 6 is yet. So once you've made your
minds up about that, then you can start asking for your users to
implement it, I'd think. After all, devs are users too, and we've
all got other things to do.
TTFN,
steveL.
Disclaimer: I don't speak for pkgcore, or any of the people mentioned,
nor have I discussed any of this with them, so it's their call, now or
when they get to that stage. I'm just answering the "put your code where
your mouth is" point.
I did that several years ago with ebuild.sh but it only ended in being
told that the rewrite I was asked to step up with, should be a series
of patches, for "policy" reasons, so I gave up in disgust (the whole
point of a rewrite is a clean codebase that does the same thing, which
is what tests are for.) Life's way too short, for contributing to a
project that's going to do that to my time. *shrug* you live and learn.
[1] http://wiki.gentoo.org/wiki/Future_EAPI/EAPI_6_tentative_features
[2] http://weaver.gentooexperimental.org/update.html
yes i know it should be split into more files; a) I wanted to see
when bash would blow up on my old 32-bit install, and b) I just
want it to work ;) and have other things to do.
[3] http://www.gossamer-threads.com/lists/gentoo/dev/260812#260812
[4] http://marc.info/?l=gentoo-dev&m=134493783816587&w=2
--
"Daddy, Mommy: what did you do in the Eco-Wars?"
