i may have found a subtle bug related to the patch for issue #10
i had at first the debian naming conventions mixed up - between the project name and version i had a dash but the debian filename convention calls for an underscore in that position - this was the fix that the patch for issue 10 provided - what i noticed tho was that my filename still came out with the dash as i had specified but when i uploaded to packagecloud it got renamed somewhere in transit - the folks at packagecloud say their cli client or server renamed the file to be debian compliant according to the metadata ignoring the actual (non-conforming) filename being uploaded
the argument to fpm i used for example looked like this:
--package projectname-VERSION_ARCH.deb
and the resulting deb file created was named:
projectname-0.07.001_amd64.deb
and the resulting file on packagecloud was named:
projectname_0.07.001_amd64.deb
i only noticed this when i went to delete the package programmatically - perhaps fpm should be enforcing the proper naming schema also
i may have found a subtle bug related to the patch for issue #10
i had at first the debian naming conventions mixed up - between the project name and version i had a dash but the debian filename convention calls for an underscore in that position - this was the fix that the patch for issue 10 provided - what i noticed tho was that my filename still came out with the dash as i had specified but when i uploaded to packagecloud it got renamed somewhere in transit - the folks at packagecloud say their cli client or server renamed the file to be debian compliant according to the metadata ignoring the actual (non-conforming) filename being uploaded
the argument to fpm i used for example looked like this:
and the resulting deb file created was named:
and the resulting file on packagecloud was named:
i only noticed this when i went to delete the package programmatically - perhaps fpm should be enforcing the proper naming schema also