Re: CVS access to upstream
On Tue, Feb 13, 2001 at 10:21:59AM +0100, peter karlsson wrote: > Chad C. Walstrom: > > > The easiest way is to maintain a vendor branch in a local repository. > > I would prefer not to make unnecessary copies... In that case, try creating a branch in the upstream CVS module, rather than a separate module. Your changes would not interfere with upstream releases, you could release as often as you like, and it would be easy to merge in changes for each upstream release tag. It would also make it much easier to grab a pre-release fix and add it to the Debian branch. -- - mdz
Re: CVS access to upstream
On Tue, Feb 13, 2001 at 10:21:59AM +0100, peter karlsson wrote: > Chad C. Walstrom: > > > The easiest way is to maintain a vendor branch in a local repository. > > I would prefer not to make unnecessary copies... In that case, try creating a branch in the upstream CVS module, rather than a separate module. Your changes would not interfere with upstream releases, you could release as often as you like, and it would be easy to merge in changes for each upstream release tag. It would also make it much easier to grab a pre-release fix and add it to the Debian branch. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CVS access to upstream
peter karlsson wrote: > I would prefer not to make unnecessary copies... I think you're referring to the local repository as being unnecessary, in which case I'd agree with you. However, if you do use local repositories and do not have direct upstream CVS access, vendor branchanes are far too convenient to be unnecessary. > Ah. cvs-buildpackage. Yeah, that one could need some documentation. > I tried using it once, but gave up. And I do have some CVS > knowledge... :-) You need to do like any developer: Read the scripts themselves. They're all bash scripts, IIRC. Run it verbose. Watch what happens. It's really not all that cryptic. Throw a '-x' in the pound-bang line. ;-) > However, what I'm thinking of now is to branch out the Debian > specific changes in the upstream CVS, so for each release tagged in > the CVS, I create a Debian branch where I add all the Debian files. > That should be easy enough. I'm finding that branches can often be overkill and more difficult to maintain in the long run. Personally, I would go with your first idea and set it up as a module, not a branch. You can still maintain separate versioning for the packaging code. I'd reserve branches for separating lifecycles of the software itself, or for short term bugfixes. (start) --+:-+-+:-;--- (stable) 0.2.x `^ | `^ | (bug) | (bug) | `+--- (unstable) 0.3.x where + == branch pt. : == merge pt. ; == backport merge pt. Remember, too, that you don't have to branch the entire source tree. Anyway, back to work I go. ;-) -- Chad Walstrom <[EMAIL PROTECTED]> | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD pgpmkqFAfDHOm.pgp Description: PGP signature
Re: CVS access to upstream
peter karlsson wrote: > I would prefer not to make unnecessary copies... I think you're referring to the local repository as being unnecessary, in which case I'd agree with you. However, if you do use local repositories and do not have direct upstream CVS access, vendor branchanes are far too convenient to be unnecessary. > Ah. cvs-buildpackage. Yeah, that one could need some documentation. > I tried using it once, but gave up. And I do have some CVS > knowledge... :-) You need to do like any developer: Read the scripts themselves. They're all bash scripts, IIRC. Run it verbose. Watch what happens. It's really not all that cryptic. Throw a '-x' in the pound-bang line. ;-) > However, what I'm thinking of now is to branch out the Debian > specific changes in the upstream CVS, so for each release tagged in > the CVS, I create a Debian branch where I add all the Debian files. > That should be easy enough. I'm finding that branches can often be overkill and more difficult to maintain in the long run. Personally, I would go with your first idea and set it up as a module, not a branch. You can still maintain separate versioning for the packaging code. I'd reserve branches for separating lifecycles of the software itself, or for short term bugfixes. (start) --+:-+-+:-;--- (stable) 0.2.x `^ | `^ | (bug) | (bug) | `+--- (unstable) 0.3.x where + == branch pt. : == merge pt. ; == backport merge pt. Remember, too, that you don't have to branch the entire source tree. Anyway, back to work I go. ;-) -- Chad Walstrom <[EMAIL PROTECTED]> | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD PGP signature
Re: CVS access to upstream
peter karlsson <[EMAIL PROTECTED]> writes: > Ah. cvs-buildpackage. Yeah, that one could need some documentation. I tried > using it once, but gave up. And I do have some CVS knowledge... :-) I've been using it for years. All I have ever done is cut and paste from the documentation. jason -- ``Just because one proposes a measure to prevent promotion of a risk-filled and controversial sexual behavior doesn't make them divisive or bigoted.'' -- Nicholas J. Yonker, Concerned Citizens for Sound Education
Re: CVS access to upstream
Chad C. Walstrom: > The easiest way is to maintain a vendor branch in a local repository. I would prefer not to make unnecessary copies... > You can use the cvs-inject script provided by cvs-buildpackage to > automate much of this. (Do an 'apt-cache show cvs-buildpackage'.) Ah. cvs-buildpackage. Yeah, that one could need some documentation. I tried using it once, but gave up. And I do have some CVS knowledge... :-) > The package would be considered 'Debian native', and version management > would simplify greatly. That's not an option at the moment. However, what I'm thinking of now is to branch out the Debian specific changes in the upstream CVS, so for each release tagged in the CVS, I create a Debian branch where I add all the Debian files. That should be easy enough. -- \\// peter - http://www.softwolves.pp.se/ Statement concerning unsolicited e-mail according to Swedish law: http://www.softwolves.pp.se/peter/reklampost.html
Re: CVS access to upstream
peter karlsson <[EMAIL PROTECTED]> writes: > Ah. cvs-buildpackage. Yeah, that one could need some documentation. I tried > using it once, but gave up. And I do have some CVS knowledge... :-) I've been using it for years. All I have ever done is cut and paste from the documentation. jason -- ``Just because one proposes a measure to prevent promotion of a risk-filled and controversial sexual behavior doesn't make them divisive or bigoted.'' -- Nicholas J. Yonker, Concerned Citizens for Sound Education -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CVS access to upstream
Chad C. Walstrom: > The easiest way is to maintain a vendor branch in a local repository. I would prefer not to make unnecessary copies... > You can use the cvs-inject script provided by cvs-buildpackage to > automate much of this. (Do an 'apt-cache show cvs-buildpackage'.) Ah. cvs-buildpackage. Yeah, that one could need some documentation. I tried using it once, but gave up. And I do have some CVS knowledge... :-) > The package would be considered 'Debian native', and version management > would simplify greatly. That's not an option at the moment. However, what I'm thinking of now is to branch out the Debian specific changes in the upstream CVS, so for each release tagged in the CVS, I create a Debian branch where I add all the Debian files. That should be easy enough. -- \\// peter - http://www.softwolves.pp.se/ Statement concerning unsolicited e-mail according to Swedish law: http://www.softwolves.pp.se/peter/reklampost.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CVS access to upstream
Regarding: Debian native package v.s. Upstream *.orig.tar.gz + *.diff Joshua Haberman wrote: > Really? I was told by someone else that it makes things much more > complicated, since you have to release a new upstream version for > any debian-specific changes to be made. I'll refrain from quoting > directly, since it was in private e-mail, but he highly recommended > against it, also citing the fact that it will make life more > complicated for anyone who has to adopt the package or NMU. Actually, that is an interesting side-affect of maintaining the software itself separate from its packaging. Incremental changes in the packaging source are found in the *.diff file distributed with the source package. For Debian native code, any version change means a new full-source tarball without a diff. The archives for Debian native packages would be much larger, in retrospect, than upstream software packages. Six in one hand, half a dozen in the other. If our autobuilders were to build from a central CVS repository using cvs-buildpackage and perhaps CVSup, it go far to making this difference a moot point. Given our current system, it may be a wiser decision to maintain the packaging separate from the software itself. Thanks for this discussion topic. I found it quite interesting and thought provoking. ;-) -- Chad Walstrom <[EMAIL PROTECTED]> | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD pgptjz7udgm1X.pgp Description: PGP signature
Re: CVS access to upstream
Regarding: Debian native package v.s. Upstream *.orig.tar.gz + *.diff Joshua Haberman wrote: > Really? I was told by someone else that it makes things much more > complicated, since you have to release a new upstream version for > any debian-specific changes to be made. I'll refrain from quoting > directly, since it was in private e-mail, but he highly recommended > against it, also citing the fact that it will make life more > complicated for anyone who has to adopt the package or NMU. Actually, that is an interesting side-affect of maintaining the software itself separate from its packaging. Incremental changes in the packaging source are found in the *.diff file distributed with the source package. For Debian native code, any version change means a new full-source tarball without a diff. The archives for Debian native packages would be much larger, in retrospect, than upstream software packages. Six in one hand, half a dozen in the other. If our autobuilders were to build from a central CVS repository using cvs-buildpackage and perhaps CVSup, it go far to making this difference a moot point. Given our current system, it may be a wiser decision to maintain the packaging separate from the software itself. Thanks for this discussion topic. I found it quite interesting and thought provoking. ;-) -- Chad Walstrom <[EMAIL PROTECTED]> | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD PGP signature
Re: CVS access to upstream
On Mon, Feb 12, 2001 at 09:25:26PM +0100, peter karlsson wrote: > I have CVS access to a upstream program I am the Debian maintainer for > (jwhois), and since I have learnt the lesson of moving the debian > directory in the CVS, I'm planning to add them as a separate module. > > My question, however, is how to handle differences between the Debian > version and the upstream sources. Is there any standard way I can put > patches that are applied when Debian archives are built, and reversed > when it is ready? The easiest way is to maintain a vendor branch in a local repository. Your Debian specific changes will happen on the main 'trunk', but upstream changes will only happen when you do an upstream release 'import'. Doing diffs is as simple as: cvs diff -r upstream_version_X_X_X > ../my.diff You can use the cvs-inject script provided by cvs-buildpackage to automate much of this. (Do an 'apt-cache show cvs-buildpackage'.) Since you have access to the upstream CVS, you might be able to convince the upstream Author to include the Debian specific changes into the upstream source. In that case, you would not need to maintain a separate upstream version and debian version; they would be one in the same. The package would be considered 'Debian native', and version management would simplify greatly. -- Chad Walstrom <[EMAIL PROTECTED]> | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD pgpQzEz9LZAdi.pgp Description: PGP signature
Re: CVS access to upstream
On Mon, Feb 12, 2001 at 09:25:26PM +0100, peter karlsson wrote: > I have CVS access to a upstream program I am the Debian maintainer for > (jwhois), and since I have learnt the lesson of moving the debian > directory in the CVS, I'm planning to add them as a separate module. > > My question, however, is how to handle differences between the Debian > version and the upstream sources. Is there any standard way I can put > patches that are applied when Debian archives are built, and reversed > when it is ready? The easiest way is to maintain a vendor branch in a local repository. Your Debian specific changes will happen on the main 'trunk', but upstream changes will only happen when you do an upstream release 'import'. Doing diffs is as simple as: cvs diff -r upstream_version_X_X_X > ../my.diff You can use the cvs-inject script provided by cvs-buildpackage to automate much of this. (Do an 'apt-cache show cvs-buildpackage'.) Since you have access to the upstream CVS, you might be able to convince the upstream Author to include the Debian specific changes into the upstream source. In that case, you would not need to maintain a separate upstream version and debian version; they would be one in the same. The package would be considered 'Debian native', and version management would simplify greatly. -- Chad Walstrom <[EMAIL PROTECTED]> | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD PGP signature
