[Pkg-electronics-devel] Help with GHDL package
Wesley J. Landaker
wjl at icecavern.net
Thu May 23 22:54:39 UTC 2013
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>
More information about the Pkg-electronics-devel
mailing list