On Thu, May 13, 2010 at 01:50:14PM -0500, Shawn Walker wrote: > I'm trying to allow the repository administrator to *optionally* > specify what publisher's data is being mirrored to assist clients in > configuration and/or validation in the future.
This seems out of scope, since we don't know what the future requirements for configuration validation may be. > Note that I didn't say you change the validate() check, etc. I'm > just wanting to change it so that *if* the administrator has > supplied the information, then assume it's valid. This is part of my concern. In the current model, administrators are required to supply a cfg_cache. So far as I can tell, they seem to copy / paste it from somewhere else. If this is the typical behavior, it would be sensible to generate something else by default, and only provide information if explicitly supplied by an administrator. We'd need to create an alternate configuration file in order to accomplish this, since we have no way of determining whether the cfg_cache was put there by someone trying to be careful, or by a quick/dirty cut paste. > I'm also not yet convinced that multi-publisher mirrors are the > common case. It seems like that would make change management (what > bits are available) difficult. Perhaps they're not common now, but the mDNS mirrors will have content from a variety of different sources. > I just want to ensure that the ability to use this potentially > valuable information (when correctly configured) isn't unnecessarily > precluded based on poorly configured repositories. Bad > configuration can always be troublesome. I agree in principle, but I think we're arguing about the nuts and bolts. > Yes, but my suggested change above doesn't preclude that. It does > empower the administrator in the single publisher case (which I > believe is the more common case for mirrors) to provide more useful > information to the client. I think that over time, single publisher mirrors are going to become less common. We've developed a variety of ideas about mirroring content, many of which contain data from multiple upstream sources. > Note that the client doesn't yet use this information, but I would > like it to be available so that it could be used if provided. I think that we will want the client to use this information. When it actually becomes possible to determine what publishers are being mirrored, I would imagine that we'd want to change the mirror discovery code to only include sources for publishers we're interested in downloading data from. Based upon the architecture we have right now, though, it's premature to add such a feature. > >>tests/ > >> Possible to add a simple unit test of some kind? > > I was thinking you could add a set of unit tests that simply return > successful if pybonjour couldn't be imported. Since PyBonjour isn't in the gate, and we have no guarantee that the mdns daemon is running, how about I write a test that enables mirror detection and verifies that the client can successfully complete an install. That should be sufficient to catch some breakage. -j _______________________________________________ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
