Re: [gentoo-dev] One-Day Gentoo Council Reminder for June

[Brian Harring]

On Thu, Jun 12, 2008 at 10:09:43AM -0700, Donnie Berkholz wrote:
> On 04:11 Wed 11 Jun     , Brian Harring wrote:
> > if the running of it satisfys the councils requirements of a *neutral*
> > standard, if the proposed spec actually meets said standards,
>
> Anyone working on a package manager (and anyone else suitably
> knowledgeable) should be able to get commit access to it. The only
> person "running" it is doing so by virtue of making the most commits.

Person 'running' it is the one w/ commit control; as far as I know, 
that's ciaran and halcy0n (latter being inactive from what I've seen).


> > Effectively, we've watched it essentially progress into a standard
> > that effectively only the paludis folk are adherent to (if in doubt,
> > ask portage folk, my sending this mail is indicative of the pkgcore
> > standpoint)- it's about time the council comment upon it in light of
> > the general view.
>
> I'd like to know what's holding you back from contributing to it,
> instead of telling us that someone else is doing things you don't like.
> Is there some kind of technical barrier (like the TeX)? Or what? Are you
> filing bugs against the parts you don't like? What's happening to them?

Duncan's recent post,
http://archives.gentoo.org/gentoo-dev/msg_3baa8ff0b7d3a65206ddaefa7cc4a346.xml
actually lays out some of the issues fairly succinctly.  What he 
doesn't state outright (and I shall) is that when bound by a standards 
group actively hostile to your manager/involvement, the 'dog and pony 
show' duncan refers to becomes far worse, and typically nastier.

It becomes far less worth being involved additionally, if it's known 
up front it's going to be flaming.

Meanwhile, couple of technical faults ignored either for paludis 
benefit, or (best I can figure) because I brought it up.

1) http://bugs.gentoo.org/show_bug.cgi?id=171291
metadata/cache (hence labeled flat_list cache format) mtime 
requirements.

This actually is a fairly old issue- I raised it when pms was first 
finally shown to people.  Basically issue is that for flat_list cache 
format, the cache entries mtime is the ebuilds mtime.  This was used 
to try and detect stale cache entries via comparing ebuild mtime- 
doesn't handle eclass related invalidation, but that is a seperate 
issue.

Current spec intentionally leaves out mtime, no mention of it.  Why 
this matters- paludis's implementation of flat_list (hence labeled 
paludis_flat_list) differs- instead of the historical cache mtime == 
ebuild mtime, it's cache mtime == max(ebuild mtime, eclasses mtimes).

Personally, I don't care about their cache implementation on disk, as 
long as it doesn't affect me - it's their way of addressing what 
flat_hash for portage/pkgcore addresses, full eclass staleness 
detection.  Fair enough.

What *does* matter is that via this omission in PMS, paludis_flat_list 
is considered a valid cache for $PORTDIR/metadata/cache.  Using 
paludis_flat_list as $PORTDIR/metadata/cache means that 
pkgcore/paludis identify the cache as stale, and regenerate it.  In 
other words, flat_list works with portage/pkgcore/paludis, 
paludis_flat_list works with paludis only (triggering invalid 
regeneration for the rest).

It may seem minor, but think through the response when a 
portage/pkgcore user hits a repository generated by paludis- 
"pkgcore/portage are broke, not our fault" due to PMS omission of 
historical behaviour.

Issue is known, and ignored at this point.


2) http://bugs.gentoo.org/show_bug.cgi?id=196561; changing (within 
eapi0) the behaviour of ~ operator.  Currently, portage ignores any 
revision for ~, pkgcore gives the finger if you try combining ~ with a 
revision (it's not a valid atom), paludis follows the PMS rules;

long term behaviour of ~; any revision of this version suffices.
PMS/paludis behaviour: revisions greater then, or equal to this 
  revision, equal to this version.

Why this matters; portage long term behaviour has been to drop -r* 
when found.  Parsing is/was loose, basically.  Due to eapi0's nature, 
one can't just force in what they think is the one true way, have to 
force in what works for all and matches history.

Issue is known, and ignored at this point.


3) good 'ole mr -r0 and the issues it triggers,
http://bugs.gentoo.org/show_bug.cgi?id=215403
initial dev thread,
http://archives.gentoo.org/gentoo-dev/msg_de84ebd5116546518879e266bf60f32b.xml
relevant flaws ignoring this issue induces:
http://archives.gentoo.org/gentoo-dev/msg_f98bab69d67bd4132917be0eb04e8f3e.xml

Spawned by a rather odd commit from rbrown flushing out a user visible 
breakage for pkgcore users, it also flushed out PM incompatibilities 
in handling of PVR/PR; specifically since -r0 has *never* been used in 
ebuild names, all ebuilds have been written assuming PVR lacks -r0.  
What was the end result of this rather obnoxious (ebuild dev viewable) 
variance?

Accusations that pkgcore devs are trying to legislate away their 
'bugs' (ignoring that the issue was fixed/released about the same time 
as the accusation) while ignoring the issue in the spec.

This obviously benefits the spec, although I'm not smart enough to see 
how...


Note these are just the issues from memory atm.  I say memory since as 
long as I've audited PMS, pointing out issues has basically been 
intentionally stepping in front of the firing line.

Hell, getting access to the damn thing required a fairly large amount 
of BS/insults-
http://article.gmane.org/gmane.linux.gentoo.devel/46163

Which was ignored (despite council backing it at the time), resulting 
in
http://article.gmane.org/gmane.linux.gentoo.devel/46417 .


Essentially, what the last year/half of dealing w/ pms is culminating 
in, is an ongoing buildup of reasons to *not* deal with the current 
folk in control, end result being not dealing with pms.  Shitty 
scenario actually; either willingly get kicked in the shins, or ignore 
it (thus ceding a voice in the format directly influencing your work).

If that actually were to change, meaning <all> folks could point out 
flaws, interact w/ the controllers w/out getting their nuts blown 
off, generally actually accomplish something other then being 
taunted, yes, I'd be more then willing to reaudit the bugger and take 
another stab at it.

As it is however, contributing to it is effectively blocked by the 
folks involved- and actual interaction w/ it serves only as a hammer 
to beat on pkgcore with.

To be clear; while I don't relish interacting w/ ciaran and co., I'm a 
damned adult and willing to deal w/ folk I don't like.  What I'm 
unwilling to do however is be in the situation where I'm forced to 
contribute to folk who are after baiting; it's just a waste of time, 
simple as that, and it in no way benefits gentoo.

~harring