> * martin f krafft <[email protected]> [080429 13:56]: >> also sprach Bernhard R. Link <[email protected]> [2008.04.27.1105 >> +0200]: >>> They are different, because you did something different. In the >>> first case you uploaded a (source) package that was already >>> there, in the second case you uploaded a (binary) package where >>> another of the same name was already there. >> >> What do you mean with "another of the same name"? Are you >> suggesting that I am trying to upload the source package again, >> without modifications, and the same md5 sum, while the binary >> package has a different md5sum? > > Yes, that is the only explanation I currently have for getting those > messages. > > Hochachtungsvoll, Bernhard R. Link
It is possible Martin is changing the section in his changelog without incrementing the version. Eg: - reprepro (3.9.0-0) UNRELEASED; urgency=low + reprepro (3.9.0-0) unstable; urgency=low Aside from the issues with this action (technically not the same version, etc.), I still believe this feature request to have some legitimate uses. For example, I recently added a new section to hold proprietary software which can be pulled into main, but in doing so exclude the source packages. The problem is, when my autobuilder determines it is necessary to rebuild binary/arch-only releases it also amends the section/release in debian/changelog based on the autobuilder target release -- in my case the target release is "private". When the package is uploaded, reprepro refuses to accept the binary release because the checksums have changed, but in reality the only change within the .deb is an autogenerated section/release within debian/changelog. I am not suggesting that reprepro is doing anything incorrectly; in fact I think reprepro is doing everything correctly in this instance. Nevertheless, it still would be a nice feature if I had a way I could explicitly tell reprepro, "I know the checksums won't match -- so just this one time, ignore the checksums and reprocess the package(s) anyway." (--ignore=previouslyuploaded?) And when a user uses the option, it should also complain endlessly about how bad it is, and the potential repercussions from using the argument. That's my two cents worth anyway. Thanks! -Ryan H. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
