Roberto C. Sanchez roberto at connexer.com writes:
A parallel branch structure might make sense in your case. Then you can
just merge trunk changes up to your branch periodically. As long as you
use dpatch and don't touch any upstream files, you will never have a
conflict.
[EMAIL
What exactly are the advantages and disadvantages of making a
Debian-native package, and is there any real policy or practice?
--
Andrew Donnellan
ajdlinuxATgmailDOTcom (primary)ajdlinuxATexemailDOTcomDOTau (secure)
http://andrewdonnellan.com http://ajdlinux.wordpress.com
[EMAIL
On Tue, 2007-01-23 at 21:34 +1100, Andrew Donnellan wrote:
What exactly are the advantages and disadvantages of making a
Debian-native package, and is there any real policy or practice?
I think this is a good rule:
If the source is published outside of Debian,
do not make a
in upstream's SVN as it makes it much easier for me
to manage snapshots, updates, and so on.
If debian-native packages are discouraged then is there a good way to
keep the debian/ dir with upstream's VCS?
--
Andrew Donnellan
ajdlinuxATgmailDOTcom (primary)ajdlinuxATexemailDOTcomDOTau (secure)
http
, and so on.
If debian-native packages are discouraged then is there a good way to
keep the debian/ dir with upstream's VCS?
You can store the debian/ dir in upstream's VCS, but is is very
undesirable to put it into released tarballs. It may seem handy now, but
it will create a strange situation
/* files into place and build. You retain all
the advantages of building the unreleased code for test packages direct
from CVS/SVN.
If debian-native packages are discouraged then is there a good way to
keep the debian/ dir with upstream's VCS?
You can do whatever you like as long as the debian
as it makes it much easier for me
to manage snapshots, updates, and so on.
If debian-native packages are discouraged then is there a good way to
keep the debian/ dir with upstream's VCS?
You can store the debian/ dir in upstream's VCS, but is is very
undesirable to put it into released tarballs. It may
On Tue, Jan 23, 2007 at 10:02:05PM +1100, Andrew Donnellan wrote:
So essentially, store debian/ etc in the upstream VCS, but keep it out
of releases and only add the directory when building a Debian package?
Does this mean I should create a snapshot of everything except the
debian files,
download the released tarball as
usual, copy your debian/* files into place and build. You retain all
the advantages of building the unreleased code for test packages direct
from CVS/SVN.
If debian-native packages are discouraged then is there a good way to
keep the debian/ dir with upstream's VCS
On Tue, 23 Jan 2007 22:02:05 +1100
Andrew Donnellan [EMAIL PROTECTED] wrote:
So essentially, store debian/ etc in the upstream VCS, but keep it out
of releases and only add the directory when building a Debian package?
Does this mean I should create a snapshot of everything except the
debian
On Tue, 23 Jan 2007 22:09:28 +1100
Andrew Donnellan [EMAIL PROTECTED] wrote:
Keep the debian/* files in CVS/SVN.
Don't package the debian/* files in the distributed tarball.
When building the packages, you simply download the released tarball as
usual, copy your debian/* files into
On Tuesday 23 January 2007 12:37, Thijs Kinkhorst wrote:
On Tue, 2007-01-23 at 21:34 +1100, Andrew Donnellan wrote:
What exactly are the advantages and disadvantages of making a
Debian-native package, and is there any real policy or practice?
Hello,
I think this is a good rule:
to the Debian archive.
Yes, and because of this we should avoid native packages as much as
possible. Nowadays, even projects with only one developer are stored
in revision-control-systems and hosted online.
So, it doesn't matter if something was written specifically for
Debian, you can still host
On 1/23/07, Neil Williams [EMAIL PROTECTED] wrote:
On Tue, 23 Jan 2007 22:09:28 +1100
Andrew Donnellan [EMAIL PROTECTED] wrote:
Keep the debian/* files in CVS/SVN.
Don't package the debian/* files in the distributed tarball.
When building the packages, you simply download the released
On Wed, 24 Jan 2007 08:45:50 +1100
Andrew Donnellan [EMAIL PROTECTED] wrote:
Hmm. Can't you use 'make dist' to create a tarball that is at least
close to what will actually be released? 'make dist' will not include
debian/ UNLESS you have made the mistake of putting debian/ in
EXTRA_DIST
On 1/24/07, Neil Williams [EMAIL PROTECTED] wrote:
On Wed, 24 Jan 2007 08:45:50 +1100
Andrew Donnellan [EMAIL PROTECTED] wrote:
Hmm. Can't you use 'make dist' to create a tarball that is at least
close to what will actually be released? 'make dist' will not include
debian/ UNLESS you have
Andrew Donnellan [EMAIL PROTECTED] writes:
So essentially, store debian/ etc in the upstream VCS, but keep it out
of releases and only add the directory when building a Debian package?
Does this mean I should create a snapshot of everything except the
debian files, then copy the debian files
On Mon, Nov 26, 2001 at 01:46:20PM -0500, Joey Hess wrote:
Adam Heath wrote:
Never build a full release from the cvs work directory. Always cvs export
to
another directory first.
Doing test builds from the cvs work dir is fine. But do final releases
from a
temp dir. Sometimes,
Stefano Zacchiroli [EMAIL PROTECTED] writes:
On Sun, Nov 25, 2001 at 05:16:27PM +0100, Christian Surchi wrote:
On Sun, Nov 25, 2001 at 02:59:03PM +0100, Stefano Zacchiroli wrote:
The problem is that I have a debian native package (so no .diff.gz) that
came from a CVS repository and I'm
[EMAIL PROTECTED] (Stefan Hornburg (Racke)) writes:
IMHO, CVS files should never part of a .tar.gz.
Why? Including CVS information enables receivers of the tarball to
quickly update their version to a more current (actually any) version.
Just transferring deltas eats less bandwidth than a
I'm jumping into this thread a bit late, but...
On Mon, Nov 26, 2001 at 03:52:53PM +0100, Stefan Hornburg (Racke) wrote:
Stefano Zacchiroli [EMAIL PROTECTED] writes:
On Sun, Nov 25, 2001 at 05:16:27PM +0100, Christian Surchi wrote:
On Sun, Nov 25, 2001 at 02:59:03PM +0100, Stefano
Stefano Zacchiroli [EMAIL PROTECTED] writes:
On Sun, Nov 25, 2001 at 05:16:27PM +0100, Christian Surchi wrote:
On Sun, Nov 25, 2001 at 02:59:03PM +0100, Stefano Zacchiroli wrote:
The problem is that I have a debian native package (so no .diff.gz) that
came from a CVS repository and I'm
I'm jumping into this thread a bit late, but...
On Mon, Nov 26, 2001 at 03:52:53PM +0100, Stefan Hornburg (Racke) wrote:
Stefano Zacchiroli [EMAIL PROTECTED] writes:
On Sun, Nov 25, 2001 at 05:16:27PM +0100, Christian Surchi wrote:
On Sun, Nov 25, 2001 at 02:59:03PM +0100, Stefano
On 26 Nov 2001, Stefan Hornburg (Racke) wrote:
Stefano Zacchiroli [EMAIL PROTECTED] writes:
On Sun, Nov 25, 2001 at 05:16:27PM +0100, Christian Surchi wrote:
On Sun, Nov 25, 2001 at 02:59:03PM +0100, Stefano Zacchiroli wrote:
The problem is that I have a debian native package (so no
Adam Heath wrote:
Never build a full release from the cvs work directory. Always cvs export to
another directory first.
Doing test builds from the cvs work dir is fine. But do final releases from a
temp dir. Sometimes, the cvs work dir is poluted, and having a fresh checkout
is safer for
[EMAIL PROTECTED] (Stefan Hornburg (Racke)) writes:
IMHO, CVS files should never part of a .tar.gz.
Why? Including CVS information enables receivers of the tarball to
quickly update their version to a more current (actually any) version.
Just transferring deltas eats less bandwidth than a
Hi mentors,
I know the -i switch of dpkg-source that excludes files from .diff.gz
on a regexp basis.
I want the same feature but on .tar.gz archive and not of .diff.gz.
The problem is that I have a debian native package (so no .diff.gz) that
came from a CVS repository and I'm guessing if there
On Sun, Nov 25, 2001 at 02:59:03PM +0100, Stefano Zacchiroli wrote:
The problem is that I have a debian native package (so no .diff.gz) that
came from a CVS repository and I'm guessing if there is a way to not
delete by hand CVS and .cvs... files each time I check out to build the
package.
The problem is that I have a debian native package (so no .diff.gz) that
came from a CVS repository and I'm guessing if there is a way to not
delete by hand CVS and .cvs... files each time I check out to build the
package.
Use cvs export, or cvs-buildpackage. I'd go with the latter one.
On Sun, Nov 25, 2001 at 05:16:27PM +0100, Christian Surchi wrote:
On Sun, Nov 25, 2001 at 02:59:03PM +0100, Stefano Zacchiroli wrote:
The problem is that I have a debian native package (so no .diff.gz) that
came from a CVS repository and I'm guessing if there is a way to not
delete by hand
Hi mentors,
I know the -i switch of dpkg-source that excludes files from .diff.gz
on a regexp basis.
I want the same feature but on .tar.gz archive and not of .diff.gz.
The problem is that I have a debian native package (so no .diff.gz) that
came from a CVS repository and I'm guessing if there
On Sun, Nov 25, 2001 at 02:59:03PM +0100, Stefano Zacchiroli wrote:
The problem is that I have a debian native package (so no .diff.gz) that
came from a CVS repository and I'm guessing if there is a way to not
delete by hand CVS and .cvs... files each time I check out to build the
package.
The problem is that I have a debian native package (so no .diff.gz) that
came from a CVS repository and I'm guessing if there is a way to not
delete by hand CVS and .cvs... files each time I check out to build the
package.
Use cvs export, or cvs-buildpackage. I'd go with the latter one.
On Sun, Nov 25, 2001 at 05:16:27PM +0100, Christian Surchi wrote:
On Sun, Nov 25, 2001 at 02:59:03PM +0100, Stefano Zacchiroli wrote:
The problem is that I have a debian native package (so no .diff.gz) that
came from a CVS repository and I'm guessing if there is a way to not
delete by hand
Julian Gilbey:
For what reason was it rejected?
Wrong syntax or wrong checksum. I couldn't manage to get the files 100%
correct, so in the end I gave up...
--
\\//
peter - http://www.softwolves.pp.se/
Statement concerning unsolicited e-mail according to Swedish law:
Santiago Vila:
If you insist that the tarball must be created first, follow Julian's
suggestion and make your package non-native by creating an .orig.tar.gz
tarball (in this case the .diff.gz is typically the debian/* files).
I don't want to make it non-native, since that means I would have
peter karlsson wrote:
Santiago Vila:
If you insist that the tarball must be created first, follow Julian's
suggestion and make your package non-native by creating an .orig.tar.gz
tarball (in this case the .diff.gz is typically the debian/* files).
I don't want to make it non-native,
Julian Gilbey:
For what reason was it rejected?
Wrong syntax or wrong checksum. I couldn't manage to get the files 100%
correct, so in the end I gave up...
--
\\//
peter - http://www.softwolves.pp.se/
Statement concerning unsolicited e-mail according to Swedish law:
Santiago Vila:
If you insist that the tarball must be created first, follow Julian's
suggestion and make your package non-native by creating an .orig.tar.gz
tarball (in this case the .diff.gz is typically the debian/* files).
I don't want to make it non-native, since that means I would have
peter karlsson wrote:
Santiago Vila:
If you insist that the tarball must be created first, follow Julian's
suggestion and make your package non-native by creating an .orig.tar.gz
tarball (in this case the .diff.gz is typically the debian/* files).
I don't want to make it non-native,
Mike Markley:
You probably don't want to do this... since a native package has no
.diff.gz, the source tarball must contain everything used to generate the
set of binary packages you're uploading.
It does, I just untarred it to a directory and ran dpkg-buildpackage there.
I don't wnat
Santiago Vila:
I would first create the Debian source and binary packages for upload,
and then distribute the resulting tar.gz elsewhere, in that order.
The problem is that I am generating the tar from my CVS (not all of the CVS
is exported, there are some MSWIN and OS/2 specific stuff there
peter karlsson wrote:
Santiago Vila:
I would first create the Debian source and binary packages for upload,
and then distribute the resulting tar.gz elsewhere, in that order.
The problem is that I am generating the tar from my CVS (not all of the CVS
is exported, there are some MSWIN and
I said:
peter karlsson wrote:
so I don't want dpkg-buildpackage to overwrite it.
Why does dpkg-buildpackage overwrite it? [...]
Oops! I understand. My suggestion is that you arrange things so that
dpkg-buildpackage creates the one and only source tarball, instead of
creating it in advance by
Colin Watson:
If you can't build the Debian package as part of the process of
generating the tarball from CVS, I suppose you could use -b and hack the
.changes by hand to include the source, although that's rather ugly.
I tried hacking the changes file by hand, but my upload got rejected
peter karlsson:
Santiago Vila:
Oops! I understand. My suggestion is that you arrange things so that
dpkg-buildpackage creates the one and only source tarball, instead of
creating it in advance by hand.
I *could* do that, but that would still not solve the problem of the files
in the
On Thu, Sep 06, 2001 at 04:00:25PM +0200, peter karlsson wrote:
Colin Watson:
If you can't build the Debian package as part of the process of
generating the tarball from CVS, I suppose you could use -b and hack the
.changes by hand to include the source, although that's rather ugly.
I
Mike Markley:
You probably don't want to do this... since a native package has no
.diff.gz, the source tarball must contain everything used to generate the
set of binary packages you're uploading.
It does, I just untarred it to a directory and ran dpkg-buildpackage there.
I don't wnat
Santiago Vila:
I would first create the Debian source and binary packages for upload,
and then distribute the resulting tar.gz elsewhere, in that order.
The problem is that I am generating the tar from my CVS (not all of the CVS
is exported, there are some MSWIN and OS/2 specific stuff there
peter karlsson wrote:
Santiago Vila:
I would first create the Debian source and binary packages for upload,
and then distribute the resulting tar.gz elsewhere, in that order.
The problem is that I am generating the tar from my CVS (not all of the CVS
is exported, there are some MSWIN and
I said:
peter karlsson wrote:
so I don't want dpkg-buildpackage to overwrite it.
Why does dpkg-buildpackage overwrite it? [...]
Oops! I understand. My suggestion is that you arrange things so that
dpkg-buildpackage creates the one and only source tarball, instead of
creating it in advance by
Santiago Vila:
Oops! I understand. My suggestion is that you arrange things so that
dpkg-buildpackage creates the one and only source tarball, instead of
creating it in advance by hand.
I *could* do that, but that would still not solve the problem of the files
in the tarball being owned by
Santiago Vila:
Including MSWIN and OS/2 specific stuff in a Debian source tarball
should not be a problem.
Well, the packages structure are different on the different platforms, and
also my MSWIN/OS2 source packages also contain binaries, plus that the
source is CRLF formatted there, and that
On Wed, Sep 05, 2001 at 10:49:51PM +0200, peter karlsson wrote:
How do I get dpkg-buildpackage not to re-build the source tarball when
building a native package? No matter what I do, it rebuilds it, which
prevents me from keeping the tarball I created from my CVS tree, which
also is what I
Colin Watson:
If you can't build the Debian package as part of the process of
generating the tarball from CVS, I suppose you could use -b and hack the
.changes by hand to include the source, although that's rather ugly.
I tried hacking the changes file by hand, but my upload got rejected
* peter karlsson
| Colin Watson:
|
| If you can't build the Debian package as part of the process of
| generating the tarball from CVS, I suppose you could use -b and hack the
| .changes by hand to include the source, although that's rather ugly.
|
| I tried hacking the changes file by
peter karlsson:
Santiago Vila:
Oops! I understand. My suggestion is that you arrange things so that
dpkg-buildpackage creates the one and only source tarball, instead of
creating it in advance by hand.
I *could* do that, but that would still not solve the problem of the files
in the
On Thu, Sep 06, 2001 at 02:07:35PM +0200, peter karlsson wrote:
I *could* do that, but that would still not solve the problem of the
files in the tarball being owned by peter/users instead of
root/root, as the tarball I build now is.
If you *really* want the files to be root/root (why?), then
On Thu, Sep 06, 2001 at 04:00:25PM +0200, peter karlsson wrote:
Colin Watson:
If you can't build the Debian package as part of the process of
generating the tarball from CVS, I suppose you could use -b and hack the
.changes by hand to include the source, although that's rather ugly.
I
Hi!
How do I get dpkg-buildpackage not to re-build the source tarball when
building a native package? No matter what I do, it rebuilds it, which
prevents me from keeping the tarball I created from my CVS tree, which
also is what I distribute elsewhere.
--
\\//
peter -
On Wed, 5 Sep 2001, peter karlsson wrote:
How do I get dpkg-buildpackage not to re-build the source tarball when
building a native package? No matter what I do, it rebuilds it, which
prevents me from keeping the tarball I created from my CVS tree, which
also is what I distribute elsewhere.
You probably don't want to do this... since a native package has no
.diff.gz, the source tarball must contain everything used to generate the
set of binary packages you're uploading.
On Wed, Sep 05, 2001 at 10:49:51PM +0200, peter karlsson [EMAIL PROTECTED]
spake forth:
Hi!
How do I get
peter karlsson wrote:
How do I get dpkg-buildpackage not to re-build the source tarball when
building a native package? No matter what I do, it rebuilds it, which
prevents me from keeping the tarball I created from my CVS tree, which
also is what I distribute elsewhere.
I would first create
On Wed, Sep 05, 2001 at 10:49:51PM +0200, peter karlsson wrote:
Hi!
How do I get dpkg-buildpackage not to re-build the source tarball when
building a native package? No matter what I do, it rebuilds it, which
prevents me from keeping the tarball I created from my CVS tree, which
also is
64 matches
Mail list logo
