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
pgplAcDF68Uhj.pgp
Description: PGP signature
