Hello. I could not agree more. Wearing those two hats can be stressful sometimes. In an ideal world I would be only developing, and would not have to worry about the finer parts of each operating system I am targeting.
Hence my two repositories: One for the project, one for the packages. This way, I can keep my code clean, and even hand over the packaging duties to somebody more experienced than me at some point. Thomas > David Given <[email protected]> hat am 11. Januar 2020 um 13:41 geschrieben: > > I'd add that the recommended thing to do if you're trying to create a package > for software you own is to blatantly wear two hats: with one hat you're the > upstream author, and with the other hat you're the packager. Have two > different repositories, don't add the debian/ directory to the upstream > distribution, when you find an upstream bug fix it there and make a release > and then import the new release into the Debian repository and make a new > package, etc. The workflow works much better like that. > In your specific case, this will avoid the git weirdness because you'd be > only using the public dist files on import. > On Sat, 11 Jan 2020 at 13:17, David Griffith < [email protected]> wrote: > > My reply is at the bottom. Please put your reply there too. > > On Sat, 11 Jan 2020, Thomas Dettbarn wrote: > > >> David Griffith < [email protected]> hat am 11. Januar 2020 um 05:57 > > >> geschrieben: > > >> > > >> I'm trying to debianize Frotz 2.50 and put the debian/ directory into > > >> the > > >> git repository. A complication is that the contents of a dist file > > >> differs from what you get from a git clone. This is what I get from > > >> dpkg-source -b ./ > > >> > > >> dpkg-source: info: using options from frotz-git/debian/source/options: > > >> --tar-ignore=public > > >> dpkg-source: info: using source format '3.0 (quilt)' > > >> dpkg-source: info: building frotz using existing > > >> ./frotz_2.50.orig.tar.gz > > >> dpkg-source: info: using patch list from debian/patches/series > > >> dpkg-source: info: local changes detected, the modified files are: > > >> frotz-git/.gitlab-ci.yml > > >> frotz-git/Makefile > > >> frotz-git/public/index.html > > >> frotz-git/src/dos/bchash.h > > >> dpkg-source: info: you can integrate the local changes with dpkg-source > > >> --commit > > >> dpkg-source: error: aborting due to unexpected upstream changes, see > > >> /tmp/frotz_2.50-1.1.diff.B02OBO > > >> > > >> My problems: > > >> 1) .gitlab-ci.yml handles the Frotz webpage > > >> https://davidgriffith.gitlab.io/frotz/, which lives in public/. By way > > >> of > > >> .gitattributes, that's automatically stripped out of the tarball when > > >> making a distribution source tarball. It should be ignored by > > >> dpkg-source too. > > >> > > >> 2) I can't seem to make dpkg-source ignore public/. I put 'tar-ignore > > >> = > > >> "public"' into debian/source/options and it doesn't seem to work because > > >> dpkg-source is still complaining about public/index.html. > > >> > > >> 3) When a dist tarball is made, hash and date information is put into > > >> Makefile and dos/bchash.h by way of export substitutions in > > >> .gitattributes. The object of this is to embed commit hashes and build > > >> times into the executable. How do I tell the debianization process that > > >> these changes are okay? I'd rather not have to do "made dist", open up > > >> the resulting tarball, and debianize there. > > >> > > >> 4) I would also like the debianization process to ignore src/dos/ as > > >> well > > >> because that contains MS-DOS specific code. > > >> > > >> My working code for this is in the debian branch at > > >> https://gitlab.com/DavidGriffith/frotz > > > > > The way into debian is a complicated one. There are a LOT of > > > helper scripts out there, which have grown. Some of them are > > > still useful, some are not. > > > On top of that, the contents of the debian/ directory are > > > plentiful, and not very well documented, if I may say so. > > > > > > My solution was to create a new repository (ports and packages) > > > outside of my project, and put the debian/ directory in > > > it. And edited the contents by hand. > > > > > > I also added a shell script mkpackage.sh, and only used three > > > tools: debuild, debsign and dput. Within this script, I am > > > also creating the orig.tar.gz, to make sure that it only > > > contains files that I want it to contain. > > > > > > If you would like to have a look, you can clone it from here: > > > [github.com/dettus/ports_and_packages](http://github.com/dettus/ports_and_packages) > > > > > > maybe it helps. > > > > I think I understand most of the debianization process as far as it > > applies to packing up Frotz. My main concerns are why I continue to have > > trouble with the public/ directory, how I'm supposed to make it ignore > > src/dos, and what I'm supposed to do to make it not complain about > > .gitlab-ci.ylm and Makefile. > > > > > > -- > > David Griffith > > [email protected] > > > > A: Because it fouls the order in which people normally read text. > > Q: Why is top-posting such a bad thing? > > A: Top-posting. > > Q: What is the most annoying thing in e-mail? > > -- > ┌─── http://www.cowlark.com ─── > │ "I have always wished for my computer to be as easy to use as my > │ telephone; my wish has come true because I can no longer figure out > │ how to use my telephone." --- Bjarne Stroustrup
