{"action":"created","issue":{"url":"https://api.github.com/repos/MeeGoIntegration/boss-launcher-webhook/issues/5","labels_url":"https://api.github.com/repos/MeeGoIntegration/boss-launcher-webhook/issues/5/labels{/name}","comments_url":"https://api.github.com/repos/MeeGoIntegration/boss-launcher-webhook/issues/5/comments","events_url":"https://api.github.com/repos/MeeGoIntegration/boss-launcher-webhook/issues/5/events","html_url":"https://github.com/MeeGoIntegration/boss-launcher-webhook/issues/5","id":57838026,"number":5,"title":"tar_git: Support for templated .spec files","user":{"login":"thp","id":135241,"avatar_url":"https://avatars.githubusercontent.com/u/135241?v=3","gravatar_id":"","url":"https://api.github.com/users/thp","html_url":"https://github.com/thp","followers_url":"https://api.github.com/users/thp/followers","following_url":"https://api.github.com/users/thp/following{/other_user}","gists_url":"https://api.github.com/users/thp/gists{/gist_id}","starred_url":"https://api.github.com/users/thp/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/thp/subscriptions","organizations_url":"https://api.github.com/users/thp/orgs","repos_url":"https://api.github.com/users/thp/repos","events_url":"https://api.github.com/users/thp/events{/privacy}","received_events_url":"https://api.github.com/users/thp/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-02-16T18:37:50Z","updated_at":"2015-10-12T11:58:28Z","closed_at":null,"body":"We have several projects where we build the .spec file from some template via a script (usually called `rpm/precheckin.sh`, but I'm sure there are others) to account for slight differences (e.g. two packages for different device adaptations that differ only in package name and build flags, or multiple variations of the same package, etc..). This is good, but has several problems:\r\n\r\n * We store generated files in the Git repository in addition to the template and the script\r\n * People forget to run `precheckin.sh` and patch the generated (=output) files in Git, leading to problems down the line the next time the template is updated and `precheckin.sh` run (I've had this at least two times, and was on the \"receiving end\" of this issue, meaning I had to merge back changes to generated files somebody else did into the template file)\r\n * Patches and pull/merge requests are hard to read, as the same changes appear multiple times (once in the template, and then once for every output file)\r\n * If the list of generated files changes, either `precheckin.sh` has to take care of removing the old file, or the developer has to figure out that the file isn't generated, and has to manually `git rm` the outdated generated file (e.g. an outdated device variant is removed from being generated, then the associated output file also needs to be manually removed)\r\n * Sometimes variants are generated from a base `.spec` file, making it harder to figure out which `.spec` file is the \"template\" one (e.g. `precheckin.sh` generates `bar.spec` from `foo.spec` via `sed -e \"s/FooFoo/BarBar/g\" <foo.spec >bar.spec` -- one has to read and understand `precheckin.sh` to figure out that `bar.spec` is read from `foo.spec`, and that `foo.spec` is used as \"template\" as well as \"output\")\r\n\r\nI hereby propose a feature enhancement for `tar_git`, whereas:\r\n\r\n * If the `.spec` file is not generated, it is stored in Git like now (`rpm/<packagename>.spec`), nothing changes\r\n * If the `.spec` file(s) is/are (to be) generated:\r\n   * The generated `.spec` files **SHOULD NOT** be stored in Git\r\n   * The template file **MUST NOT** end in `.spec` (suggested: `.spec.in`, but not required, as it could theoretically be fully generated by `rpm/precheckin.sh` without any template file)\r\n   * There **MUST** be a script `rpm/precheckin.sh` that is run by `tar_git` using a Bourne shell with the working directory being `rpm/` (think: `cd rpm && rm -f *.spec && sh precheckin.sh`) after the Git checkout and that generates one or more `.spec` files\r\n   * The `rpm/precheckin.sh` script **MUST NOT** assume that any `.spec` file exists, meaning that one cannot generate `.spec` file variants out of a base `.spec` file - the base `.spec` file must always be a template (e.g. `.spec.in`) -- this is to allow `rm -f rpm/*.spec` to remove leftover files, and to avoid situations like with `bar.spec` generated from `foo.spec` as described above\r\n   * The `rpm/precheckin.sh` script **SHOULD NOT** have the executable bit (`+x`) set and the shebang line **SHOULD BE** `#!/bin/sh` (but is ignored, as it's run with `sh precheckin.sh` as above)\r\n   * The `rpm/precheckin.sh` script **MUST NOT** use any bash-isms, only a normal Bourne shell should be assumed\r\n   * *Transitional feature:* If the generated `.spec` file is stored in Git (as for all projects using generated `.spec` files up to now), it **WILL BE** overwritten by `rpm/precheckin.sh`\r\n   * If `rpm/precheckin.sh` exists, it is always safe to run `cd rpm && rm -f *.spec && sh precheckin.sh`, this way, the script doesn't have to take care of removing outdated files (e.g. when a variant for an outdated device is removed, thereby causing less `.spec` files to be generated)\r\n   * It is **RECOMMENDED** that projects that use `rpm/precheckin.sh` have `rpm/*.spec` (like this, with the glob) in their `.gitignore` files, to avoid accidentally adding/checking in generated `.spec` files during development\r\n\r\nThis specification allows local build tools such as `mb2` to be eventually extended to generate and update `.spec` files on demand, and also provides a consistent way for developers to generate/update the `.spec` files manually (`cd rpm && sh precheckin.sh`).\r\n\r\nIn short:\r\n\r\n * If `rpm/precheckin.sh` exists, any tooling or developer should assume that it/he/she needs to first `rm rpm/*.spec` and then run `sh precheckin.sh` (inside the `rpm/` directory as working directory) before the list of `.spec` files is up to date and before any package building can take place. Any change in the source directory - even outside of `rpm/` - should cause a re-run of `rpm/precheckin.sh`, as the `precheckin.sh` script might parse source code files to obtain values used in the `.spec` file -- `tar_git` will run this script after checkout\r\n\r\nOr in code (assume `fail` is a function that prints the error message and then exits with non-zero exit status):\r\n\r\n```\r\n# Right after checkout (tar_git) OR just before build (mb2 / manual build)\r\nif [ -f rpm/precheckin.sh ]; then\r\n    cd rpm\r\n    rm -f *.spec\r\n    sh precheckin.sh || fail \"Could not generate .spec files with precheckin.sh\"\r\n    cd ..\r\nfi\r\n```\r\n\r\nAdvantages that this gives us:\r\n\r\n * We don't store redundant/generated files in Git\r\n * Generated files will always be up to date\r\n * We avoid users editing generated files and forgetting to update the templates\r\n * There is a single, documented and simple way of generating `.spec` files\r\n * Less frustration, more automation, consistency and fun(!)\r\n\r\nPossible transitional disadvantages (= yes, we can't have nice things, there's a transitional cost):\r\n\r\n * Some existing `precheckin.sh` scripts might assume that they are run from the project root\r\n * Some existing `precheckin.sh` might require parameters, these need to be fixed\r\n * We need to educate developers how to use the new feature, and fix existing packaging"},"comment":{"url":"https://api.github.com/repos/MeeGoIntegration/boss-launcher-webhook/issues/comments/147375798","html_url":"https://github.com/MeeGoIntegration/boss-launcher-webhook/issues/5#issuecomment-147375798","issue_url":"https://api.github.com/repos/MeeGoIntegration/boss-launcher-webhook/issues/5","id":147375798,"user":{"login":"larstiq","id":4560289,"avatar_url":"https://avatars.githubusercontent.com/u/4560289?v=3","gravatar_id":"","url":"https://api.github.com/users/larstiq","html_url":"https://github.com/larstiq","followers_url":"https://api.github.com/users/larstiq/followers","following_url":"https://api.github.com/users/larstiq/following{/other_user}","gists_url":"https://api.github.com/users/larstiq/gists{/gist_id}","starred_url":"https://api.github.com/users/larstiq/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/larstiq/subscriptions","organizations_url":"https://api.github.com/users/larstiq/orgs","repos_url":"https://api.github.com/users/larstiq/repos","events_url":"https://api.github.com/users/larstiq/events{/privacy}","received_events_url":"https://api.github.com/users/larstiq/received_events","type":"User","site_admin":false},"created_at":"2015-10-12T11:58:28Z","updated_at":"2015-10-12T11:58:28Z","body":"As discussed with @iamer, \"precheckin.sh\" no longer describes what is going on. Renaming it to something (descriptive) that hasn't been in use before also allows us to sidestep any transitional headaches.\r\n\r\nIn summary, the procedure in #14 is now: `cd rpm && rm -f *.spec && sh genspecs.sh`"}}