* Ron r...@debian.org [141119 07:21]:
I believe Bernhard explained earlier that git-dpm allows the replacement
character to be configurable (but also offers just a single character
for all replacements).
git-dpm doesn't have a replacement-character configurable, but different
control sequences
Ron writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
As I explained in the earlier discussion with Henrique, there are more
things than just : and ~ which are perfectly legal in debian version
strings, but are illegal constructs in git refnames.
AFAICT[1
On Wed, Nov 19, 2014 at 03:41:12PM +, Ian Jackson wrote:
Ron writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
As I explained in the earlier discussion with Henrique, there are more
things than just : and ~ which are perfectly legal in debian version
strings
Hi Raphael,
On Thu, Nov 13, 2014 at 09:46:13AM +0100, Raphael Hertzog wrote:
[..snip..]
Problem 1: the derivatives
--
So I am a Kali Linux contributor. We use git repos to maintain all our
packages and we use git-buildpackage. Most of the Kali contributors
are not
On Fri, Nov 14, 2014 at 11:35:45AM +0100, Marco d'Itri wrote:
On Nov 14, Raphael Hertzog hert...@debian.org wrote:
This is just a proof that storing the patches as real commits is useful.
And that's the point of the patch-queue tag. Instead of having the patches
only as real commits in
On Sat, Nov 15, 2014 at 06:35:07PM +, Simon McVittie wrote:
[..snip..]
with upstream changes - and try packaging them with each of gbp-pq,
Note that nothing withing gbp forces you to use gbp-pq. You can use
e.g. use
--no-unapply-patches
--auto-commit
--single-debian-patch
in your
On 18/11/14 07:20, Guido Günther wrote:
Note that nothing withing gbp forces you to use gbp-pq.
I know; but the gbp-pq-like repository structure, as produced by git
import-dsc with no special options, is a popular one (pkg-perl and their
3000 packages, as well as smaller teams like -telepathy,
On Mon, Nov 17, 2014 at 11:39:10PM +, Simon McVittie wrote:
On 17/11/14 16:24, Ian Jackson wrote:
I don't think this problem, of a mass of different branch structures,
is going to go away any time soon. Simply because people don't seem
able to agree.
I agree it's unlikely to go away,
On Fri, Nov 14, 2014 at 03:44:35PM +, Ian Jackson wrote:
Bernhard R. Link writes (Re: RFC: DEP-14: Recommended layout for Git
packaging repositories):
Raphael Hertzog hert...@debian.org [14 22:26]:
...
When a Git tag needs to refer to a specific version of a Debian package
Guido Günther writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
On Fri, Nov 14, 2014 at 03:44:35PM +, Ian Jackson wrote:
Current practice seem so be to replace both : and ~ with _. Unless
we
This didn't work well so gbp switched to what Raphael documented
On Tue, Nov 18, 2014 at 04:24:30PM +, Ian Jackson wrote:
Guido Günther writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
On Fri, Nov 14, 2014 at 03:44:35PM +, Ian Jackson wrote:
Current practice seem so be to replace both : and ~ with _. Unless
we
Ian wrote:
Guido Günther writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
On Fri, Nov 14, 2014 at 03:44:35PM +, Ian Jackson wrote:
Current practice seem so be to replace both : and ~ with _. Unless
we
This didn't work well so gbp switched to what
On Tue, 18 Nov 2014 21:17:15 -0500, James McCoy wrote:
Guido Günther writes (Re: RFC: DEP-14: Recommended layout for Git
packaging repositories):
This didn't work well so gbp switched to what Raphael documented years
ago (: - %, ~ - _).
Hmm, seems debcommit is converting
On Mon, 17 Nov 2014, Ron wrote:
Anything that doesn't store the full debian version (be it a git tag or a
filename) will have a colision risk. Consider a package that has versions
1:2.3.5-1 and 5:2.3.5-1.
Right, that was one of the first cases I mentioned. When you upload
5:2.3.5-1,
Simon McVittie writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
I agree that the expected contents of the branches are far more
important than their names. Unfortunately, while acting as the Debian
expert for Debian derivatives at $day_job, I keep finding
Simon McVittie writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
gbp-pq and git-dpm are the other way round: the tree can be built with
dpkg-buildpackage, but the cost is that you have to commit in a way that
isn't the normal git thing (either using a specific tool
On 17/11/14 16:24, Ian Jackson wrote:
I don't think this problem, of a mass of different branch structures,
is going to go away any time soon. Simply because people don't seem
able to agree.
My answer is to create a parallel universe in which the branch
structure is known.
As far as I can
Simon McVittie writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
As far as I can see from what you've said elsewhere, for source format
3.0 (quilt), you're aiming for the patches applied and also serialized
in debian/patches/ state (matching git-dpm I think
On Sat, Nov 15, 2014 at 06:15:33PM +, Simon McVittie wrote:
On 12/11/14 22:07, Ron wrote:
I am also interested to hear more
about whatever the confusion was you had with this was when you
started working with Tollef's systemd repo that you mentioned
in the previous thread.
Having
On Fri, 14 Nov 2014, Thorsten Glaser wrote:
On Fri, 14 Nov 2014, Ian Jackson wrote:
expect to find version numbers matching ^\d+\~, then anything matching
These are common enough for me to have not only seen,
but also used (in native packages, of course) them.
Not only in native
On Sat, Nov 15, 2014 at 06:35:07PM +, Simon McVittie wrote:
On 13/11/14 14:04, Ron wrote:
I really do think that the names of the branches are actually going to
be the least of your worries here, unfortunately. Even with a naming
scheme that's widely adopted, things just aren't going
On Sun, 16 Nov 2014, Ron wrote:
On Sat, Nov 15, 2014 at 03:49:56PM -0200, Henrique de Moraes Holschuh wrote:
On Sat, 15 Nov 2014, Raphael Hertzog wrote:
On Fri, 14 Nov 2014, Ian Jackson wrote:
What exactly is your use case you feel this is essential for?
I think this discussion
On Sun, Nov 16, 2014 at 02:03:23PM -0200, Henrique de Moraes Holschuh wrote:
On Sun, 16 Nov 2014, Ron wrote:
On Sat, Nov 15, 2014 at 03:49:56PM -0200, Henrique de Moraes Holschuh wrote:
On Sat, 15 Nov 2014, Raphael Hertzog wrote:
On Fri, 14 Nov 2014, Ian Jackson wrote:
What exactly
On Sun, Nov 16, 2014 at 07:33:32PM +1030, Ron wrote:
On Sat, Nov 15, 2014 at 06:15:33PM +, Simon McVittie wrote:
On 12/11/14 22:07, Ron wrote:
I am also interested to hear more
about whatever the confusion was you had with this was when you
started working with Tollef's systemd
Hi,
Bernhard R. Link:
I think such a document would do well to not say much about upstream
branches or imply how they should be managed.
It is helpful to base the Debian release on an Upstream release that is
actually tagged by Upstream, provided that the version thus tagged is the
basis for
On Fri, 14 Nov 2014, Ian Jackson wrote:
Richard Hartmann writes (Re: RFC: DEP-14: Recommended layout for Git
packaging repositories):
Can you at least suggest, not require, that the NMUer should also send
a link to a publicly available branch with the patch(es) which are
based
On Fri, 14 Nov 2014, Ian Jackson wrote:
What exactly is your use case you feel this is essential for?
I think this discussion is in danger of going round in circles.
I'm going to leave it here and let Raphael get on with it.
I understand Ron's logic and there's certainly value in
On Sat, 15 Nov 2014 18:02:23 +0100, Raphael Hertzog wrote:
Unless you want to suggest a specific standardized name for a NMU patch
branch... but this does seem a bit premature given that nobody is
currently doing stuff like that. The few persons that I saw commit their
NMU to git just used
On Sat, 15 Nov 2014, Raphael Hertzog wrote:
On Fri, 14 Nov 2014, Ian Jackson wrote:
What exactly is your use case you feel this is essential for?
I think this discussion is in danger of going round in circles.
I'm going to leave it here and let Raphael get on with it.
I understand
On 12/11/14 22:07, Ron wrote:
I am also interested to hear more
about whatever the confusion was you had with this was when you
started working with Tollef's systemd repo that you mentioned
in the previous thread.
Having played with gitpkg some more, I'm reminded that the answer to
this is
On 13/11/14 14:04, Ron wrote:
I really do think that the names of the branches are actually going to
be the least of your worries here, unfortunately. Even with a naming
scheme that's widely adopted, things just aren't going to be that sort
of uniform outside of (a fairly large number of)
Simon McVittie s...@debian.org writes:
Having played with gitpkg some more, I'm reminded that the answer to
this is that unlike (AIUI) both gbp-pq and git-dpm, it did not meet my
assumption that the contents of the git tree were in a suitable form to
run dpkg-buildpackage and have a 3.0
On Sat, Nov 15, 2014 at 03:49:56PM -0200, Henrique de Moraes Holschuh wrote:
On Sat, 15 Nov 2014, Raphael Hertzog wrote:
On Fri, 14 Nov 2014, Ian Jackson wrote:
What exactly is your use case you feel this is essential for?
I think this discussion is in danger of going round in
On Fri, 14 Nov 2014, Ron wrote:
So I am a Kali Linux contributor. We use git repos to maintain all our
packages and we use git-buildpackage.
I guess the first question there is what were the arguments put forward
for deciding to 'standardise' on gbp? If there wasn't one, maybe that's
an
On Thu, 13 Nov 2014, Tobias Frost wrote:
One point came to my mind: NMUs
Can we maybe add some words what would be best practice to handle NMUs?
I think the current best practices are fine: the NMUer should send a
debdiff to the BTS. Maybe the patch doesn't apply on top of the
supplementary
On Thu, 13 Nov 2014, Bernhard R. Link wrote:
* Raphael Hertzog hert...@debian.org [14 22:26]:
Helper tools should usually rely on the output of `dpkg-vendor --query
vendor`
to find out the name of the current vendor. The retrieved string must be
converted to lower case. This allows
On Nov 14, Raphael Hertzog hert...@debian.org wrote:
This is just a proof that storing the patches as real commits is useful.
And that's the point of the patch-queue tag. Instead of having the patches
only as real commits in the local repository, they get pushed to the
public repository too
On Fri, Nov 14, 2014 at 11:25:36AM +0100, Raphael Hertzog wrote:
On Fri, 14 Nov 2014, Ron wrote:
So I am a Kali Linux contributor. We use git repos to maintain all our
packages and we use git-buildpackage.
I guess the first question there is what were the arguments put forward
for
Raphael Hertzog wrote:
On Thu, 13 Nov 2014, Bernhard R. Link wrote:
* Raphael Hertzog hert...@debian.org [14 22:26]:
Is using the vendor you use git on a good default for the vendor code
you are currently working on? In my experience those two are quite
unrelated.
Do you have a
Ron writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
Why include the epoch in tags at all?
Because we want to be able to tell not just which tag was which but
also what order they are in.
The only reason I excluded epoch from filenames is that it makes tools
like
Bernhard R. Link writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
Raphael Hertzog hert...@debian.org [14 22:26]:
...
When a Git tag needs to refer to a specific version of a Debian package,
the Debian version needs to be mangled to cope with Git's restrictions
On Fri, Nov 14, 2014 at 03:39:05PM +, Ian Jackson wrote:
Ron writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
Why include the epoch in tags at all?
Because we want to be able to tell not just which tag was which but
also what order they are in.
Right
On Fri, 14 Nov 2014, Ian Jackson wrote:
expect to find version numbers matching ^\d+\~, then anything matching
These are common enough for me to have not only seen,
but also used (in native packages, of course) them.
(But: Yes, epochs should belong into filenames, except
for filesystem naming
On Fri, Nov 14, 2014 at 11:56 AM, Raphael Hertzog hert...@debian.org wrote:
On Thu, 13 Nov 2014, Tobias Frost wrote:
One point came to my mind: NMUs
Can we maybe add some words what would be best practice to handle NMUs?
I think the current best practices are fine: the NMUer should send a
On Sat, 15 Nov 2014, Ron wrote:
On Fri, Nov 14, 2014 at 03:39:05PM +, Ian Jackson wrote:
Ron writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
Why include the epoch in tags at all?
Because we want to be able to tell not just which tag was which
On Fri, 14 Nov 2014, Richard Hartmann wrote:
On Fri, Nov 14, 2014 at 11:56 AM, Raphael Hertzog hert...@debian.org wrote:
On Thu, 13 Nov 2014, Tobias Frost wrote:
One point came to my mind: NMUs
Can we maybe add some words what would be best practice to handle NMUs?
I think the current
On Fri, Nov 14, 2014 at 03:13:30PM -0200, Henrique de Moraes Holschuh wrote:
On Sat, 15 Nov 2014, Ron wrote:
On Fri, Nov 14, 2014 at 03:39:05PM +, Ian Jackson wrote:
Ron writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
Why include the epoch in tags
Richard Hartmann writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
Can you at least suggest, not require, that the NMUer should also send
a link to a publicly available branch with the patch(es) which are
based on the packaging branch's correct tag? That makes
Thorsten Glaser writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
On Fri, 14 Nov 2014, Ian Jackson wrote:
expect to find version numbers matching ^\d+\~, then anything matching
These are common enough for me to have not only seen,
but also used (in native
Ron writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
Right, gitweb, cgit, gitk, etc. are all going to do exactly the same
thing, take them from the DAG of the repo. They are unlikely to care
about how the tag names would textually sort (and even less likely
Hi,
Henrique de Moraes Holschuh:
That said I did consider that side of it too, but I'm having a hard
time thinking of an example where you would actually care about
ordering the tags for some task. Do you have one that comes to mind?
The BTS needs it: it is the very base of
Hi,
Ian Jackson:
Worse, unless I'm mistaken, there are some current workflows which
involve subsequent uploads to the same suite not necessarily being
fast forwards.
Meh. Anybody whose upload depends on being able to force-push a branch
deserves to lose. (I'm talking about the general case
On Fri, Nov 14, 2014 at 05:43:49PM +, Ian Jackson wrote:
Ron writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
Right, gitweb, cgit, gitk, etc. are all going to do exactly the same
thing, take them from the DAG of the repo. They are unlikely to care
about
On Fri, 14 Nov 2014, Henrique de Moraes Holschuh wrote:
The BTS needs it: it is the very base of version-aware bug state
tracking. It builds the DAG by combining the DAGs extracted from the
Debian changelogs of each branch of the package, AFAIK.
Speaking of which, one of the long standing
Ron writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
Right, and like you already noted, there's potential for ambiguity
in tag names anyway once the illegal characters have been mangled.
Raphael is proposing an unambiguous mangling which deals with this
problem
* Raphael Hertzog hert...@debian.org [141114 12:34]:
On Thu, 13 Nov 2014, Bernhard R. Link wrote:
* Raphael Hertzog hert...@debian.org [14 22:26]:
Helper tools should usually rely on the output of `dpkg-vendor --query
vendor`
to find out the name of the current vendor. The
Hi,
Ian Jackson:
Thus, please don't try to shoehorn a divided workflow into this DEP.
Write your own.
I disagree with half of this but agree with the other half.
I think that the divided workflow should be documented in this DEP.
But I agree that those who like the divided workflow
[ I skip the more detailed discussions on naming conventions to
concentrate on your higher level questions for now ]
On Thu, 13 Nov 2014, Ron wrote:
Sure, I understood those were your goals.
What I haven't seen, and what I'm asking for, is an actual detailed
rationale describing the actual
I think you need to be more explicit about the implications for `3.0
(quilt)' format packages. Something like:
If the git tree contains debian/format specifying `3.0 (quilt)',
the git tree must also contain debian/patches/series and all the
patch files contained within it.
On Tue, 11 Nov 2014, Raphael Hertzog wrote:
First, I'm a fan of trying to ease the workflow for all by having some
standardisation / best-practice recommendation/documentation.
Kudos to the initiattors!
QUESTION: some people have argued to use debian/master as the latest
packaging targets
2014-11-12 10:28 GMT+01:00 Raphael Hertzog hert...@debian.org:
On Wed, 12 Nov 2014, Mathieu Parent wrote:
OK. Makes sense. The unstripped upstream can then live in an
non-namespaced branch if needed (this is not my usual workflow but should be
possible).
On Wed, 12 Nov 2014, Mathieu Parent
Le 12/11/2014 12:25, Raphael Hertzog a écrit :
Hi,
On Wed, 12 Nov 2014, Thibaut Paumard wrote:
I see nothing about whether the debian branch should contained the
unpacked or the unpacked *and* patched sources, and whether to ship the
.pc directory.
That's a volunteer choice at this
On Thu, Nov 13, 2014 at 09:46:13AM +0100, Raphael Hertzog wrote:
[..snip..]
Well git-buildpackage obviously needs quite some update:
- it complains when you're trying to build as soon as you're not in a
branch named master (that can be overridden with --git-ignore-branch
or setting
Thibaut Paumard writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
[patches applied vs unapplied]
However, we should perhaps strongly recommend that this choice be
documented in debian/README.sources.
I think it would be better to document this by the use
Tobias Frost writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
[Ian:]
And you should add:
The packaging branch should not contain a `.pc' directory.
Maybe I got the above wrong: you mean patch applied after e.g
quilt push -a ? I think, removing .pc
Hi,
Thibaut Paumard:
We have a very nice source package format with 3.0 (quilt).
IMHO this format is very nice if you have some opaque upstream,
and a debian/ directory that's under your control.
This restriction does not apply to a DVCS like git. Moreover, git already
has built-in mechanisms
On Thursday, November 13, 2014 01:32:04 Sam Hartman wrote:
Hi.
I've read the original proposal and believe it is generally going in the
right direction.
things I liked:
* didn't pick between dgit/git-dpm/git-pq; documented the common parts
* Seemed to really focus on one clear scope.
On Thu, Nov 13, 2014 at 09:46:13AM +0100, Raphael Hertzog wrote:
[ I skip the more detailed discussions on naming conventions to
concentrate on your higher level questions for now ]
Agreed, if we solve the tricky problems, that part is mostly just
yak shaving (and if we can't, it's probably
Hi,
I think the only workflow that newcomers and NMUers should be required
to learn is the one that involves quilt, they should not be expected to
learn (e.g.) dgit in addition. [...]
I certainly don't think people should be expected to learn dgit in
addition to other tools. I am trying
On Nov 13, Raphael Hertzog hert...@debian.org wrote:
I am part of the Python Modules team who wants to switch to git but not
all contributors are using the same git helper tools and yet we would like
to all work together on the same repositories without forcing everybody
to use the same
* Raphael Hertzog hert...@debian.org [14 22:26]:
Helper tools should usually rely on the output of `dpkg-vendor --query vendor`
to find out the name of the current vendor. The retrieved string must be
converted to lower case. This allows users to override the current vendor
by setting
On Tue, Nov 11, 2014 at 10:51 PM, Henrique de Moraes Holschuh
h...@debian.org wrote:
Please allow debian/master as an alternative. It fits with the general git
usage of master, it fits with the workflow of several packages, where you
do experimental-unstable, and it is not going to surprise
On Wed, Nov 12, 2014 at 4:04 AM, Marco d'Itri m...@linux.it wrote:
Whatever the decision will be on debian/master, I think that master
should be at the very least an option.
I.e. a debian-only repo? That's what pabs also seems to prefer so it
probably makes sense to support/allow both.
FWIW, I
On Wed, Nov 12, 2014 at 01:13:39AM +0100, Matthias Urlichs wrote:
Please discourage the use of pristine-tar. The format is fragile and can
suffer from bit rot.
I am not personally interested in pristine-tar, but I don't think this is the
right place to take a stance on its use.
--
To
On Wed, Nov 12, 2014 at 03:38:59PM +0800, Paul Wise wrote:
Personally I wouldn't use anything other than debian-only repos, at
least for those where I have a choice. I also actively avoid
contributing to packages that don't use such repos.
And I'm the exact opposite.
--
To UNSUBSCRIBE,
Jonathan == Jonathan Dowland j...@debian.org writes:
Jonathan On Wed, Nov 12, 2014 at 03:38:59PM +0800, Paul Wise wrote:
Personally I wouldn't use anything other than debian-only repos, at
least for those where I have a choice. I also actively avoid
contributing to packages
Hi,
On Tue, 11 Nov 2014, Iustin Pop wrote:
Packaging branches and tags
===
Packaging branches should be named according to the codename of the
target distribution. In the case of Debian, that means for example
`debian/sid`, `debian/jessie`,
Hi,
Jonathan Dowland:
On Wed, Nov 12, 2014 at 01:13:39AM +0100, Matthias Urlichs wrote:
Please discourage the use of pristine-tar. The format is fragile and can
suffer from bit rot.
I am not personally interested in pristine-tar, but I don't think this is the
right place to take a stance
On Wed, 12 Nov 2014, Matthias Urlichs wrote:
If the package maintainers use the pristine-tar tool to efficiently store
a byte-for-byte copy of the upstream tarballs, this should be done in the
`pristine-tar` branch.
Please discourage the use of pristine-tar. The format is fragile and can
Paul Wise p...@debian.org writes:
On Wed, Nov 12, 2014 at 3:34 PM, Gergely Nagy wrote:
I'd like to note that there are very good reasons for a debian-only,
overlay-style packaging repository too. This section should, in my
opinion, at least acknowledge that, and briefly mention it as an
On Tue, 11 Nov 2014, Henrique de Moraes Holschuh wrote:
In fact, I was quite non-amused by the initial versions of this idea, but
reading this latest version, I must say I *like* it. Well done! I am
especially happy about the way it respects the usual git usage conventions,
this will ease
On Tue, 11 Nov 2014, Barry Warsaw wrote:
One question: when this gets adopted, will individual maintainers or teams
have to know which of the git packaging helpers a particular repository is
using? IOW, what happens if I were to use gbp-pq on a package that someone
else had used git-dpm on?
[ Ccing the maintainers of git packaging helper tools ]
Hi Scott,
using your mail as an opportunity to explicity notify the respective
package maintainers of this ongoing DEP.
Guido, Bernhard, Ron, if you are not reading debian-devel, I would
like to bring your attention to a discussion that I
On Wed, 12 Nov 2014, Mathieu Parent wrote:
A paragraph about repacked upstream is needed. A lot of packages are
currently stripped for minified JS, non-free additions, included RFCs,
... What would the upstream/1.x branch be then? Maybe add an
upstream/1.x+debian branch?
Yeah, that was
Hi Gergely,
On Wed, 12 Nov 2014, Gergely Nagy wrote:
Raphael When releasing a Debian package, the packager should create and
push
Raphael a signed tag named `vendor/version`. For example, a Debian
maintainer
Raphael releasing a package with version 2:1.2~rc1-1 would create a
On Wed, Nov 12, 2014 at 10:02 AM, Raphael Hertzog hert...@debian.org wrote:
for the current Ubuntu development series. If I needed to support older
releases in either distro, then debian/wheezy or ubuntu/utopic would be good
branches to use. (Or IOW, what's the equivalent of debian/sid for
2014-11-12 10:28 GMT+01:00 Raphael Hertzog hert...@debian.org:
On Wed, 12 Nov 2014, Mathieu Parent wrote:
A paragraph about repacked upstream is needed. A lot of packages are
currently stripped for minified JS, non-free additions, included RFCs,
... What would the upstream/1.x branch be
Hi!
On Wed, 2014-11-12 at 15:38:59 +0800, Paul Wise wrote:
On Wed, Nov 12, 2014 at 3:34 PM, Gergely Nagy wrote:
I'd like to note that there are very good reasons for a debian-only,
overlay-style packaging repository too. This section should, in my
opinion, at least acknowledge that, and
Le 11/11/2014 22:26, Raphael Hertzog a écrit :
Hello,
following the initial discussion we had in August
(https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have
written a first draft of the Debian Enhancement Proposal that I suggested.
It's now online at
On Tue, 11 Nov 2014, Raphael Hertzog wrote:
QUESTION: some people have argued to use debian/master as the latest
packaging targets sometimes sid and sometimes experimental. Should we
standardize on this? Or should we explicitly allow this as an alternative?
Given the feedback received,
Hi,
On Wed, 12 Nov 2014, Thibaut Paumard wrote:
I see nothing about whether the debian branch should contained the
unpacked or the unpacked *and* patched sources, and whether to ship the
.pc directory.
I personally ship the unpatched sources and don't ship the .pc directory.
That's a
Hi Raphael,
On Wed, Nov 12, 2014 at 10:15:27AM +0100, Raphael Hertzog wrote:
Hi Scott,
using your mail as an opportunity to explicity notify the respective
package maintainers of this ongoing DEP.
Guido, Bernhard, Ron, if you are not reading debian-devel, I would
like to bring your
On 12/11/14 05:54, Mathieu Parent wrote:
Also, the vendor/* branches heads should be at a descendent commit of
the corresponding upstream branch, diffing only by the debian dir.
This is only true for workflows similar to the one normally used with
gbp-pq, in which desired patches are serialized
Hi Ron,
On Wed, 12 Nov 2014, Ron wrote:
I think you probably need to be careful of overspecifying this.
Definitely. That's precisely why I don't want to dwelve (too much)
into details of the various workflows and why I try to restrict
the DEP at simple naming conventions for branches and tags
On Wed, 12 Nov 2014, Mathieu Parent wrote:
Maybe a short note would be good then? (but I don't know how to write it).
I suggest this:
--- a/web/deps/dep14.mdwn
+++ b/web/deps/dep14.mdwn
@@ -230,6 +230,17 @@ non-patchable data), you can do so but you should then
document
this in
Hi,
Simon McVittie:
Is it the intention of this DEP to mandate the gbp-pq-like repo
structure, which basically forbids use of tools whose design does not
match that? Or is the intention to set some conventions that can be true
regardless of whether you are using a more gbp-pq-like or more
On 12/11/14 13:38, Matthias Urlichs wrote:
IMHO there are two basic approaches which are mostly at odds with
each other.
I think there are at least three.
Two: Treat Upstream tarballs as Source Code; if Upstream generates
them from git-or-whatever, that's not our problem. Use a script to
Raphael Hertzog writes (RFC: DEP-14: Recommended layout for Git packaging
repositories):
following the initial discussion we had in August
(https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have
written a first draft of the Debian Enhancement Proposal that I suggested.
It's
Barry Warsaw writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
On Nov 11, 2014, at 10:26 PM, Raphael Hertzog wrote:
Vendor namespaces
-
Each vendor uses its own namespace for its packaging related
Git branches and tags: `debian/*` for Debian
Raphael Hertzog writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
The DEP will neither encourage and discourage its use. It only mentions
that if a maintainer is using it, it should store pristine-tar data
in the pristine-tar branch.
Would it be worth mentioning
1 - 100 of 141 matches
Mail list logo
