Re: debianization with files that change
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 <dg@cowlark.com> 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 < dave@661.org> wrote:
> > My reply is at the bottom. Please put your reply there too.
> > On Sat, 11 Jan 2020, Thomas Dettbarn wrote:
> > >> David Griffith < dave@661.org> 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
> > dave@661.org
> >
> > 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
Reply to: