On Mon, Feb 18, 2013 at 08:05:07PM +0100, Guillem Jover wrote:
I was not attacking the NMU faith or its usefulness, otherwise we'd
obviously not have NMUs; what I was getting at in this thread, that
got trimmed in the quoted mail, is the thought that the current NMU
procedure for native
Gergely Nagy writes (Re: No native packages?):
There are two native packages I maintain, and I've yet to hear a good
reason for making either of them non-native. Making it harder and much
much more inconvenient for downstream distributions to modify them is a
*goal* in these cases: to make
In article 8738xju6br@windlord.stanford.edu,
Russ Allbery r...@debian.org wrote:
I'm still religious about using non-native packaging for my own packages
that have any conceivable use outside of Debian or derivatives, since I
find it aesthetically ugly, and therefore psychically painful, to
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Gergely Nagy writes (Re: No native packages?):
There are two native packages I maintain, and I've yet to hear a good
reason for making either of them non-native. Making it harder and much
much more inconvenient for downstream distributions
]] Ian Jackson
I haven't looked up to see what these packages are, but I worry that
what you are doing here is undermining the freedom of our downstreams.
They're free to do whatever they want.
The ability of our users and downstreams to choose to modify the
software we distribute is the
On Sat, 2013-02-16 at 12:11:29 +0100, Stefano Zacchiroli wrote:
On Wed, Feb 13, 2013 at 03:41:53AM +0100, Guillem Jover wrote:
(Random data point: I have 14 packages with versions indicating they
are NMUed native packages installed on my system. Some of them have
priority standard or
On Wed, Feb 13, 2013 at 03:41:53AM +0100, Guillem Jover wrote:
(Random data point: I have 14 packages with versions indicating they
are NMUed native packages installed on my system. Some of them have
priority standard or higher.)
I've a similar number on my system, but most of these
On Mon, 2013-02-04 at 18:43:22 +0100, Jakub Wilk wrote:
So what do you propose instead? It's not like native packages get
NMUed because of great entertainment value of the NMU process, but
because there's no better choice.
The same thing we usually do when confronted with a dead upstream
* Guillem Jover guil...@debian.org, 2013-02-02, 13:56:
if you are going to patch the package you might as well do the one
line change from 3.0 (native) to 3.0 (quilt), and rename the
source tarball to add «.orig».
That's a good solution for derivatives, not so much for NMUs or
backports.
As
On Fri, 2013-02-01 at 22:25:18 +0100, Jakub Wilk wrote:
* Guillem Jover guil...@debian.org, 2013-01-29, 20:31:
if you are going to patch the package you might as well do the one
line change from 3.0 (native) to 3.0 (quilt), and rename the
source tarball to add «.orig».
That's a good
* Guillem Jover guil...@debian.org, 2013-01-29, 20:31:
if you are going to patch the package you might as well do the one line
change from 3.0 (native) to 3.0 (quilt), and rename the source
tarball to add «.orig».
That's a good solution for derivatives, not so much for NMUs or
backports.
On Wed, 2013-01-30 at 17:58 +1100, Joey Hess wrote:
Julien Cristau wrote:
Maybe I forgot the answer, but at least in terms of git and the dpkg
3.0 (git) format, why can't we simply make use of shallow cloning?
At which point you have lost all the advantages of shipping the
repository
On 01/29/2013 08:29 AM, Russ Allbery wrote:
Benjamin Drung bdr...@debian.org writes:
Other distributions gain from your extra work. Image the opposite. You
want to package a software that is only available in a downstream
distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a
On 01/28/2013 08:59 PM, Gergely Nagy wrote:
In my opinion, a native package is the wrong choice when your only
arguments for it is convenience.
That's not a strong argument
To the contrary, I think that convenience of one or another
format is the *only* argument.
What you've listed as
On 01/30/2013 04:38 PM, Ian Campbell wrote:
Also, I wonder if it is possible to arrange that having unpacked a git
format source package that the remotes for debian and upstream are
already prepopulated in the repo such that git remotes update would
fetch all of the missing history without
On Tue, Jan 29, 2013 at 12:59:28AM +0100, Cyril Brulebois wrote:
Benjamin Drung bdr...@debian.org (28/01/2013):
Other distributions gain from your extra work. Image the
opposite. You want to package a software that is only available in a
downstream distribution (e.g. Ubuntu or Linux Mint).
Gergely Nagy, 2013-01-28 09:44:18 +0100 :
[...]
By harmful side effects, I mean two things:
[...]
- Patches not separated
Not quite true. You can still have debian/patches/* and apply them at
build-time (dpatch or quilt), even if they're not shipped in a separate
.diff.gz file.
Roland.
Tollef Fog Heen tfh...@err.no writes:
]] Gergely Nagy
No, not really. I don't really care what tools one uses, as long as the
result is reasonably easy *and* reliable to work with. Since VCS can be
stale, and quite often does not include neither NMUs, nor backports,
that fails the reliable
Wouter Verhelst wou...@debian.org writes:
On Mon, Jan 28, 2013 at 09:44:18AM +0100, Gergely Nagy wrote:
Wouter Verhelst wou...@debian.org writes:
On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote:
Dmitrijs Ledkovs wrote on his blog[0]:
Generally if software is useful in
Roland Mas lola...@debian.org writes:
Gergely Nagy, 2013-01-28 09:44:18 +0100 :
[...]
By harmful side effects, I mean two things:
[...]
- Patches not separated
Not quite true. You can still have debian/patches/* and apply them at
build-time (dpatch or quilt), even if they're not
Am Montag, den 28.01.2013, 22:53 -0600 schrieb Peter Samuelson:
[Benjamin Drung]
Image the opposite. You want to package a software that is only
available in a downstream distribution (e.g. Ubuntu or Linux
Mint). Do you prefer to have a non-native format or a native format?
If their
Tollef Fog Heen tfh...@err.no writes:
I wasn't trying to imply that my idea was new. :-)
Sorry. :) I wasn't clear enough that I figured you probably knew the
history.
Yes, this is a lot of work, and I'm not sure what the best way to go
about it would be. On the other hand, I think we're
On Sun, 2013-01-27 at 19:16:44 +0100, Jakub Wilk wrote:
Dmitrijs Ledkovs wrote on his blog[0]:
Generally if software is useful in Debian Project it can be useful
for other debian-like and unlike projects. In particular native
packages do not offer the same patching flexibility as 3.0
Guillem Jover guil...@debian.org writes:
I don't really see the problem here, if you are going to patch the
package you might as well do the one line change from 3.0 (native) to
3.0 (quilt), and rename the source tarball to add «.orig».
One of the issues with native packages before format
Julien Cristau wrote:
Maybe I forgot the answer, but at least in terms of git and the dpkg
3.0 (git) format, why can't we simply make use of shallow cloning?
At which point you have lost all the advantages of shipping the
repository that Tollef mentioned, as far as I can tell. You're back
On 01/28/2013 07:30 PM, Philip Hands wrote:
You're going to have to do a lot better than saying that you don't like
it very much if you're going to convince me that Joey's mistaken in that
choice
Hi Phil,
Thanks for sharing your view (and the one of Joe).
I also maintain at least one native
Wouter Verhelst wou...@debian.org writes:
On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote:
Dmitrijs Ledkovs wrote on his blog[0]:
Generally if software is useful in Debian Project it can be useful
for other debian-like and unlike projects. In particular native
packages do not
On 27 January 2013 18:32, Gergely Nagy alger...@balabit.hu wrote:
Jakub Wilk jw...@debian.org writes:
Dmitrijs Ledkovs wrote on his blog[0]:
Generally if software is useful in Debian Project it can be useful
for other debian-like and unlike projects. In particular native
packages do not
Gergely Nagy alger...@balabit.hu writes:
...
We have tools that make it easy to create upstream tarballs from an SCM
repo. Git has git archive, gitpkg and possibly other tools make it very
easy to create upstream tarballs: so much so, that it means nothing more
than tagging the repo properly.
On the other side of the fence are folks who believe in the separation
between upstream and Debian so much that they refuse to package
software they are upstream for (I'm not among them, but I know they
exist).
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to
Philip Hands p...@hands.com writes:
Gergely Nagy alger...@balabit.hu writes:
...
We have tools that make it easy to create upstream tarballs from an SCM
repo. Git has git archive, gitpkg and possibly other tools make it very
easy to create upstream tarballs: so much so, that it means nothing
]] Gergely Nagy
No, not really. I don't really care what tools one uses, as long as the
result is reasonably easy *and* reliable to work with. Since VCS can be
stale, and quite often does not include neither NMUs, nor backports,
that fails the reliable requirement.
It sounds like you are
Gergely Nagy algernon at balabit.hu writes:
There's also the case where upstream and debian maintainer are the same
*now*, but that can change anytime. Case in point: there's a package[1]
That’s actually (one of) the reasons why I’m not using native packages
for the software I’m upstream of,
Tollef Fog Heen tfh...@err.no writes:
]] Gergely Nagy
No, not really. I don't really care what tools one uses, as long as the
result is reasonably easy *and* reliable to work with. Since VCS can be
stale, and quite often does not include neither NMUs, nor backports,
that fails the reliable
On Mon, Jan 28, 2013 at 09:36:45AM -0800, Russ Allbery wrote:
Tollef Fog Heen tfh...@err.no writes:
]] Gergely Nagy
No, not really. I don't really care what tools one uses, as long as the
result is reasonably easy *and* reliable to work with. Since VCS can be
stale, and quite often
On 28 January 2013 18:17, Roger Leigh rle...@codelibre.net wrote:
On Mon, Jan 28, 2013 at 09:36:45AM -0800, Russ Allbery wrote:
Tollef Fog Heen tfh...@err.no writes:
]] Gergely Nagy
No, not really. I don't really care what tools one uses, as long as the
result is reasonably easy *and*
Roger Leigh rle...@codelibre.net writes:
Maybe I forgot the answer, but at least in terms of git and the dpkg 3.0
(git) format, why can't we simply make use of shallow cloning? We only
distribute a single revision, the one we're building, and if the history
is polluted for whatever reason,
On Mon, Jan 28, 2013 at 18:17:20 +, Roger Leigh wrote:
On Mon, Jan 28, 2013 at 09:36:45AM -0800, Russ Allbery wrote:
Tollef Fog Heen tfh...@err.no writes:
]] Gergely Nagy
No, not really. I don't really care what tools one uses, as long as the
result is reasonably easy *and*
On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote:
I am guilty myself of maintaining a native package (and another one
is waiting in NEW). However, I will be happy to switch to a
non-native format once I figure out a releasing work-flow that is
convenient for me.
Changing from native
Am Dienstag, den 29.01.2013, 08:49 +1100 schrieb Craig Small:
On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote:
I am guilty myself of maintaining a native package (and another one
is waiting in NEW). However, I will be happy to switch to a
non-native format once I figure out a
Benjamin Drung bdr...@debian.org (28/01/2013):
Other distributions gain from your extra work. Image the
opposite. You want to package a software that is only available in a
downstream distribution (e.g. Ubuntu or Linux Mint). Do you prefer
to have a non-native format or a native format?
On Mon, Jan 28, 2013 at 11:59:56PM +0100, Benjamin Drung wrote:
Other distributions gain from your extra work. Image the opposite. You
want to package a software that is only available in a downstream
distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a
non-native format or a
Benjamin Drung bdr...@debian.org writes:
Other distributions gain from your extra work. Image the opposite. You
want to package a software that is only available in a downstream
distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a
non-native format or a native format?
I'm not
On Mon, Jan 28, 2013 at 09:44:18AM +0100, Gergely Nagy wrote:
Wouter Verhelst wou...@debian.org writes:
On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote:
Dmitrijs Ledkovs wrote on his blog[0]:
Generally if software is useful in Debian Project it can be useful
for other
[Benjamin Drung]
Image the opposite. You want to package a software that is only
available in a downstream distribution (e.g. Ubuntu or Linux
Mint). Do you prefer to have a non-native format or a native format?
If their native format is an archive in gzipped tar file format, like
ours is, I'm
]] Russ Allbery
Tollef Fog Heen tfh...@err.no writes:
]] Gergely Nagy
No, not really. I don't really care what tools one uses, as long as the
result is reasonably easy *and* reliable to work with. Since VCS can be
stale, and quite often does not include neither NMUs, nor backports,
Jakub Wilk jw...@debian.org writes:
Dmitrijs Ledkovs wrote on his blog[0]:
Generally if software is useful in Debian Project it can be useful
for other debian-like and unlike projects. In particular native
packages do not offer the same patching flexibility as 3.0 (quilt),
thus forcing
Hi,
On 27.01.2013 19:32, Gergely Nagy wrote:
There are two native packages I maintain, and I've yet to hear a good
reason for making either of them non-native.
Not knowing your use cases in particular, it would often be good enough
if we could restrict native packages to use cases, where they
Arno Töll a...@debian.org writes:
Hi,
On 27.01.2013 19:32, Gergely Nagy wrote:
There are two native packages I maintain, and I've yet to hear a good
reason for making either of them non-native.
Not knowing your use cases in particular, it would often be good enough
if we could restrict
On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote:
Dmitrijs Ledkovs wrote on his blog[0]:
Generally if software is useful in Debian Project it can be useful
for other debian-like and unlike projects. In particular native
packages do not offer the same patching flexibility as 3.0
Adrian Bunk [EMAIL PROTECTED] writes:
It's different when the Debian maintainer is also upstream. It is argued
that then there's only one `debianization'. That's all right but please
consider the following cases before making your package Debian native:
- Do you want to release a new upstream
51 matches
Mail list logo
