[Pkg-electronics-devel] Help with GHDL package

[Wesley J. Landaker]

On Thursday, May 23, 2013 09:21:06 أحمد المحمودي wrote:
> On Sun, May 19, 2013 at 04:31:14PM -0600, Wesley J. Landaker wrote:
> > However, it is a big change from how GHDL is currently packaged (for
> > example, the change to use the gcc-4.7-source package looks good now,
> > but I had to specifically STOP using the gcc-X.Y-source package years
> > back when this caused TONS of problems as soon as it got out of date).
> 
>   So do you recommend against use of gcc-X.Y-source ? Or is the solution
>   when gcc-X.Y gets out of date, is to use gcc-X.Y+1-source ?

The problem I ran into before is that gcc-X.Y-source would move to a new 
version that couldn't build GHDL any more, and then since I had a build-
depends on it, GHDL would get removed from testing. Essentially I was 
*forced* to *immediately* track new versions of gcc, even if it make GHDL 
stop working on a bunch of architectures. After a while that got really old 
and made it very hard to keep GHDL working in Debian (remember, it currently 
works on tons of arches, not just i386 & amd64).

The fix was to just import whatever gcc-core worked well on all 
architectures myself, hence the current scheme. The downside currently is 
that to build GHDL currently (last I messed with it) you either need a big 
horrible monolithic patch for multiarch support (what is in the current NMU) 
or you have to depend on the pre-patched Debian version in gcc-X.Y-source. 

I think the best compromise is probably to package GHDL with its own version 
of GCC, as it does currently, but instead of importing gcc-core from GCC 
upstream, import the contents of the desired Debian gcc-X.Y-source.

> > Perhaps somewhere there has the time and energy to roll in your
> > changes nicely into the Alioth GHDL colloborative maintenance Git
> > repository (ssh://git.debian.org/git/collab-maint/ghdl.git).
> 
>   I just had a look at the Git repo., I'm not used to that layout,
>   what's the 'master' branch for ? I see that pkg-debian branch has the
>   packaging work.

The idea is as follows:

gcc/release  -- nothing but plain imports of gcc-core release tarballs
gcc/dfsg     -- changes to gcc-core for DFSG (mostly removing GFDL stuff)
ghdl/release -- nothing but plain imports of ghdl release tarballs
ghdl/dfsg    -- changes to ghdl for DFSG (again, removing GFDL stuff)
upstream     -- merges gcc/dfsg and ghdl/dfsg, for making .orig.tar.gz
pkg-debian   -- Debian-specific changes (i.e. all the packaging)
master       -- not used (contains just a readme & a git config example)
ghdl/svn/trunk -- a git-svn mirror of SVN, for cherry-picking bug fixes

If you take a look with "gitk --all" it may be easier to see what is going 
on.

The usual way I'd upgrade to a new GHDL or new GCC was something like this. 
Obviously whatever *wasn't* getting updated would get to skip that step:

git checkout gcc/release
tar xvfz gcc-core-whatever.tar.gz
git add -A
git commit -m "Import gcc-core-whatever"
git tag gcc/whatever
git checkout gcc/dfsg
git merge gcc/release
# make & commit new changes for DFSG-freeness; not usually necessary
git checkout ghdl/release
tar xvfz ghdl-whatever.tar.gz
git add -A
git commit -m "Import ghdl-whatever"
git tag ghdl/whatever
git checkout ghdl/dfsg
git merge ghdl/release
# make & commit new changes for DFSG-freeness; not usually necessary
git checkout upstream
git merge gcc/dfsg ghdl/dfsg
git tag ghdl-whatever+gcc-whatever+dfsg
git archive --format=tar ../ghdl-whatever.orig.tar upstream
bzip -9 ../ghdl-whatever+gcc-whatever+dfsg.orig.tar
git checkout pkg-debian
git merge upstream
# make & commit new changes for this Debian version
# built package e.g. I'd use my cowdebuild script which does:
#   pdebuild --pbuilder cowbuilder --debbuildopts "-i -I $*" --use-pdebuild-
internal --buildresult `pwd`/..
# upload e.g. with dput
git tag ghdl-whatever+gcc-whatever+dfsg-1
git push origin :
git push origin --tags

For tracking SVN (say to pull out a single bug fix), I'd do something like:

git checkout ghdl/svn/trunk
git svn rebase
git checkout pkg-debian
# git cherry-pick as necessary, then rebuild, etc

This topic-branch approach makes things very easy to track and manage each 
component. The main thing I worry about is someone coming in and blasting a 
bunch of things straight into into the wrong branches -- of course it will 
"work", inasfar as it will make a package, but it will discard all the 
benefits of this carefully desired branching scheme, and will make things 
harder to upgrade and maintain in the future. I guess I'll I'm saying is if 
you don't follow the current scheme, please just be prepared to be 
responsible for maintaining it long term. =)

One thing that Joris' package does that I do like is that it generates the 
ghdl tarball from the SVN-style layout on the fly. (I usually used plain 
GHDL releases, but Tristan stopped doing those.) It shouldn't be too 
difficult to work this into the current scheme of things, but that is 
something I don't currently have time to do, unfortunately!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-electronics-devel/attachments/20130523/f88fd78b/attachment.pgp>