On Thu, Mar 22, 2007 at 01:17:17AM +0100, Pierre Habouzit wrote: > > In the original proposal, 'current' was the flag to tell the packaging tools > > that pyversions -d *should* be used. There is of course nothing that stops > > a maintainer from invoking pyversions -d manually;
> Okay I see. As a coder, I don't like it then, and I feel reinforced in > my gut dislike of that field. "current" is declarative, and does not > says anything about what the packager really put in his debian/rules. That's fine. I'm not wedded to the, ah, "current" implementation; my concern is that it not be gutted from the policy because of concerns about the implementation, instead of finding a non-buggy solution. > If he does not writes what has to be to multi-build the package, and > that he does not puts current, well, the package basically will only be > built for current. And in that case, do all of the helpers correctly calculate the Provides based on the contents of the binary packages? > And as a matter of a fact, maintainers do not seem to understand what > current is for, Piotr python2.5-only package is a very good example of > this IMHO. Well, information surrounding 'current' is certainly muddled at present, but I don't think that points to a technical flaw. > > the question is, how will > > doing so fit into the python policy, will there be support for automating > > this in the helper tools, and will packages that do this (and are therefore > > binNMUable for python transitions) be automatically detectable from the > > Sources and/or Packages files? > like I say later, I knew it was what really matters for you. And IMHO > it's really more interesting that the dh_py* tools explains what has > really been built. They already do the job to generate the correct > substs for python:Depends and python:Provides, so basically, the code to > detect that exists. Yes, so automation of the package builds themselves is addressed, with or without 'current'. > One just has to make it clear in the Packages.gz files. Like I said, I > don't really think Sources.gz are relevant, as it's declarative from the > maintainer PoV. I can't think of any reason it would be a problem to have this information in Packages only. > But like said, I've not yet thought about all the consequences yet, > and I do not know what's needed or not. I've the suspicion that XB-P-V > could indeed be the way to go (even if for packages with modules > Provides: show that information already), but I'm not sure that the > current use of XB-P-V carries all the information we need. AIUI the current use of XB-P-V, as endorsed by the python policy, indicates what versions of python the package has been built for, which is not all that relevant for binNMUs; the same information can already be extracted (though less easily) from the provides/depends. What is needed is a description of what will happen to the package if a buildd is *attempted* against a particular version of python. > Thanks. I'll try to make this proposal driven from our needs, and not > trying to advantage this or that implementation of the dh_py* helpers, > which was the ground of the argument when I joined this (mess ?) half a > year ago. I think with your explanations, I quite understand the > requirements from the user and packager point of view (NEW, number of > packages efficiency, etc...), and I believe the sole other need is the > ease to deal with transitions from the RM PoV and for that it needs to > answer the 3 questions: > * what should be binNMUed for a python version removal (assuming it > was not default btw ;P), that one is easy IMHO: basically nothing > _needs_ to, but: > + packages with a strong dependency on that pythonX.Y and _no_ > python dependency have to be dropped altogether (or likely need > porting and are not binNMUable) ; > + for space efficiency we could think of binNMUing every package > that has built a public module for that particular python > version. Here, XB-P-V is not needed if we have the Provides that > is mandatory (and that is what Joss proposes, and I think it's > sane anyway). In addition to space efficiency, this should be done to ensure that packages are in a consistent state at release time, so that we don't risk a security update significantly changing the contents of one of these packages. > * what should be done for a default python change: here concerned > packages are: > + packages with private binary extensions, > + packages built only for the "current" python version. Yes, I believe that's correct. > * what should be done for a new python: here concerned packages are > _only_ packages that build public binary modules for more than the > "current" python. Here again, XB-P-V does not seems required if the > Provides is, they provide the same information, except for the "I'm > only built for current and if you binNMU me I won't generate a new > package anyway". Right. > So that first quick look just says that what we need is a way to find > out about packages that: > * build private extensions (needed for question (2)); > * only build things for the default python version (opposed to those > who build for as many as possible), knowing that I'm only speaking > of packages with public binary modules here. > (needed for 2, and for 3) Looks right to me. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
