search

learningequality / kolibri-server

A performance-boosting access layer for Kolibri with multi-core support and improved caching
5 stars 8 forks source link

Adds a convenient "make dist" target #57

Closed benjaoming closed 4 years ago

benjaoming commented 4 years ago

Kept running into this

This package has a Debian revision number but there does not seem to be
an appropriate original tar file or .orig directory in the parent directory;
(expected one of kolibri-server_0.3.6.orig.tar.gz, kolibri-server_0.3.6.orig.tar.bz2,
kolibri-server_0.3.6.orig.tar.lzma,  kolibri-server_0.3.6.orig.tar.xz or kolibri-server.orig)
continue anyway? (y/n)
benjaoming commented 4 years ago

Self-merging, it doesn't affect anything released, just a shortcut that makes it a lot easier for me to bootstrap a development environment.

@jredrejo still interested in knowing if you know an even more convenient/built-in way of starting package development from a source-tree with debian/ code inside.

jredrejo commented 4 years ago

The resulting sources with this automated build are invalid. Honestly, for such a simple package I do it manually and test the sources are correct, or just a simple bash script can do it if you prefer to automate it. This Makefile can't be used to build a proper package. Luckily it does not affect to the final package functionality

benjaoming commented 4 years ago

@jredrejo still interested in knowing if you know an even more convenient/built-in way of starting package development from a source-tree with debian/ code inside.

jredrejo commented 4 years ago

@jredrejo still interested in knowing if you know an even more convenient/built-in way of starting package development from a source-tree with debian/ code inside.

Ah, I didn't remember you have this doubt. I hope this will help to clarify it: https://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a_native_Debian_package_and_a_non-native_package.3F

As a rule of thumb, native packages should always be avoided. In this case we have reasons to chose a native package, we must decide. My option so far was not to do it, but I have no problems in changing it for this case as it can be inside the exceptions. But if we build a native package the diff.gz can not exist (and git sources should never be added to the package sources) In any of the cases doing dpkg-sources -x package.dsc should work if the packaging is correct and with the latest sources in launchpad that didn't happen.

In case we opt for a native packaging: https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#native-dh-make explains how to build it. dpkg-buildpackage is the tool I always use both for native or non-native packages

benjaoming commented 4 years ago

The problem I ran into with the original workflow was this: When I changed something and bumped the version, how should I bring about a new orig.tar.gz package?

So I wrote make dist to generate the orig.tar.gz

Do you think that the native package structure can fix this and make the workflow smoother?

jredrejo commented 4 years ago

yes, doing it native would mean we only need to take care of the git file to be excluded. @benjaoming I have created https://github.com/learningequality/kolibri-server/pull/65 to do this change, please, review it.