----- Original Message -----
On 12/12/2013 01:18 AM, Bohuslav Kabrda wrote:
> Well yeah, my point is that there is no upstream-acceptable way other than
> checking the file hashes by ensurepip, is there? If I wouldn't want to
> check file hashes, I'd have to query RPM for release - or is there some
> other way you're thinking of?
I think doing it initially as a downstream only change where you query
RPM will work for now (perhaps by patching the way pip handles the case
where ENSUREPIP_OPTIONS is set?).
By the time this approach is posted upstream, then PEP 426/440 will
hopefully by Final and we can just use the metadata version field
directly rather than needing to grab the release increment from the RPM
repo. (I think this situation provides a good practical use case for why
it's important to standardise this feature upstream, too).
So, getting back to Toshio's concern about sysadmins who just update'n'upload
files, the workflow for them would be "update files, bump build tag and then
What I mean is, this still has two solutions:
- checking the build tag (seems to be very simple to do)
- check the file hashes
Both solutions are IMO acceptable upstream (when we can actually do build tags), but my
question is: Which one is more likely to be accepted? I'm for "checking the build
tag", even if it means the extra step for sysadmins who will need to bump the build
tag when doing changes. (We may need to tell them to not bump the build tag "major
number", but add something to it like "1" => "1.1", since we
want distro package with "2" win over sysadmin's change.)
Does that make sense? What I'd love to hear is which of the two approaches is more
likely to get accepted upstream, so that I can concentrate on that one approach.
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (http://beaker-project.org/
Bohuslav "Slavek" Kabrda.