On Tue, Aug 16, 2011 at 4:48 AM, Luca BRUNO <lu...@debian.org> wrote:
> Peter Bigot scrisse: > > > I'm surprised the binutils patches don't work since I wouldn't expect > > any upstream changes to affect the msp430 files, but I can only > > provide patches against the upstream release that's part of the > > initial LTS release. > > On top of that, Debian source also carries additional patches for other > supported arches. This all make patching failing on common files > (eg. Makefile.am). > I begin to see: instead of patching upstream tar files for a package, Debian's build infrastructure asks that you patch somebody else's already patched tarfiles, thus putting everybody's patches for everything into one large pot and stirring. I suppose that's one way to run a distribution. > This currently happens for both binutils and gcc, and I can't do much > for it (except trying a cluebat on the fellow maintainer). > This is very unfortunate, but should be almost transparent to you and > I'm fine with patches plus your handling of git branches :) > > > If you apply them against some other version, I > > hope the version numbers you use make it clear that what you have > > isn't a supported release from the perspective of mspgcc. > > As I am forced to live with it, I'm still looking for the straighter > way. > The binutils I'm currently uploading, announces itself as: > > lucab@galatea:~$ msp430-objdump -v > GNU objdump (GNU Binutils patched msp20110716) 2.21.53.20110805 > [...] > > As the banner says, this is upstream 20110805 snapshot with mspgcc > 20110716 LTS patches. PKGVERSION (everything between parenthesis) may > be customized at configure time, your pick :) > Package file is currently numbered 2.21~msp20110716-1, as it > may be automatically built against newer post-2.21 snapshots. > I avoided putting lts labels anywhere, as it may differ from what you > expect (while in fact being almost identical). > Is it clear enough? Should I change anything to make it more explicit? > Something similar will be applied to GCC. > No, I think that communicates both the base version of the package, and the base version of the mspgcc patches, which is all I'd expect anybody to be able to see without inspecting the package log. Hopefully none of the upstream changes or patches Debian applies for you will break mspgcc. > > The overhead of preparing and pushing releases is too much to > > add yet another level of version numbering. > > Fine. I'll keep a patch level numbering somewhere internally just to > distinguish them in the archive. > Sounds good. Peter > > Cheers, Luca > > -- > .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) > : :' : The Universal O.S. | lucab (AT) debian.org > `. `'` | GPG Key ID: 3BFB9FB3 > `- http://www.debian.org | Debian GNU/Linux Developer > > > ------------------------------------------------------------------------------ > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users >
------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
