Re: Help, shc newer version packaging
* T o n g <mlist4suntong@yahoo.com>, 2015-09-12, 13:20:
- First, how to deal with the changing source names?
I have a .patch file for the .c source file, however, the way upstream
maintains the source is that it gives a new name to the .c source file
in each version by appending the version number to the file name end,
while using a not-changing symlink file to make the makefile happy.
This trick works for the makefile file but will cause patching to
choke. How to deal with such situation? Is there any patching mechanism
to allow me to do some shell-script operation like the following before
patching?
rm shc.c
mv shc-3.8.9.c shc.c
Some thing happened to makefile as well -- the previous version was
"Makefile" and now it is called "makefile". That'll choke my makefile
patching as well.
You can execute any code you want in debian/rules, so you could
implement your fancy patching mechanism if you wanted to. But that would
be a bad idea.
Please ask upstream not to change the file names. Also, if possible,
please forward the patches upstream, so that you don't have to apply
them.
In the mean time, the best you can do is to rebase your patches
manually.
- I need advice on how should I properly name the package.
This needs a bit explanation. The version I packaged was shc-3.8.7
because the shc-3.8.9 version has a critical bug. Now the upstream
release a fix but call it shc-3.8.9b. Shall I named my Debian package
shc-3.8.9b as well, or just shc-3.8.9?
(I suppose you ask about package version, not about package name.)
"3.8.9b" is a valid version number. I don't see why you shouldn't use
it.
- Finally, to do things properly, should I open an ITP bug then close
it in changelog?
No, ITPs are only for new packages.
--
Jakub Wilk
Reply to: