Re: [gentoo-dev] Re: adding a modification timestamp to the installed pkgs database (vdb)
On Sun, Jan 17, 2010 at 11:09:07AM +, Ciaran McCreesh wrote: 2010/1/17 Christian Faulhammer fa...@gentoo.org: Ciaran McCreesh ciaran.mccre...@googlemail.com: As much as you love to have the new and shiny VDB2, it is far off. Prototyping and drafting implementations would be great to have some base where we can discuss on (in a civil manner). So having this timestamp would be a good way to prepare a sane migration path. No, it wouldn't. Brian's proposal a) would be of no use whatsoever for VDB2 migration, and b) would not be used by VDB2. Having a *decent* cache validation mechanism is a good idea; having a half-baked one is a waste of time. Propose something, or shut up frankly. If all you're going to contribute is it's half baked claims, you're wasting folks time. You've had a couple of months of time to counterpropose something- back it up with a proposal or be silent please. As is, quite a few folk see how experimental vdb2/vdb1 synchronization can be done w/ this timestamp- your claims thus far that it won't work seem to boil down to but not everyone will update the timestamp. Which gets right back to why I'm elevating this to the council to *force* PMS to include this, thus force the holdout (paludis) to update the timestamp thus invalidating your cyclical claim. Either way, you find issues w/ the proposal you're more then free to propose something else- hell, I'll even listen if it's sane. What I won't do is sit around and listen to you whinge about the sky falling or that I/others are being idiots via not going the route *you* want and standardizing caches across all the managers- as I said, you want that functionality *you* propose it. About the only thing paludis shares w/ portage/pkgcore is a potential installed-pkgs-cache of pkg names; this isn't incredibly useful frankly (it's nice for cold cache searches but that's it). The cache usage between portage/pkgcore vs paludis differs a fair bit, as such trying to define an LCD vdb cache is pointless. Further it's not what I'm after and you've already opposed adding caches to vdb1 w/in the ticket- you want something beyond this, then go nuts. Either way, that's pretty much the bar I'm sitting for continuing discussion of this w/ you- either it's going to be productive w/ specific claims (no more of this vague handwaving bullshit) and moving towards accomplishing something or I'm just going to continue ignoring your disruptive behaviour, instead getting majority PMS consensus and then pushing it up to the council bypassing your shenanigans. It's not how things should be done, but it's about the only way to get something done when you dig in and go cyclical. Wish it weren't that way, but I've more interest in progress then playing games w/ folk looking to be poisonous. Seriously, if you can't even be bothered to spell out your claims in full or layout a counter proposal, instead spending your time screaming nyah nyah it won't work! as you did for prefix, I'm not having it. There are better uses of folks time frankly, and users deserve functionality over daft pissing matches. Be productive and constructive, or be ignored pretty much. ~harring pgpTniK4TKPAj.pgp Description: PGP signature
Re: [gentoo-dev] Re: adding a modification timestamp to the installed pkgs database (vdb)
2010/1/18 Brian Harring ferri...@gmail.com: Propose something, or shut up frankly. I propose we don't do anything until someone comes up with a decent cache proposal. If all you're going to contribute is it's half baked claims, you're wasting folks time. You've had a couple of months of time to counterpropose something- back it up with a proposal or be silent please. Doing nothing is better than doing something useless. As is, quite a few folk see how experimental vdb2/vdb1 synchronization can be done w/ this timestamp- your claims thus far that it won't work seem to boil down to but not everyone will update the timestamp. Er, no. It comes down to VDB2 implementing things that VDB1 doesn't support, such as having multiple installed slots of the same cat/pkg-ver, thus making it impossible to have both VDB1 and VDB2 at the same time. I have never argued against this proposal because not everyone will update the timestamp. That's an argument you've made up and attributed to me. Which gets right back to why I'm elevating this to the council to *force* PMS to include this, thus force the holdout (paludis) to update the timestamp thus invalidating your cyclical claim. PMS doesn't mention VDB at all. You're barking up the wrong tree. If you want me to include it in Paludis, all you have to do is come up with a proposal that does everything we need, rather than a proposal that can't legally be used for anything at all. What I won't do is sit around and listen to you whinge about the sky falling or that I/others are being idiots via not going the route *you* want and standardizing caches across all the managers- as I said, you want that functionality *you* propose it. I propose that rather than implementing a half-baked cache that isn't usable for anything, we do nothing until someone does come up with a full, unified cache proposal, where the validity of caches after operations is well defined. It's not how things should be done, but it's about the only way to get something done when you dig in and go cyclical. Cyclical on what? Explain where there is a cycle anywhere. You keep claiming I go cyclical, but never point out any actual cycles. It's what you fall back on when you don't have an argument. Wish it weren't that way, but I've more interest in progress then playing games w/ folk looking to be poisonous. And again, the whole poisonous thing. It's the last resort of those who are themselves the poison. How is wanting to do nothing until something can be done properly, rather than doing something that doesn't solve anything, poisonous? Seriously, if you can't even be bothered to spell out your claims in full or layout a counter proposal, instead spending your time screaming nyah nyah it won't work! as you did for prefix, I'm not having it. Uh, I already did, several times, and you ignored me, snipped them out and said I was going cyclical. I'll also point out that I raised a long list of things that were wrong with Prefix way back when it all started, and over the past few months everyone has finally realised that that list was full of legitimate concerns that are just now being addressed. Is it going to take you five years to see how I'm right here too? And how much more damage are you going to do to Gentoo before you admit that, as with Prefix, I've thought this through properly and you're just rushing along with the first thing that popped into your head? So, for you to ignore yet again: * The proposal does not define exactly what the validity of a cache is. You are sort of implicitly assuming that the validity of a cache is a function exclusively of the VDB not being modified, for some undefined value of not being modified, but nowhere are you stating concretely what the rules are. * You are addressing *only* VDB validity, rather than doing validity of all repositories at the same time. * There is no granularity to the proposal. There is simply an ill-defined modified rule, with no way for a package manager to know what was modified or by whom. * You aren't doing anything to fix the zillions of different caches that package managers have to use. There are better uses of folks time frankly, and users deserve functionality over daft pissing matches. Then give them a functional, shared cache, not a cache that can't legally be used for anything. -- Ciaran McCreesh
Re: [gentoo-dev] Re: adding a modification timestamp to the installed pkgs database (vdb)
2010/1/17 Christian Faulhammer fa...@gentoo.org: Ciaran McCreesh ciaran.mccre...@googlemail.com: As much as you love to have the new and shiny VDB2, it is far off. Prototyping and drafting implementations would be great to have some base where we can discuss on (in a civil manner). So having this timestamp would be a good way to prepare a sane migration path. No, it wouldn't. Brian's proposal a) would be of no use whatsoever for VDB2 migration, and b) would not be used by VDB2. Having a *decent* cache validation mechanism is a good idea; having a half-baked one is a waste of time. -- Ciaran McCreesh
[gentoo-dev] Re: adding a modification timestamp to the installed pkgs database (vdb)
Brian Harring wrote: The proposal is pretty simple; if code modifies the vdb in any fashion, it needs to update the mtime on a file named '.modification_time' in the root of the vdb. I'd to prefer using the mtime of the /var/db/pkg directory itself, since existence of a '.modification_time' file isn't going to prove that an programs that don't recognize that file haven't made any modifications. We can also use the mtimes of category subdirectories, in order to indicate whether a modification has occurred in any given category. -- Thanks, Zac
[gentoo-dev] Re: adding a modification timestamp to the installed pkgs database (vdb)
On Tue, Oct 27, 2009 at 11:32:30AM -0700, Zac Medico wrote: Brian Harring wrote: The proposal is pretty simple; if code modifies the vdb in any fashion, it needs to update the mtime on a file named '.modification_time' in the root of the vdb. I'd to prefer using the mtime of the /var/db/pkg directory itself, since existence of a '.modification_time' file isn't going to prove that an programs that don't recognize that file haven't made any modifications. Grumble. Works for me. We can also use the mtimes of category subdirectories, in order to indicate whether a modification has occurred in any given category. Pkgcore already relies on that for old style virtuals cache. The pisser there is that modifications w/in a node don't result in a category level mtime- it certainly would be nice to have it formalized in some fashion so that cache regeneration could just work on the areas it needs to. ~brian pgphkBO4EE29C.pgp Description: PGP signature
