Pierre-Elliott, On 7 April 2016 at 12:27, Pierre-Elliott Bécue <[email protected]> wrote: > You're right, but I'm an "explicit is better than implicit guy". :)
I guess this is not a case of "explicit vs. implicit". Imagine the entire line as an URL: https://github.com/P-EB/python-django-gravatar2.git%20-b%20master Of course you wouldn't have a problem if you copy-and-pasted it (before escaping the spaces) on the command line, as the "-b master" would be interpreted as arguments to "git clone". But, if you copy and pasted on another client, e.g. a GUI Git client (which I've seen people using), the URL may be interpreted like above (after escaping) and the cloning process will fail. Not to mention that this is expected to be in machine-readable form, which may not be aware that someone is passing Git command line arguments along the URL. > I thought it'd be better to keep them, but, okay. They are mostly related to building projects written in C, so there's little use for a pure-Python one, as you are not "saving them for later". > I'm not in fond of PYBUILD_NAME thing since I met a lot of trouble with it. > If that's recommended I'll put it but I'm more a ".install" files guy. Imagine that you would be doing by hand what is expected to be automated by Pybuild. > I do not have any issue to build multiple times, but I'll follow your > advice. Are you building with pbuilder or something like that? I've used dpkg-buildpackage and it complained in the second time I ran it. > I'm really uncomfortable with tests un packaging for python apps, but I can > try to remove the override. Anyway, I'm using pybuild, hence the pypi > package fits better and a good way to have a snapshot of upstream's work. Why uncomfortable with tests in packaging? They can help to make sure that newer versions aren't introducing regressions. I didn't understood why PyPI packages would fit better than snapshots (tarball releases) from the upstream repository. > Thank you very much for all these advice. Glad to help. You're welcome. On 7 April 2016 at 12:51, Pierre-Elliott Bécue <[email protected]> wrote: > I uploaded a new version of the package. It should be visible soon, and > accessible also via > > dget -x > http://mentors.debian.net/debian/pool/main/p/python-django-gravatar2/python-django-gravatar2_1.4.0-2.dsc You shouldn't bump the version of the package yet, as it was never uploaded to the archive. Until the first upload, it will be "X.Y.Z-1", no matter how many changes you did to it. Then you can bump the version in the following revisions, but only after every upload, not after every change in the packaging work. P.s.: I've seen that you pushed changes with "--force" to the Git repository. Please don't do that when you already shared it with other people. They will not be able to merge/pull easily (as there are annoying merge conflicts in the changed files) and will be harder to analyze what you really did (which is the primary feature of every version control system), as there will be no visible difference in the history. Regards, Tiago. -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
