PJ Eby writes: > By "clear", I mean "free of prior assumptions".
Ah, well, I guess I've just run into a personal limitation. I can't imagine thinking that is "free of prior assumptions". Not my own<wink/>, and not by others, either. So, unfortunately, I was left with the conventional opposition in thinking: "clear" vs. "muddy". That impression was only strengthened by the phrase "vs. simply copying fields from distro tools." > Put together, the phrase "clear thinking on concrete use cases" means > (at least to me), "dropping all preconceptions of the existing design > and starting over from square one, to ask how best the problem may be > solved, using specific examples as a guide rather than using > generalities." Sure, but ISTM that's the opposite of what you've actually been doing, at least in terms of contributing to my understanding. One obstacle to discussion you have contributed to overcoming in my thinking is the big generality that the packager (ie, the person writing the metadata) is in a position to recommend "good behavior" to the installation tool, vs. being in a position to point out "relevant considerations" for users and tools installing the packager's product. Until that generality is formulated and expressed, it's very difficult to see why the examples and particular solutions to use cases that various proponents have described fail to address some real problems. It was difficult for me to see, at first, what distinction was actually being made. Specifically, I thought that the question about "Obsoletes" vs. "Obsoleted-By" was about which package should be considered authoritative about obsolescence. That is a reasonable distinction for that particular discussion, but there is a deeper, and general, principle behind that. Namely, "metadata is descriptive, not prescriptive." Of course once one understands that principle, the names of the fields don't matter so much, but it is helpful for "naive" users of the metadata if the field names strongly connote description of the package rather than behavior of the tool. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
