Re: Centralized darcs
Josselin Mouette writes (Re: Centralized darcs): Maybe you shouldn't assume all people who like to code and debug aren't clueful enough to run diff. Putting my changes in a patch is the most useful way to integrate them in a Debian package *and* to forward them upstream. It is far less complex than using a VCS specifically for this task, and it is the way that takes less time overall. You seem to have misunderstood me as saying that I prefer packages where the source code is in VCSs. For NMUs or local changes or derived distros, you _don't care_ whether the source is in a VCS or not because in general you have no access to that VCS repository and because you don't have time to learn ten or so different VCS's so you probably don't know how to use the one the maintainers chose. What I need as someone working on a package for which I'm not the maintainer is this: dpkg-source -x must give me something I can immediately edit and diff on the resulting tree after I've edited and built it must produce a sane patch. So debian/rules build must not edit any source files. This is the supposedly universal interface for Debian packages, which the rest of us (ie, people not the package maintainer) are relying on. It is my opinion that packages where dpkg-source -x doesn't produce the source that actually gets compiled are in violation of policy. Did you read the contortions in my previous posting ? Obviously I know how to use diff. The problem is that with patch systems I _can't_ just apply my universal knowledge about dpkg-source and diff and so forth. I have to learn about and usually fight with the patch system too. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
Russ Allbery writes (Re: Centralized darcs):
In my experience, the key difference between whether or not I want to use
a patch system like quilt is whether I have an upstream to which I need to
feed self-contained patches that may go unapplied for extended periods of
time. When I'm in that situation, I need to maintain that separate change
in a self-contained file into which I can put notes about the status of
merging with upstream and which I can forward-port *as an independent
change* to new releases of the upstream software so that I can then push
it to upstream again.
I don't think I've encountered any quilted packages. When I say
dpkg-source -x, do I get the patched or the unpatched source ? What
happens if I do this
dpkg-source -x /mirror/program.dsc
cp -a program-1.2 program-1.2.unedited
emacs program-1.2/src/program.c
(cd program-1.2 debian/rules build fakeroot debian/rules binary)
really dpkg -i program_1.2-1_i386.deb
program --test-mode
diff -ru program-1.2{.unedited,} diff
and send you (as maintainer) the diff ?
If the answer is `it works just fine' then obviously I don't care and
I probably won't even notice.
Note that there are ways of dealing with the situation you describe
above which don't break the standard model. For example, you could
have the .diff.gz specify the _patched_ source and store the patches
separately in debian/patches. Every diff would appear twice but this
is not usually a big problem. Someone who didn't know about your
patch system would just produce a working package and a reasonable
diff to send to the BTS (if it's not just a local change), and you as
maintainer can do the patch system integration when you include it.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
Ian Jackson [EMAIL PROTECTED] writes:
Russ Allbery writes (Re: Centralized darcs):
In my experience, the key difference between whether or not I want to
use a patch system like quilt is whether I have an upstream to which I
need to feed self-contained patches that may go unapplied for extended
periods of time. When I'm in that situation, I need to maintain that
separate change in a self-contained file into which I can put notes
about the status of merging with upstream and which I can forward-port
*as an independent change* to new releases of the upstream software so
that I can then push it to upstream again.
I don't think I've encountered any quilted packages. When I say
dpkg-source -x, do I get the patched or the unpatched source ? What
happens if I do this
dpkg-source -x /mirror/program.dsc
cp -a program-1.2 program-1.2.unedited
emacs program-1.2/src/program.c
(cd program-1.2 debian/rules build fakeroot debian/rules binary)
really dpkg -i program_1.2-1_i386.deb
program --test-mode
diff -ru program-1.2{.unedited,} diff
and send you (as maintainer) the diff ?
quilt doesn't automatically apply the patches when you unpack the source,
like all the patch management software, so this works if and only if your
changes don't cause any of the other patches to fail.
I agree that it would be nice to have dpkg-source just do the right thing.
The best way to get there from here, I think, would be to provide some way
for quilt to transform its patches into dpkg-v2 patches in the package,
which would then be applied automatically. This is easier to do with
quilt than with dpatch.
Note that there are ways of dealing with the situation you describe
above which don't break the standard model. For example, you could have
the .diff.gz specify the _patched_ source and store the patches
separately in debian/patches. Every diff would appear twice but this is
not usually a big problem. Someone who didn't know about your patch
system would just produce a working package and a reasonable diff to
send to the BTS (if it's not just a local change), and you as maintainer
can do the patch system integration when you include it.
That's an interesting idea. I can't see an obvious problem with it after
a few minutes of thought, other than making it a bit harder to deal with a
quilt-using package inside a revision control system, and that could be
automated.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
Le mercredi 09 août 2006 à 11:12 +0100, Ian Jackson a écrit : Did you read the contortions in my previous posting ? Obviously I know how to use diff. The problem is that with patch systems I _can't_ just apply my universal knowledge about dpkg-source and diff and so forth. I have to learn about and usually fight with the patch system too. This is where I disagree with you. I've met at least 3 different patch systems only in GNOME packages, and there was nothing to learn or to fight against. Their behavior is totally obvious. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Centralized darcs
On Wed, Aug 09, 2006 at 06:53:08AM -0700, Russ Allbery wrote: Ian Jackson [EMAIL PROTECTED] writes: [...] Note that there are ways of dealing with the situation you describe above which don't break the standard model. For example, you could have the .diff.gz specify the _patched_ source and store the patches separately in debian/patches. Every diff would appear twice but this is not usually a big problem. Someone who didn't know about your patch system would just produce a working package and a reasonable diff to send to the BTS (if it's not just a local change), and you as maintainer can do the patch system integration when you include it. That's an interesting idea. I can't see an obvious problem with it after a few minutes of thought, other than making it a bit harder to deal with a quilt-using package inside a revision control system, and that could be automated. I tried months ago but failed, so I am very interested if someone has a clean solution. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wed, Aug 09, 2006 at 11:12:15AM +0100, Ian Jackson wrote: What I need as someone working on a package for which I'm not the maintainer is this: dpkg-source -x must give me something I can immediately edit and diff on the resulting tree after I've edited and built it must produce a sane patch. So debian/rules build must not edit any source files. This is the supposedly universal interface for Debian packages, which the rest of us (ie, people not the package maintainer) are relying on. It is my opinion that packages where dpkg-source -x doesn't produce the source that actually gets compiled are in violation of policy. In every single patch system I've encountered, you can run debian/rules patch and get the patched source. It's only one more command and I consider it universal for all patch systems deployed in Debian. Admittedly, I do few NMU's though, so I could be missing things. But I did investigate a large number of patch systems for use with xorg and they all had this in common. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
In every single patch system I've encountered, you can run debian/rules patch and get the patched source. It's only one more command and I consider it universal for all patch systems deployed in Debian. In some cases, this will fail if you don't have the build-dependencies installed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wed, Aug 09, 2006 at 08:14:43PM +, David Nusinow wrote: On Wed, Aug 09, 2006 at 11:12:15AM +0100, Ian Jackson wrote: What I need as someone working on a package for which I'm not the maintainer is this: dpkg-source -x must give me something I can immediately edit and diff on the resulting tree after I've edited and built it must produce a sane patch. So debian/rules build must not edit any source files. This is the supposedly universal interface for Debian packages, which the rest of us (ie, people not the package maintainer) are relying on. It is my opinion that packages where dpkg-source -x doesn't produce the source that actually gets compiled are in violation of policy. In every single patch system I've encountered, you can run debian/rules patch and get the patched source. It's only one more command and I consider it universal for all patch systems deployed in Debian. dbs doesn't have it. It also isn't mentioned as a best practice *anywhere* I can find that people might commonly look, so it isn't immediately obvious to people who might decide to roll their own next time. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs (was Re: centralized bzr)
* John Goerzen wrote: Darcs has a nice way of pushing patches via e-mail, with GPG signatures even. That's the only feature I miss after I switched from darcs to mercurial. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs (was Re: centralized bzr)
On 06/08/06, Norbert Tretkowski [EMAIL PROTECTED] wrote: * John Goerzen wrote: Darcs has a nice way of pushing patches via e-mail, with GPG signatures even. That's the only feature I miss after I switched from darcs to mercurial. Norbert At last someone mentions mercurial. This is a personal (developer/programmer, and packager) (idiosyncratic) use case: I tend to use darcs with darcs build package for debian builds. But mercurial is so easy to set up and convenient to use, i end up using it for both macro and micro development purposes, ... (mercurial takes care of programming needs, darcs packaging) If the darcs repository is contained with the directory ./foo-1.0.1/_darcs then that would be kept within a mercurial repository at ./.hg and all trivial development changes, interim and otherwise are tracked at that level the .hg repository including the contents of _darcs. (this making mercurial the macro and micro manager) darcs commits and tagging occur only when the debian package is to be built. mercurial is fast, and pleasure to use. darcs and mercurial, the ones that i want (and both). Ralph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
I demand that Matthew Palmer may or may not have written... I've given up on this thread, but I just have to say one thing: On Sat, Aug 05, 2006 at 11:38:39AM +0300, George Danchev wrote: `Hate patch systems' can easily apply all chunks and start BWAHAHAHAHAHAHAHAHAHAHA! Easily. Heh. You should be a comedian. Actually, yes, it *should* be easy: debian/rules patch. Bwahahaha, as they say. :-) -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + At least 4000 million too many people. POPULATION LEVEL IS UNSUSTAINABLE. Ehm... out of the top of the screen! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs (was Re: centralized bzr)
* Norbert Tretkowski wrote: * John Goerzen wrote: Darcs has a nice way of pushing patches via e-mail, with GPG signatures even. That's the only feature I miss after I switched from darcs to mercurial. I just realized that this feature is implemented in the patchbomb extension, which is part of mercurial since 0.8.1. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Sun, Aug 06, 2006 at 01:52:09PM +0100, Darren Salt wrote: I demand that Matthew Palmer may or may not have written... I've given up on this thread, but I just have to say one thing: On Sat, Aug 05, 2006 at 11:38:39AM +0300, George Danchev wrote: `Hate patch systems' can easily apply all chunks and start BWAHAHAHAHAHAHAHAHAHAHA! Easily. Heh. You should be a comedian. Actually, yes, it *should* be easy: debian/rules patch. I can't see any mention of that target in Policy. Am I looking at a badly outdated version? (3.7.2.0, 2006-05-04). It also fails to work on a split-patch package I've been working on over the weekend (just to renew my hatred of such systems). Should I be filing a serious bug against that package? Even the devref, s6.1, fails to make the slightest mention (let alone recommendatation) as to a target to provide. Even the two patch systems it does mention don't provide a common interface to such a common and necessary task. Can you provide an authoritative reference which documents the universal necessity of a patch target to debian/rules? Or are you, perhaps, taking the convention of a single patch management system and ass-u-ming that it works across the board, when it, most assuredly, does not? Bwahahaha, as they say. :-) Yep, I certainly do say that. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
I demand that Matthew Palmer may or may not have written... On Sun, Aug 06, 2006 at 01:52:09PM +0100, Darren Salt wrote: I demand that Matthew Palmer may or may not have written... I've given up on this thread, but I just have to say one thing: On Sat, Aug 05, 2006 at 11:38:39AM +0300, George Danchev wrote: `Hate patch systems' can easily apply all chunks and start BWAHAHAHAHAHAHAHAHAHAHA! Easily. Heh. You should be a comedian. Actually, yes, it *should* be easy: debian/rules patch. I can't see any mention of that target in Policy. Am I looking at a badly outdated version? (3.7.2.0, 2006-05-04). I'd say not :-) It seems like a reasonable good practice starting point to me, given that patch and unpatch targets are present if the source package uses dpatch, i.e. the rules file includes /usr/share/dpatch/dpatch.make. It also fails to work on a split-patch package I've been working on over the weekend (just to renew my hatred of such systems). Should I be filing a serious bug against that package? No. Wishlist at worst. The one which *I* hate is the tarball-within-tarball one: whenever I've seen that one (rarely), I've normally tried debian/rules extract, watched it fail, read the rules file, then grumbled about apparent non-obviousness of target choice. ... actually, debian/rules patch fails on one package for which I recently provided a patch. But it did provide the opportunity to have a brief look at quilt... [snip] Or are you, perhaps, taking the convention of a single patch management system and ass-u-ming that it works across the board, when it, most assuredly, does not? Probably... but then I'm sure that whoever came up with unpack as a target for extracting the files from a tarball ass-u-med that everybody else would be thinking the same way. ;-) Hee-haw, as they say. [snip] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Buy less and make it last longer. INDUSTRY CAUSES GLOBAL WARMING. Avert misunderstanding by calm, poise, and balance. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
Ian Jackson [EMAIL PROTECTED] writes: I think this is the root of the key difference between the `like patch systems' people and the `hate patch systems' people. `Hate patch systems' people are those who can read code, and prefer programming and debuggint to doing archaelogy. Oh brother, cut out the silly flamebait. Patch systems and SCMs have different strengths and weaknesses; which one works best depends on the task at hand. I use, and don't-hate [*], both, in different situations. [*] Not really like... dealing with maintenance stuff, whether SCM branches or maintaining patch sets, is usually annoying and fickle no matter what you do, but makes life easier in the long run; I like those things that maximize the utility/pain ratio. -miles -- Suburbia: where they tear out the trees and then name streets after them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Friday 04 August 2006 14:58, Ian Jackson wrote: Matthew Palmer writes (Re: Centralized darcs): diff.gz archaeology should not be necessary. I think this is the root of the key difference between the `like patch systems' people and the `hate patch systems' people. In my opinon the root of the key differences is that with patch systems you can have it both ways: a) all chunks in one big diff b) chunks clearly separated by issue Obviously the patch system is an addition to the VCS, so one can live without the underlaying VCS used in a given case. `Hate patch systems' people are those who can read code, and prefer programming and debuggint to doing archaelogy. They're people like me: my first approach to any bug I'm trying to fix (or change I'm trying to make) is to read and then edit the actual code. Only if I seem to be explicitly going against some other person's decision, or the whole thing seems crazy, will I try to find some archaeology or Seems like you will find clearly separated chunks useful sometimes. changelog or something in an effort to find out why it was done the crazy way. `Hate patch systems' can easily apply all chunks and start reading/digging/hacking on the top of that, while separated chunks are close at hand for any reference. `Like patch systems' people are those who would prefer to do archaelogy to dealing with the actual code of a program written by someone else. These are people for whom the average level of clue in the world as represented by the history of the program and other people's patches exceeds their own ability to generate correct changes to the code. The resulting culture is one of `cargo culting' patches and `explanations' from one place to another, without really understanding them. `Like patch systems` people can go either way as they find fit, although turning back all chunks into a combined fashion is a regression, because you can't have it both ways anymore. Given that I think your definitions wrt `like and hate patch systems people` could be easily swapped and still be true, thus making such sort of discriminations fairly irrelevant. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
I've given up on this thread, but I just have to say one thing: On Sat, Aug 05, 2006 at 11:38:39AM +0300, George Danchev wrote: `Hate patch systems' can easily apply all chunks and start BWAHAHAHAHAHAHAHAHAHAHA! Easily. Heh. You should be a comedian. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
Le vendredi 04 août 2006 à 12:58 +0100, Ian Jackson a écrit : `Hate patch systems' people are those who can read code, and prefer programming and debuggint to doing archaelogy. They're people like me: my first approach to any bug I'm trying to fix (or change I'm trying to make) is to read and then edit the actual code. Maybe you shouldn't assume all people who like to code and debug aren't clueful enough to run diff. Putting my changes in a patch is the most useful way to integrate them in a Debian package *and* to forward them upstream. It is far less complex than using a VCS specifically for this task, and it is the way that takes less time overall. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Centralized darcs
On Sat, Aug 05, 2006 at 11:38:39AM +0300, George Danchev wrote: In my opinon the root of the key differences is that with patch systems you can have it both ways: a) all chunks in one big diff b) chunks clearly separated by issue Obviously the patch system is an addition to the VCS, so one can live without the underlaying VCS used in a given case. Huh? Storing patches on SCM is one of the issues that annoys *me* about having a patch system in addition to VCS. This blows also in the archeology sense. Comparing versions in VCS is harder when you are actually looking at diffs of diffs. Seems like you will find clearly separated chunks useful sometimes. Yes, however the fact that we have almost a dozen of different patch systems (not including the package-specific NIH systems) pretty much negates any potential advantage. Having it either way, centralized SCM like Ubuntu or standardized patch system like RPM would so much rule over the complete lack of coherancy we have now.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Saturday 05 August 2006 18:52, Riku Voipio wrote: On Sat, Aug 05, 2006 at 11:38:39AM +0300, George Danchev wrote: In my opinon the root of the key differences is that with patch systems you can have it both ways: a) all chunks in one big diff b) chunks clearly separated by issue Obviously the patch system is an addition to the VCS, so one can live without the underlaying VCS used in a given case. Huh? Storing patches on SCM is one of the issues that annoys *me* about having a patch system in addition to VCS. This blows also in the archeology sense. Comparing versions in VCS is harder when you are actually looking at diffs of diffs. I see your point wrt 'diffs of diffs' issue, but you bear in mind that you should deal with people who do not use your SCM for any reason, most notably upstream. Seems like you will find clearly separated chunks useful sometimes. Yes, however the fact that we have almost a dozen of different patch systems (not including the package-specific NIH systems) pretty much negates any potential advantage. True. Having different patch systems is a different issue to discuss. Should it be used only one patch system, which one, and why, are all open questions, and I'm afraid I handly can give an ultimate answer to this one, since there are different people with different views and preferences. Having it either way, centralized SCM like Ubuntu or standardized patch system like RPM would so much rule over the complete lack of coherancy we have now.. Another example [1]: FreeBSD's Ports collection (where FreeBSD is not upstream) is also kept under VCS, and diffs to upstream code are kept in separate files (patches) in the very same VCS. Well, yes they use just one method to produce these patches. This is also true for other BSD's. [1]http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/slow-patch.html -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Thu, 3 Aug 2006 15:41:32 +0100, Jon Dowland [EMAIL PROTECTED] wrote: At 1154593998 past the epoch, Eduard Bloch wrote: And you can do all that with dpatch-edit-dpatch and the regular Unix commands without learning another VCS and/or without needing access to it. Advantage? Yes. Someone is more likely to know a particular VCS than an in-house tool like dpatch, I reckon, and that skillset is going to be more useful and applicable in other contexts as well. A few years ago, we had only CVS, which sucked. And now, we have a gazillion of different VCSes, all different. I am not sure which of these two situations is worse. Greetings Marc, who is happy with a combination of svn and dpatch -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Centralized darcs
Marc Haber [EMAIL PROTECTED] writes: A few years ago, we had only CVS, which sucked. And now, we have a gazillion of different VCSes, all different. And most of them suck too, in their own ways. -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
Romain Francoise [EMAIL PROTECTED] writes: A few years ago, we had only CVS, which sucked. And now, we have a gazillion of different VCSes, all different. And most of them suck too, in their own ways. Yup... and you just _know_ whichever one ends up winning will not be the best by most measures, it will be the one that's good enough and has a nice website... :-( -Miles -- The secret to creativity is knowing how to hide your sources. --Albert Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
Matthew Palmer writes (Re: Centralized darcs):
diff.gz archaeology should not be necessary.
I think this is the root of the key difference between the `like patch
systems' people and the `hate patch systems' people.
`Hate patch systems' people are those who can read code, and prefer
programming and debuggint to doing archaelogy. They're people like
me: my first approach to any bug I'm trying to fix (or change I'm
trying to make) is to read and then edit the actual code. Only if I
seem to be explicitly going against some other person's decision, or
the whole thing seems crazy, will I try to find some archaeology or
changelog or something in an effort to find out why it was done the
crazy way.
`Like patch systems' people are those who would prefer to do
archaelogy to dealing with the actual code of a program written by
someone else. These are people for whom the average level of clue in
the world as represented by the history of the program and other
people's patches exceeds their own ability to generate correct changes
to the code. The resulting culture is one of `cargo culting' patches
and `explanations' from one place to another, without really
understanding them.
When I work on Ubuntu packages I'm basically doing NMUs all the time
and I have been forced into a completely insane workflow to deal with
the mad patch systems:
$ dpkg-source -x /export/mirror/.../program.dsc
$ mkdir orig build
$ rsync -a --delete --delete-excluded --exclude='*~' program orig/
$ rsync -a --delete --delete-excluded --exclude='*~' program build/
$ (cd build/program debian/rules build debian/rules binary)
now edit build/program/stupid/long/path/src/program.c to make
the bulk of my changes
test the resulting program in the build tree if possible
if I'm very lucky then I can edit program.c and
$ make -C build/program/stupid/long/path/src program
if I make a change but sometimes this is not possible and I have
to resort to the process below
$ diff -u build/program/stupid/long/path/src/program.c{~,} \
program/debian/patches/999_my_new_patch
now edit program/debian/patches/999_my_new_patch
$ grep -R 888_some_existing_patch program
this tells me whether 888_some_existing_patch needs to be added
to a list of patches and if so I edit the list file
also edit program/debian/changelog
$ rsync -a --delete --delete-excluded --exclude='*~' program build/
$ (cd build/program debian/rules build debian/rules binary)
not that this is a complete rebuild. I use ccache.
$ really dpkg -i program.deb
run test
if test does not work, edit 999_my_new_patch and rebuild from scratch
if test does work
$ diff -ruN --exclude='*~' {orig/,}program diff
and send diff to bug system.
This is incredibly clumsy but it has the virtue of being reliable and
not requiring me to learn dmadpatch 0.37 as distributed in program
0.0.0.3 from 1999 and not having to deal with any bugs in patch
systems etc.
But, FFS!
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Thu, Aug 03, 2006 at 11:23:43AM +0100, martin f krafft wrote: also sprach Lars Wirzenius [EMAIL PROTECTED] [2006.08.03.1116 +0100]: Debian's lists support List-ID, List-Post, and the other List- headers. If mutt's L command doesn't use that to figure out the list reply address, perhaps someone would be so kind as to write a suitable patch? (That's what evolution's control-L seems to cue in on, fwiw.) It sure works, but you have to let mutt know about it: subscribe debian-devel@lists.debian.org That's a *good* thing. Err, no you don't ;) Mutt really does use the list headers these days - that's a throw back to the dark ages^W^WWoody - sarges mutt does list correctly with L :) Cheers, -- Brett Parker -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
Ian Jackson [EMAIL PROTECTED] writes: I think this is the root of the key difference between the `like patch systems' people and the `hate patch systems' people. In my experience, the key difference between whether or not I want to use a patch system like quilt is whether I have an upstream to which I need to feed self-contained patches that may go unapplied for extended periods of time. When I'm in that situation, I need to maintain that separate change in a self-contained file into which I can put notes about the status of merging with upstream and which I can forward-port *as an independent change* to new releases of the upstream software so that I can then push it to upstream again. It's possible that some of the revision control packages can do this, but an advantage to using quilt is that its resulting artifacts are in a very simple and easy-to-see form that other people working on the package can maintain and that I can easily mail to upstream or copy to a web page without having to script something inside the revision control system. I find this useful. I currently maintain some packages in this situation with quilt and some packages in this situation with svk letting the revision control system do the work. I've found that, in the latter case, I end up having to extract the patches out of svk and store them separately *anyway* in order to do upstream merges, and in general svk makes me less happy than quilt for every operation except merging with a new upstream release. On the other hand, it makes me fairly happy when doing the latter. I'm not sure if the tradeoff is worth it. After every upstream merger, I have to review every patch applied to the package *anyway* to make sure that it's still sane, and I find that easier to do by reading through the contents of debian/patches than by running filterdiff on diff.gz and then trying to work through the intermingled results of multiple changes. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
Otavio Salvador [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] writes: After every upstream merger, I have to review every patch applied to the package *anyway* to make sure that it's still sane, and I find that easier to do by reading through the contents of debian/patches than by running filterdiff on diff.gz and then trying to work through the intermingled results of multiple changes. If you were using one branch to each logical unit patch you might merge the new upstream against it and then merge all together again in a new release branch that you upload. That might looks like: branches upstream fix-bug-N fix-bug-M add-feature-X debian So every new upstream release you merge it against each fix and add branch. Then those against debian/. Should work well. Yeah, that would get me some of the support for upstream merges that I like from svk, but I'm not sure that the additional level of work is worth it, particularly given that the structure would only be available to people who use the repository. I'm sure that there are revision control systems that make the above simple and painless, but conceptually it's complicated and sounds annoying to deal with compared to something simple like quilt. One of the things I really like about using quilt is that all of the structure I use when maintaining the package is available to anyone who wants to work on it. The only thing you lose without access to my repository is the revision history, not the actual tools for creating new packages. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
Russ Allbery [EMAIL PROTECTED] writes: After every upstream merger, I have to review every patch applied to the package *anyway* to make sure that it's still sane, and I find that easier to do by reading through the contents of debian/patches than by running filterdiff on diff.gz and then trying to work through the intermingled results of multiple changes. If you were using one branch to each logical unit patch you might merge the new upstream against it and then merge all together again in a new release branch that you upload. That might looks like: branches upstream fix-bug-N fix-bug-M add-feature-X debian So every new upstream release you merge it against each fix and add branch. Then those against debian/. Should work well. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wed, Aug 02, 2006 at 04:16:30PM -0500, John Goerzen [EMAIL PROTECTED] wrote: On Wed, Aug 02, 2006 at 08:31:29PM +0200, Eduard Bloch wrote: Really, I think that getting patches in darcs from people that are using darcs send is not only easier for me as a maintainer, but also easier Much easier as storing the mail attachment under debian/patches? I doubt. Yes, indeed it is. darcs send will send each original darcs record as a discrete change. darcs apply can run in an interactive mode to let the person approve (or not) each individual patch. The full commit log from the original person also comes along automatically. AND, there's no need to hack the Debian build infrastructure. for them as contributors. Plus it is really easy for people that don't grok darcs to just use normal tools to edit Debian source packages, create diffs, NMU packages, or whatever -- and for me to integrate their changes later. This is not the case for the other special-purpose patch tools. This does not really differ from the scenarios with patch management system. Yes it does. If I don't understand patch tool X, I have to learn how to use patch tool X before I can even begin hacking. Nobody has to learn Darcs to hack on my packages. Well if someone has to work on a which of the applied patch broken the package is such a way kinda issue, he will have to, in order to have access to the patches. dpatch, quilt and others, in this case, make life easier (especially for security support). Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Thursday 03 August 2006 03:32, Matthew Palmer wrote: --cut-- This is fine, but (again) you forget about your 'apt-get source' users, which are not supposed to be aware of your SCM, where your repo is, please, find 'SCM' in the above row, thanks. I did. Using an SCM and shipping a monolithic diff.gz makes it *easier* for the 'apt-get source' user to work with the package, because there isn't a randomly-chosen debian patch manager in the way to confuse and confound. The very same debian patch manager clearly identifies patches you've produced against a certain upstream version and if I want to see the text of your diffs altering src/file.c|h|whatever, not just a mere changelog entry, I must track your SCM repo and its logs (learning a debian patch manager is certainly easier as compared to any SCM and there are certainly more SCM out there than debian patch managers). Why do I need to track your changes to the upstream code ? Probably because I want to be sure that you haven't added any offending changes or any other defects to the upstream source code when upstream claims that their branch is working properly. Now you want to kill that important information from the debian source package itself and make like of people even harded to find out your SCM, learn to use it and track down the changes made to the upstream branch. I don't find that very impresive, and I think Security Team will not be impressed too. source and why they have been applied. Which is it? Clearly identified patches, or not supposed to be aware? Obviously 'SCM' is what you missed above, which led you to such a confusion. Yes, people might be able to apt-get source and have patches which are to be (un)applied to the upstream source clearly identified without having to bother with any SCM to do the _patching_ work. (SCM == VCS) They don't have to know anything about the SCM to manipulate a monolithic diff.gz package. This is in contrast to a patch-managed package, where you *MUST* learn the patch management system to make a minimal, useful NMU patch. Seems like you don't consider clearly identified patches prepared against a given upstream version important, and (as you said in a previous message) a mere changelog entries should be enough for you. This is just a very interesting way of tracking changes ;-) I.e. if you have patches, do them debian way (using a debian patch system) Please identify the debian way, so I may start using it. Oh wait. There isn't any single Debian way. Never has been, almost certainly never will be. There is no signle SCM you can do packaging either. No, there isn't, but the difference is that the SCM doesn't get in your way. 'Tracking patches against the upstream branch without using your SCM, but the debian source package instead, grabbed by apt-get source' is name of the game, that's why debian patch managers exist. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
#include hallo.h * Matthew Palmer [Thu, Aug 03 2006, 08:03:21AM]: On Wed, Aug 02, 2006 at 08:36:18PM +0200, Eduard Bloch wrote: #include hallo.h * John Goerzen [Wed, Aug 02 2006, 01:01:51PM]: On Wed, Aug 02, 2006 at 08:47:01PM +0300, George Danchev wrote: to learn how we deal with this all. This is fine, but (again) you forget about your 'apt-get source' users, which NO. They need not care. They can just hack and send me diffs. My debian/changelog will already document what has been going on anyway. Heh. So they need two copies, one where they do modifications, then diff those and send you the diff. Or they need to change debian/changelog and learn to use interdiff. All that is more work that just callin dpatch_edit_patch foo. $ dpatch_edit_patch zsh: command not found: dpatch_edit_patch Nitpicking, you know what I mean. of packages that contain debian/patches/ were dpatch-edit-patch will get you nowhere. And when you do find a package where dpatch-edit-patch works, all it does, effectively, is make two copies, one where you do modifications, and then diff those and store the diff. Gee that sounds familiar. dpatch-edit-patch also suffers from the difficulty that you need to manually revert bits and pieces that you don't want in your final dpatch, like (for instance) updated changelog entries (which you made to make test builds to ensure that everything's working OK before going through the rigamarole of wrapping up the patch, and then reopening it again -- a full-tree diff, removal, and re-copying -- if you got it wrong. And you can do all that with dpatch-edit-dpatch and the regular Unix commands without learning another VCS and/or without needing access to it. Advantage? Yes. Why do dist.VCS fans always talk about patches like the would rain from the sky just so? Because we've moved on from being our own VCS (a la dpatch) and are now using an automated tool to track things *for* us, instead. So now working with patches is simple and straightforward. If you like the *WAY* it does this things, ok. I don't, I have described why and Frank did as well. are not supposed to be aware of your SCM, where your repo is, patches applied to the upstream source and why they have been applied. I.e. if you have patches, do them debian way (using a debian patch system) even using SCM to manage your whole packaging. Your orig.tar.gz must be really original tar.gz, and your diff.gz should hold whole debian-specific thing. I am quite well aware of that and it is trivial to do. And if the user has more than one patch which needs to be maintained separately, is it still is still trivial FOR HIM? (or her) HE (or she) can work out how to make things work FOR HIMSELF (or herself). Chances are, no matter which system you choose, someone out there isn't going to like it. So why hamstring yourself with a sub-standard system that you don't like working with, just to please some minority of users? Statements based on uncertain premisses are uncertain as well. And you got the answer already: there are lots of cases where the patch management is better made visible to others, as files rather trough some obscure meta layer (CMS) between the maintainer and users. Just get it as is, there is no question whether you like this fact or not. Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
#include hallo.h * John Goerzen [Wed, Aug 02 2006, 04:12:50PM]: Because everyone knows how to use cp and diff, and because I get diffs sent to the BTS all the time. It works. And it has nothing to do with VCS -- it's just Debian packages. Bingo. Therefore, your efforts to use the regular process as an argument supporting darcs' patch management are pointless. And if the user has more than one patch which needs to be maintained separately, is it still is still trivial FOR HIM? (or her) Who is the user? A system admin adding 3-5 extra patches to his local package installation? Eduard. -- weasel .oO( Graphischer installier fuer Debian: ein xterm und drinnen d-i ) Ganneff weasel: ATERM! weasel s/xterm/x-terminal-emulator/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wed, 2006-08-02 at 15:34 -0500, John Goerzen wrote: Ok, third time. Please do not do that: To: George Danchev [EMAIL PROTECTED] CC: debian-devel@lists.debian.org Then SET YOUR HEADERS to reflect that, like everyone else does. So you're shouting to people to use non-standard and not generally implemented headers to in order to have you comply with the mailinglist code of conduct? Please review: http://www.debian.org/MailingLists/#codeofconduct Thanks. Thijs signature.asc Description: This is a digitally signed message part
Re: Centralized darcs
Matthew Palmer [EMAIL PROTECTED] wrote: On Wed, Aug 02, 2006 at 06:31:18PM +0200, Frank Küster wrote: John Goerzen [EMAIL PROTECTED] wrote: I think people that are NMUing packages rarely care about this. When NMU'ing a package, I'd really appreciate to know which changes have which purpose and which specificity. In particular when trying to incorporate a fix provided by upstream - why the hell doesn't it apply cleanly? Did the Debian maintainer already try to address the problem differently, We have changelogs for that. If a maintainer doesn't fill out changelogs adequately, what are the chances that they're going to document their patches any better? The changelog will say something like patched component foo to no longer fail on bar, as well as patched component foo to support baz and patched component foo, I think the code might be insecure. You can't tell which changelog entry corresponds to which hunk in which file. With separated patches this is much easier, even if they are undocumented (except for the name). Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Centralized darcs
On Wed, Aug 02, 2006 at 03:34:34PM -0500, John Goerzen wrote: On Wed, Aug 02, 2006 at 09:09:12PM +0300, George Danchev wrote: Care to describe how without using your SCM but apt-get source instead ? apt-get source packagename Really, what is the problem here? With a system like dpatch when one downloads the source package it includes any modifications made to upstream as a series of logically separate patches, hopefully helping to document what the purpose of each individual modification is or at least providing information on which sets of changes go together. This information makes it much easier to understand what has been modified for the package and why. This is especially useful where you're trying to do something like figure out behaviour which diverges from upstream. Similar information should be provided by a revision control system but normally only with the repository. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
Thijs Kinkhorst [EMAIL PROTECTED] writes: So you're shouting to people to use non-standard and not generally implemented headers to in order to have you comply with the mailinglist code of conduct? Er, well the advantage of the headers is that in practice they pretty much work most of the time (despite being non-standard and not generally implemented they seem to work with the sort of MUA dds tend to use), unlike the c-o-c, which doesn't really. -Miles -- Everywhere is walking distance if you have the time. -- Steven Wright -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
to, 2006-08-03 kello 17:56 +0900, Miles Bader kirjoitti: Er, well the advantage of the headers is that in practice they pretty much work most of the time (despite being non-standard and not generally implemented they seem to work with the sort of MUA dds tend to use), unlike the c-o-c, which doesn't really. Debian's lists support List-ID, List-Post, and the other List- headers. If mutt's L command doesn't use that to figure out the list reply address, perhaps someone would be so kind as to write a suitable patch? (That's what evolution's control-L seems to cue in on, fwiw.) -- Rule #13 for successful communication: don't do Latin quotations -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
also sprach Lars Wirzenius [EMAIL PROTECTED] [2006.08.03.1116 +0100]: Debian's lists support List-ID, List-Post, and the other List- headers. If mutt's L command doesn't use that to figure out the list reply address, perhaps someone would be so kind as to write a suitable patch? (That's what evolution's control-L seems to cue in on, fwiw.) It sure works, but you have to let mutt know about it: subscribe debian-devel@lists.debian.org That's a *good* thing. Rule #13 for successful communication: don't do Latin quotations quidquid latine dictum sit, altum viditur. Never forget that! -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system women who want to be equal to men lack ambition. -- timothy leary signature.asc Description: Digital signature (GPG/PGP)
Re: Centralized darcs
to, 2006-08-03 kello 11:23 +0100, martin f krafft kirjoitti: also sprach Lars Wirzenius [EMAIL PROTECTED] [2006.08.03.1116 +0100]: Debian's lists support List-ID, List-Post, and the other List- headers. If mutt's L command doesn't use that to figure out the list reply address, perhaps someone would be so kind as to write a suitable patch? (That's what evolution's control-L seems to cue in on, fwiw.) It sure works, but you have to let mutt know about it: subscribe debian-devel@lists.debian.org That's a *good* thing. My point was that having to tell mutt manually about every mailing list is a pain, and people don't do it. The List- headers are sufficient, in my experience, to automate this. -- When in doubt, use brute force. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Thursday 03 August 2006 12:23, martin f krafft took the opportunity to say: also sprach Lars Wirzenius [EMAIL PROTECTED] [2006.08.03.1116 +0100]: Debian's lists support List-ID, List-Post, and the other List- headers. If mutt's L command doesn't use that to figure out the list reply address, perhaps someone would be so kind as to write a suitable patch? (That's what evolution's control-L seems to cue in on, fwiw.) It sure works, but you have to let mutt know about it: subscribe debian-devel@lists.debian.org When I tried it, version 1.5.9-2sarge2, L worked without having to let mutt know anything manually. It seems to use List-Post. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpxsFMYUD0Je.pgp Description: PGP signature
Re: Centralized darcs
Lars Wirzenius: to, 2006-08-03 kello 11:23 +0100, martin f krafft kirjoitti: It sure works, but you have to let mutt know about it: subscribe debian-devel@lists.debian.org That's a *good* thing. My point was that having to tell mutt manually about every mailing list is a pain, and people don't do it. The List- headers are sufficient, in my experience, to automate this. :0 * ^Delivered-To: mailing list \/[a-z0-9_+-]+ lists/$MATCH/ :0 * ^List-Id: .*\/[a-z0-9_+-]+ lists/$MATCH/ :0 * ^List-Id: \/[a-z0-9_+-]+ lists/$MATCH/ :0 * ^To: Multiple recipients of list \/[a-zA-Z0-9_+-]+ lists/$MATCH/ in my ~/.procmailrc coupled with folder-hook . lists `cd /home/shot/Mail/lists/; echo *` In my ~/.muttng/muttngrc seems to work very nice. -- Shot -- I have discovered a truly remarkable solution to Fermat's Last Theorem which this signature is too small to contain. pgpDuUVj8ZXrU.pgp Description: PGP signature
Re: Centralized darcs
On Thu, Aug 03, 2006 at 08:09:44AM +0200, Mike Hommey wrote: Nobody has to learn Darcs to hack on my packages. Well if someone has to work on a which of the applied patch broken the package is such a way kinda issue, he will have to, in order to have access to the patches. dpatch, quilt and others, in this case, make life easier (especially for security support). Ack but on the other hand if the repository is public *and* people do organize their checkins in a sorted manner, than using a SCM can be fine too. Anyway, as a side note on this thread: *darcs is just far t slow* for decent maintenance of large pieces of software. I tried once to create a mozilla repository, do some work with it and it was completely unusable. I am not talking about minutes, but almost hours to finish tasks that should take seconds. - Alexander -- GPG messages preferred.| .''`. ** Debian GNU/Linux ** Alexander Sack | : :' : The universal [EMAIL PROTECTED]| `. `' Operating System http://www.asoftsite.org/ | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
Alexander Sack [EMAIL PROTECTED] writes: Anyway, as a side note on this thread: *darcs is just far t slow* for decent maintenance of large pieces of software. I tried once to create a mozilla repository, do some work with it and it was completely unusable. I am not talking about minutes, but almost hours to finish tasks that should take seconds. It has improved a lot in last releases. You might redo your try. :-D -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
Otavio Salvador [EMAIL PROTECTED] wrote: Alexander Sack [EMAIL PROTECTED] writes: Anyway, as a side note on this thread: *darcs is just far t slow* for decent maintenance of large pieces of software. I tried once to create a mozilla repository, do some work with it and it was completely unusable. I am not talking about minutes, but almost hours to finish tasks that should take seconds. It has improved a lot in last releases. You might redo your try. Would it be usable for a source tree of a size where dpatch usage becomes a pain? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Centralized darcs
On Thu, Aug 03, 2006 at 08:37:10AM +0200, Eduard Bloch wrote: #include hallo.h * John Goerzen [Wed, Aug 02 2006, 04:12:50PM]: Because everyone knows how to use cp and diff, and because I get diffs sent to the BTS all the time. It works. And it has nothing to do with VCS -- it's just Debian packages. Bingo. Therefore, your efforts to use the regular process as an argument supporting darcs' patch management are pointless. What? Are you trying to just be a troll here? I am saying that: * For the MAINTAINER, a single diff.gz is often not the most convenient. * I believe that ANY VCS is a better solution to this than ANY custom patch solution. * No matter which VCS you use, third parties (NMUers, etc) don't have to learn it -- they can use standard Debian tools. * No matter which custom patching solution you use, third parties DO have to learn it before they can start hacking on your code. * Darcs has certain advantages over other VCS. If *I* use Darcs instead of a patching tool, then if Joe Random Hacker wants to NMU my package, *HE* doesn't have to learn a thing. Plus I get all the benefits of patch management and history with more features than any patching tool. If *I* use Darcs, then EVERYONE ELSE can use the regular process. If *I* use a patching tool, then EVERYONE ELSE IS FORCED TO ALSO. Clear now? And if the user has more than one patch which needs to be maintained separately, is it still is still trivial FOR HIM? (or her) Who is the user? A system admin adding 3-5 extra patches to his local package installation? How does this bolster your case? The local sysadmin has the potential to need to learn 3-5 patching tools in this case. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Thu, Aug 03, 2006 at 08:09:44AM +0200, Mike Hommey wrote: Well if someone has to work on a which of the applied patch broken the package is such a way kinda issue, he will have to, in order to have access to the patches. No, they are all in the diff.gz, and that's easy enough to find. dpatch, quilt and others, in this case, make life easier (especially for security support). As someone that has on occasion had the opportunity to NMU others' packages, I really disagree with that. Plus we've had someone in here from the QA team that agrees with my position on this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Thu, Aug 03, 2006 at 03:13:30PM +0200, Frank Küster wrote: Otavio Salvador [EMAIL PROTECTED] wrote: Alexander Sack [EMAIL PROTECTED] writes: Anyway, as a side note on this thread: *darcs is just far t slow* for decent maintenance of large pieces of software. I tried once to create a mozilla repository, do some work with it and it was completely unusable. I am not talking about minutes, but almost hours to finish tasks that should take seconds. It has improved a lot in last releases. You might redo your try. Would it be usable for a source tree of a size where dpatch usage becomes a pain? I've used it with both the Linux kernel tree and Asterisk with good results. -- John
Re: Centralized darcs
Alle Thursday 03 August 2006 13:42, Otavio Salvador ha scritto: Alexander Sack [EMAIL PROTECTED] writes: Anyway, as a side note on this thread: *darcs is just far t slow* for decent maintenance of large pieces of software. I tried once to create a mozilla repository, do some work with it and it was completely unusable. I am not talking about minutes, but almost hours to finish tasks that should take seconds. It has improved a lot in last releases. You might redo your try. As a recent post of mine to darcs-devel [1] shows it seems to be going well for a while and then after a few upstream releases it just breaks down. Hints for solving this mess would be appreciated, I'm investigating bzr at the moment, but tailor doesn't seem to like it all that much either seeing all the errors I get. Groetjes, Peter 1: http://article.gmane.org/gmane.comp.version-control.darcs.user/10145 never mind my idiotic duplicate. -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ God, root, what is difference? Pitr | God is more forgiving. Dave Aronson| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Thu, Aug 03, 2006 at 09:15:05AM +0300, George Danchev wrote: The very same debian patch manager clearly identifies patches you've produced against a certain upstream version and if I want to see the text of your diffs altering src/file.c|h|whatever, not just a mere changelog entry, I must track your SCM repo and its logs (learning a debian patch manager is No, you must just: zcat packagename-blah.diff.gz | less certainly easier as compared to any SCM and there are certainly more SCM out there than debian patch managers). Why do I need to track your changes to the upstream code ? Probably because I want to be sure that you haven't added any offending changes or any other defects to the upstream source code when upstream claims that their branch is working properly. Now you want to kill And the Debian diff will show you that. that important information from the debian source package itself and make like of people even harded to find out your SCM, learn to use it and track down the changes made to the upstream branch. I don't find that very impresive, and I think Security Team will not be impressed too. Why don't you stop speculating about what they think and just ask them for their opinion? Someone from the QA team already offered an opinion, and it wasn't yours. They don't have to know anything about the SCM to manipulate a monolithic diff.gz package. This is in contrast to a patch-managed package, where you *MUST* learn the patch management system to make a minimal, useful NMU patch. Seems like you don't consider clearly identified patches prepared against a given upstream version important, and (as you said in a previous message) a mere changelog entries should be enough for you. This is just a very interesting way of tracking changes ;-) No patch management system that I've seen tracks changes. It shows the current patches against upstream, not history for all time. This is a feature you get ONLY with a VCS, or manually by using shapshot.debian.net. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
Frank Küster [EMAIL PROTECTED] writes: Otavio Salvador [EMAIL PROTECTED] wrote: Alexander Sack [EMAIL PROTECTED] writes: Anyway, as a side note on this thread: *darcs is just far t slow* for decent maintenance of large pieces of software. I tried once to create a mozilla repository, do some work with it and it was completely unusable. I am not talking about minutes, but almost hours to finish tasks that should take seconds. It has improved a lot in last releases. You might redo your try. Would it be usable for a source tree of a size where dpatch usage becomes a pain? It depends of what means by usable and the size that you think it'll happen ;-) -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house.
Re: Centralized darcs
At 1154609291 past the epoch, Shot (Piotr Szotkowski) wrote: snip procmail solution I use something similar, but I generate procmailrc and muttrc snippets from a master file of mailing lists using m4 and some scripts. -- Jon Dowland http://alcopop.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Thu, Aug 03, 2006 at 08:32:28AM -0500, John Goerzen wrote: On Thu, Aug 03, 2006 at 08:09:44AM +0200, Mike Hommey wrote: Well if someone has to work on a which of the applied patch broken the package is such a way kinda issue, he will have to, in order to have access to the patches. No, they are all in the diff.gz, and that's easy enough to find. The total of changes is in the diff.gz, but obviously in a combined fashion. That is: if you have applied multiple patches for different issues on the same file, how will you extract a certain patch from that impossible. So, as a matter of fact, in diff.gz you loose information that you can keep in separately shipped patches. Just having the diff.gz can be a major PITA for security maintenance ... for instance, if you try to track down a regression that you know nothing about other than that it appeared somewhere between now and the beginning of life. - Alexander -- GPG messages preferred.| .''`. ** Debian GNU/Linux ** Alexander Sack | : :' : The universal [EMAIL PROTECTED]| `. `' Operating System http://www.asoftsite.org/ | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
At 1154593998 past the epoch, Eduard Bloch wrote: And you can do all that with dpatch-edit-dpatch and the regular Unix commands without learning another VCS and/or without needing access to it. Advantage? Yes. Someone is more likely to know a particular VCS than an in-house tool like dpatch, I reckon, and that skillset is going to be more useful and applicable in other contexts as well. -- Jon Dowland http://alcopop.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Thu, Aug 03, 2006 at 01:27:45PM +0300, Lars Wirzenius wrote: My point was that having to tell mutt manually about every mailing list is a pain, and people don't do it. I do. The List- headers are sufficient, in my experience, to automate this. They don't support following up to cross-posted messages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
#include hallo.h * John Goerzen [Thu, Aug 03 2006, 08:29:33AM]: On Thu, Aug 03, 2006 at 08:37:10AM +0200, Eduard Bloch wrote: #include hallo.h * John Goerzen [Wed, Aug 02 2006, 04:12:50PM]: Because everyone knows how to use cp and diff, and because I get diffs sent to the BTS all the time. It works. And it has nothing to do with VCS -- it's just Debian packages. Bingo. Therefore, your efforts to use the regular process as an argument supporting darcs' patch management are pointless. What? Are you trying to just be a troll here? I am saying that: * For the MAINTAINER, a single diff.gz is often not the most convenient. Really? For me, it sounded like having a single diff.gz is ok for everyone and patch management should be done in the VCS. * I believe that ANY VCS is a better solution to this than ANY custom patch solution. Believes are not proofs, sorry. They are hypotheses based on subjective ground. If *I* use Darcs instead of a patching tool, then if Joe Random Hacker wants to NMU my package, *HE* doesn't have to learn a thing. Plus I get all the benefits of patch management and history with more features than any patching tool. If *I* use Darcs, then EVERYONE ELSE can use the regular process. If *I* use a patching tool, then EVERYONE ELSE IS FORCED TO ALSO. Clear now? ?? It has been clear before. There are just too many null-arguments blowing up this discussion. And if the user has more than one patch which needs to be maintained separately, is it still is still trivial FOR HIM? (or her) Who is the user? A system admin adding 3-5 extra patches to his local package installation? How does this bolster your case? The local sysadmin has the potential to need to learn 3-5 patching tools in this case. One can easily add those modifications. In different atoms (patches). One can update those atoms with newer versions from 3rd party sources. Without having to deal with maintainer's VCS or setup a custom one. Eduard. -- Der Haß ist ein aktives Mißvergnügen, der Neid ein passives, deshalb darf man sich nicht wundern, wenn der Neid so schnell in Haß übergeht. -- Johann Wolfgang von Goethe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
#include hallo.h * John Goerzen [Tue, Aug 01 2006, 04:47:13PM]: I do use darcs to track patches against upstream. I really don't understand the whole cdbs/dpatch/whatever thing -- why use a hack to manage your patches when you could use a real VC tool that does it better? Because you can make your work persistent in atoms without having a complicated meta layer inbetween. Patching with VC works well (even with Subversion) if you have just few lines to change (basic use case while developing svn-buildpackage) but the fun disappears when you have a dozen of patches from different sources. I get scared sometimes when I hear people talking proudly about managing their project using a distributed VCS as framework to link dozens of patch layers together though I admittedly never tried to recreate a such scenario. It sounds like a lot of overhead and big waste of time from the beginning, sorry. Eduard. -- LGS Halloechen, ihr Spinner, so frueh auf? nusse nein, wir schlafen alle im kollektiv knorke mein alkoven ist kaputt teq alkohol kaputt? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Tuesday 01 August 2006 23:47, John Goerzen wrote: I do use darcs to track patches against upstream. I really don't understand the whole cdbs/dpatch/whatever thing -- why use a hack to manage your patches when you could use a real VC tool that does it better? Is there a common best practice procedure on how to deal with new upstream releases then? I imagine that I unpack an upstream tarball, put it under (D)RCS control and work on the debian/ directory. Then a new upstream tarball is released. Do I just unpack it and do a merge? How do tell my own patches (that I usually do in dpatch) from the upstream changes? Cheers Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
Le mardi 01 août 2006 à 23:39 +0100, martin f krafft a écrit : also sprach John Goerzen [EMAIL PROTECTED] [2006.08.01.2247 +0100]: I do use darcs to track patches against upstream. I really don't understand the whole cdbs/dpatch/whatever thing -- why use a hack to manage your patches when you could use a real VC tool that does it better? I agree, dpatch co seem to be more accessible: they are files you can touch; they're not an abstract concept (branch) which you can work with, but which is not tangible. This is another possible reason for SVN's success: branches are directories, which are a reasonably widespread concept among Unix developers. In fact, SVN is what looks the most closely to a distributed and versioned filesystem, which is how most packaging teams use it. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Centralized darcs
Hello! On Tue, 01 Aug 2006 22:34:41 +0200, John Goerzen wrote: On Tue, Aug 01, 2006 at 09:06:19PM +0100, martin f krafft wrote: John, are you actually using the workflow you describe for maintenance of Debian packages? Single or team maintenance? Could you elaborate a bit? I do use darcs for almost all of my Debian packages. You can find my darcs repositories at http://darcs.complete.org/debian/ In darcs, every working copy is a repository, and a branch is just a get, and a commit to the canonical location is just a merge (darcs push). FWIW, the Common Lisp in Debian group [1] (Peter Van Eynde, René Van Bevern and me) uses Darcs to manage its packages [2]. From the private presentation Peter sent me a long time ago... The tree is upstream - package-upstream | branch + debian patches - package You update package-upstream, then pull the changes into package. The debian parts are only in package. darcs-build.sh [3] or darcs-buildpackage will automaticly create the upstream .orig.tar.gz file from the package-upstream repository. I've been using darcs push, which sends the patch over ssh, instead of the e-mail thing since I am the only committer to my repos. But sending a GPG-signed patch bundle can be as easy as darcs send and David Roundy has posted recipes for processing those on the server. I don't know how Peter and René work, but in my case as I'm the only one working on my packages I just rsync to Alioth my local repositories. In case I've patches for other (i.e. not mine) repositories, I send them to the corresponding bug [4] or the CL-Debian mailing list. Just my 0.02€... Thx, bye, Gismo / Luca [1] http://cl-debian.alioth.debian.org/ [2] http://cl-debian.alioth.debian.org/repository [3] http://cl-debian.alioth.debian.org/repository/pvaneynd/darcs-build.sh [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335489 pgprsjWBVF1SU.pgp Description: PGP signature
Re: Centralized darcs
Hello! On Wed, 02 Aug 2006 10:17:57 +0200, Christoph Haas wrote: On Tuesday 01 August 2006 23:47, John Goerzen wrote: I do use darcs to track patches against upstream. I really don't understand the whole cdbs/dpatch/whatever thing -- why use a hack to manage your patches when you could use a real VC tool that does it better? Is there a common best practice procedure on how to deal with new upstream releases then? You may check the darcs-buildpackage manual, if you've darcs-buildpackage installed is at [1]. BTW, John's announcement is at [2]. HTH! Thx, bye, Gismo / Luca [1] http://localhost/doc/darcs-buildpackage/html/ [2] http://www.abridgegame.org/pipermail/darcs-users/2005-April/007072.html pgp9U74BPA27R.pgp Description: PGP signature
Re: Centralized darcs
also sprach Josselin Mouette [EMAIL PROTECTED] [2006.08.02.1004 +0100]: I agree, dpatch co seem to be more accessible: they are files you can touch; they're not an abstract concept (branch) which you can work with, but which is not tangible. This is another possible reason for SVN's success: branches are directories, which are a reasonably widespread concept among Unix developers. In fact, SVN is what looks the most closely to a distributed and versioned filesystem, which is how most packaging teams use it. Excellent argument! I completely agree. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system aus der kriegsschule des lebens - was mich nicht umbringt, macht mich härter. - friedrich nietzsche signature.asc Description: Digital signature (GPG/PGP)
Re: Centralized darcs
On Tue, 2006-08-01 at 16:47 -0500, John Goerzen wrote: I do use darcs to track patches against upstream. I really don't understand the whole cdbs/dpatch/whatever thing -- why use a hack to manage your patches when you could use a real VC tool that does it better? A patch system can be very convenient for the people who are not the maintainer of the package - if you fetch the source package from the archive you get all packages neatly separated and mostly with a description. It's then easy to extract a patch, disable a patch or add a new one, for example when NMU'ing. If I'm correct the source package won't display the changesets from your VC. Thijs signature.asc Description: This is a digitally signed message part
Re: Centralized darcs
On Wednesday 02 August 2006 12:23, Thijs Kinkhorst wrote: On Tue, 2006-08-01 at 16:47 -0500, John Goerzen wrote: I do use darcs to track patches against upstream. I really don't understand the whole cdbs/dpatch/whatever thing -- why use a hack to manage your patches when you could use a real VC tool that does it better? A patch system can be very convenient for the people who are not the maintainer of the package - if you fetch the source package from the archive you get all packages neatly separated and mostly with a description. It's then easy to extract a patch, disable a patch or add a new one, for example when NMU'ing. True. The patch system extends distributed development even further ... beyond the VCS (be any kind of). You can always have input from random people which worths to be reviewed. These people need easy access to the debian source package and what parts it has been assembled of. If I'm correct the source package won't display the changesets from your VC. Unless someone steps forward and hack VCS2changelog.Debian utility(ies) which automagically adds VCS log events on the top of debian/changelog already being under VCS control in the first place ;-) -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wed, Aug 02, 2006 at 09:41:02AM +0200, Eduard Bloch wrote: #include hallo.h * John Goerzen [Tue, Aug 01 2006, 04:47:13PM]: I do use darcs to track patches against upstream. I really don't understand the whole cdbs/dpatch/whatever thing -- why use a hack to manage your patches when you could use a real VC tool that does it better? Because you can make your work persistent in atoms without having a complicated meta layer inbetween. Patching with VC works well (even with Subversion) if you have just few lines to change (basic use case while developing svn-buildpackage) but the fun disappears when you have a dozen of patches from different sources. Actually, I think this is where darcs really shines. Keep in mind that, to darcs, a repository is a collection of patches. Darcs also has a notion of patch dependencies. So you can actually do things like revert a given patch and all later patches that depend upon it. This dependency support is pretty much automatic. So not only do you get to manage your project's current patches, but you get history and merging tools for free. Note that darcs is, at its heart, a patch management system rather than a history system. Each patch does have a timestamp, but darcs repositories are, fundamentally, just collections of patches. The patches don't necessarily have to be applied in the same order (for instance, it doesn't matter if you apply the patch that creates file A or file B first), though its dependencies ensure that they are applied in the correct order when necessary. Really, I think that getting patches in darcs from people that are using darcs send is not only easier for me as a maintainer, but also easier for them as contributors. Plus it is really easy for people that don't grok darcs to just use normal tools to edit Debian source packages, create diffs, NMU packages, or whatever -- and for me to integrate their changes later. This is not the case for the other special-purpose patch tools. I get scared sometimes when I hear people talking proudly about managing their project using a distributed VCS as framework to link dozens of patch layers together though I admittedly never tried to recreate a such I don't know what you mean by a patch layer. scenario. It sounds like a lot of overhead and big waste of time from the beginning, sorry. I don't know where you get that idea. As I make changes, I darcs record them. I use dbp-importorig to import new upstream sources -- this is just a script that untars them and uses darcs_load_dirs to import them as a changeset to the upstream branch. I use darcs pull (the darcs merge command) to pull it into my Debian tree, and that's that. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wed, Aug 02, 2006 at 10:17:57AM +0200, Christoph Haas wrote: On Tuesday 01 August 2006 23:47, John Goerzen wrote: I do use darcs to track patches against upstream. I really don't understand the whole cdbs/dpatch/whatever thing -- why use a hack to manage your patches when you could use a real VC tool that does it better? Is there a common best practice procedure on how to deal with new upstream releases then? I imagine that I unpack an upstream tarball, put it under (D)RCS control and work on the debian/ directory. Then a new upstream tarball is released. Do I just unpack it and do a merge? How do tell my own patches (that I usually do in dpatch) from the upstream changes? I generally keep an upstream branch and a Debian branch. I wrote a few simple tools in the darcs-buildpackage package to help with this. dbp-importorig takes a tarball/directory name, a version number, and a path to an upstream branch. It commits the upstream changes vs. the latest version in the upstream repo and tags it. If upstream uses darcs or git, you could use their repo directly. If they use CVS or SVN, you could use tailor to track it. If they use Arch, you can use arch2darcs to track it. Then all you do is go to your Debian branch and do a merge from the upstream branch (darcs pull). Most things will be merged automatically. Conflicts will be warned as appropriate. You do all your work in the Debian branch, committing changes as you go. dbp-importorig always generates predictable commit messages. Darcs has support for regexps at a fundamental level in almost all commands, so you can easily select (or not) the upstream patches. What's more, the Debian branch is always a superset of the upstream branch. You can extract the pure upstream sources at will from the Debian branch by simply selecting the latest upstream tag from it. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wed, Aug 02, 2006 at 11:23:31AM +0200, Thijs Kinkhorst wrote: On Tue, 2006-08-01 at 16:47 -0500, John Goerzen wrote: I do use darcs to track patches against upstream. I really don't understand the whole cdbs/dpatch/whatever thing -- why use a hack to manage your patches when you could use a real VC tool that does it better? A patch system can be very convenient for the people who are not the maintainer of the package - if you fetch the source package from the archive you get all packages neatly separated and mostly with a description. It's then easy to extract a patch, disable a patch or add a new one, for example when NMU'ing. Actually, I disagree with that. I always hate having to work with a package that uses a patch management system, because then I have to learn the system before I can do any work on the package. And there are several systems. Plus it's not always quick easy to generate a diff for an NMU out of that. And the resulting diff isn't necessarily easy to read (being a diff of a diff). If I'm correct the source package won't display the changesets from your VC. That is correct, per Debian policy. However, if you're just NMUing, presumably you wouldn't care about that -- you'd send me a diff, which would then become a changeset in my VC tool. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wednesday 02 August 2006 16:34, John Goerzen wrote: On Wed, Aug 02, 2006 at 11:23:31AM +0200, Thijs Kinkhorst wrote: On Tue, 2006-08-01 at 16:47 -0500, John Goerzen wrote: I do use darcs to track patches against upstream. I really don't understand the whole cdbs/dpatch/whatever thing -- why use a hack to manage your patches when you could use a real VC tool that does it better? A patch system can be very convenient for the people who are not the maintainer of the package - if you fetch the source package from the archive you get all packages neatly separated and mostly with a description. It's then easy to extract a patch, disable a patch or add a new one, for example when NMU'ing. Actually, I disagree with that. I always hate having to work with a package that uses a patch management system, because then I have to learn the system before I can do any work on the package. And there are several systems. Plus it's not always quick easy to generate a diff for an NMU out of that. And the resulting diff isn't necessarily easy to read (being a diff of a diff). How is that not true if one knows a given patch system and does know about your VCS and needs to work on one of your packages. Do they have debian/patches/ as separate file, how do I know how to update/remove/etc them ? How is that different from learning darcs patch system which might happend to be new for me. There is also git arch which also pretend to be a patch system at heart. Thus the diversity is the same as in different patch system / not necessary a bat thing though /. If I'm correct the source package won't display the changesets from your VC. That is correct, per Debian policy. However, if you're just NMUing, presumably you wouldn't care about that -- you'd send me a diff, which would then become a changeset in my VC tool. -- John -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wed, Aug 02, 2006 at 05:20:26PM +0300, George Danchev wrote: Actually, I disagree with that. I always hate having to work with a package that uses a patch management system, because then I have to learn the system before I can do any work on the package. And there are several systems. Plus it's not always quick easy to generate a diff for an NMU out of that. And the resulting diff isn't necessarily easy to read (being a diff of a diff). How is that not true if one knows a given patch system and does know about your VCS and needs to work on one of your packages. Do they have They just apt-get source, hack away, and send me a diff. debian/patches/ as separate file, how do I know how to update/remove/etc There would be no debian/patches. They shouldn't be converting the package to use a patch system. them ? How is that different from learning darcs patch system which might happend to be new for me. There is also git arch which also pretend to be a patch system at heart. Thus the diversity is the same as in different patch system / not necessary a bat thing though /. They can build and use the package just like normal. Somebody doesn't have to know how to use my VC in order to work on my package, which is different from the situation with the patch systems. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
Hello! On Wed, 02 Aug 2006 15:32:13 +0200, John Goerzen wrote: If upstream uses darcs or git, you could use their repo directly. If they use CVS or SVN, you could use tailor to track it. If they use Arch, you can use arch2darcs to track it. For a tailor mini-HowTo, please give a look at [1]. Actually, I use a different approach for the three upstream that uses CVS. The first time I generated the darcs -upstream repository, I didn't include the CVS folders (because anyway it's a lintian error if they're present in the .orig.tar.gz). Thus, every time I want to import a CVS version into the darcs -upstream, I do: $ cd /path/to/package-upstream $ cvs update -d $ darcs add [any new files] $ darcs record -m Import upstream $PACKAGE version $DATE $ darcs tag -m UPSTREAM_$PACKAGE_$DATE Until now it worked without any problem. Thx, bye, Gismo / Luca [1] http://wiki.debian.org/PackagingWithDarcsAndTailor pgpKWxkvHaODb.pgp Description: PGP signature
Re: Centralized darcs
Hello! On Wed, 02 Aug 2006 16:49:06 +0200, Luca Capello wrote: The first time I generated the darcs -upstream repository, I didn't include the CVS folders (because anyway it's a lintian error if ^^^ they're present in the .orig.tar.gz). The underlined above should be read as I didn't `darcs add` the CVS folder, obviously the CVS folder is present into the $PACKAGE-upstream folder (otherwise `cvs update -d` couldn't work). Thx, bye, Gismo / Luca pgpoDLDCViCDu.pgp Description: PGP signature
Re: Centralized darcs
On Wednesday 02 August 2006 17:31, John Goerzen wrote: On Wed, Aug 02, 2006 at 05:20:26PM +0300, George Danchev wrote: Actually, I disagree with that. I always hate having to work with a package that uses a patch management system, because then I have to learn the system before I can do any work on the package. And there are several systems. Plus it's not always quick easy to generate a diff for an NMU out of that. And the resulting diff isn't necessarily easy to read (being a diff of a diff). How is that not true if one knows a given patch system and does know about your VCS and needs to work on one of your packages. Do they have They just apt-get source, hack away, and send me a diff. Also true for any debian patch system, but with the gain the debian specific patches are clearly separated and documented as well. Existing patches could be updated, which could be a good thing when adding a new patch to patch already patched by other patches stuff is insane. debian/patches/ as separate file, how do I know how to update/remove/etc There would be no debian/patches. That could be bad sometimes, or most of the time. Some people prefer to have debian-specific patches (applied to the upstream source) separated and with comments appended, which leads to more fine-grained control. They shouldn't be converting the package to use a patch system. They can send new patch to be included in debian/patches/, remove one, or update it as well. They can send a patch against the toplevel soruce package directory. them ? How is that different from learning darcs patch system which might happend to be new for me. There is also git arch which also pretend to be a patch system at heart. Thus the diversity is the same as in different patch system / not necessary a bat thing though /. They can build and use the package just like normal. Somebody doesn't have to know how to use my VC in order to work on my package, which is different from the situation with the patch systems. But you lose debian specific patches to be clearly separated from the upstrem source (digging diff.gz for that is not fun), unless one knows where to find your VCS repository, learn that VCS and work from there, which is not always documented in the source package's themselves. It all boils down to how you look at it - some prefer separation, other megring everything at once. Seems like we are not taking about different VCS, but how the debian specific patches against the upstream source might be applied. P.S. please do not CC: if not explicitely requested, I'm subscribed. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wed, Aug 02, 2006 at 06:01:27PM +0300, George Danchev wrote: How is that not true if one knows a given patch system and does know about your VCS and needs to work on one of your packages. Do they have They just apt-get source, hack away, and send me a diff. Also true for any debian patch system, but with the gain the debian specific No, it's not, because for most of them, the source that you get with apt-get source is a tar.gz file and a debian/ directory. You can NOT just hack away on that like you would any package. You MUST learn the specific tool to do ANYTHING. They shouldn't be converting the package to use a patch system. They can send new patch to be included in debian/patches/, remove one, or If I am using darcs, or svn, or whatever, there is no debian/patches at all. I don't understand what you are saying here. But you lose debian specific patches to be clearly separated from the upstrem source (digging diff.gz for that is not fun), unless one knows where to find First, what is a Debian-specific patch? Isn't everything in diff.gz that? Maybe you mean just stuff in debian/. Well it's easy enough to filter that out. I think people that are NMUing packages rarely care about this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wednesday 02 August 2006 18:35, John Goerzen wrote: On Wed, Aug 02, 2006 at 06:01:27PM +0300, George Danchev wrote: How is that not true if one knows a given patch system and does know about your VCS and needs to work on one of your packages. Do they have They just apt-get source, hack away, and send me a diff. Also true for any debian patch system, but with the gain the debian specific No, it's not, because for most of them, the source that you get with apt-get source is a tar.gz file and a debian/ directory. You can NOT just hack away on that like you would any package. You MUST learn the specific tool to do ANYTHING. After apt-get source you get debian source package directory with debian/patches/ inside. Learing to add/remove/update patches is easy and if one is not able to learn that, better not to send any diff, waste of time. They shouldn't be converting the package to use a patch system. They can send new patch to be included in debian/patches/, remove one, or If I am using darcs, or svn, or whatever, there is no debian/patches at all. I don't understand what you are saying here. Where are you debian specific patches you apply to the upstream source tree as patches in debian/patches/ do. Or your have orig.tar.gz already patched with these and which is no more original tar.gz, and diff.gz not containing these. This is forbidden by the policy as we know. And this adds confusion. But you lose debian specific patches to be clearly separated from the upstrem source (digging diff.gz for that is not fun), unless one knows where to find First, what is a Debian-specific patch? Isn't everything in diff.gz that? Right, but you have parts which touch upstream files (debian/patches/*), and parts which does not (debian/!patches). I prefer them to be clearly separated when the whole debian source package is unpacked. Maybe you mean just stuff in debian/. Well it's easy enough to filter that out. I think people that are NMUing packages rarely care about this. see above. Note that I'm not against distibuted VCS (obviously), I argue that no matter which VCS is used, IMO debian specific patches which alter upstream source should be clearly separated (these are debian/patches/* in the world of debian patch systems). second try/Please, do not CC: to me. I didn't explicitely requested that, it is obvious that I'm subscribed to this list. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
John Goerzen [EMAIL PROTECTED] wrote: On Wed, Aug 02, 2006 at 06:01:27PM +0300, George Danchev wrote: How is that not true if one knows a given patch system and does know about your VCS and needs to work on one of your packages. Do they have They just apt-get source, hack away, and send me a diff. Also true for any debian patch system, but with the gain the debian specific No, it's not, because for most of them, the source that you get with apt-get source is a tar.gz file and a debian/ directory. You can NOT just hack away on that like you would any package. You MUST learn the specific tool to do ANYTHING. As far as I know, this is only true for one specific patch system which I distaste so much that I always forget its name. dpatch and quilt, which are often used and recommended, use a standard unpacked source tree with a debian directory in it. But you lose debian specific patches to be clearly separated from the upstrem source (digging diff.gz for that is not fun), unless one knows where to find First, what is a Debian-specific patch? Isn't everything in diff.gz that? No, of course not. In many cases there are upstream patches, which could mean: - patches taken from an unreleased upstream version - patches developed by the DD and submitted to upstream, inclusion might be promised or only hoped for - security patches for external code that is included in the tarball and used, but not maintained by upstream (no guarantee that their next point release will actually contain the security fix...) Among the really Debian-specific patches, there might also be some that will probably always be needed, even in major new upstream versions, and others that are Debian-specific workarounds for a problem that is likely to be solved differently by upstream at some point in the future. For example, tetex-base has three debian-specific patches (one of the second type), and seven that address upstream issues. Many of the changelogs of other packages also indicate a similiar organization (dropped patch-foo which is included upstream, dropped patch-bar, no need to change BAR_PATH any more. Add a pointer in README.Debian to the docs for the bar option, updated patch-baz from upstream CVS). I think people that are NMUing packages rarely care about this. When NMU'ing a package, I'd really appreciate to know which changes have which purpose and which specificity. In particular when trying to incorporate a fix provided by upstream - why the hell doesn't it apply cleanly? Did the Debian maintainer already try to address the problem differently, or is it an orthogonal change for an unrelated problem? In the worst case, in the setup you suggest, I would have to understand the complete diff.gz to be sure, or at least major parts of the changes to actual source code. If there are separate, commented patches somewhere, it's easy to tell. And even if it's not commented, one usually can trust that changes addressing the same problem aren't dispersed over multiple patches. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Centralized darcs
George Danchev [EMAIL PROTECTED] wrote: But you lose debian specific patches to be clearly separated from the upstrem source (digging diff.gz for that is not fun), unless one knows where to find First, what is a Debian-specific patch? Isn't everything in diff.gz that? Right, but you have parts which touch upstream files (debian/patches/*), and parts which does not (debian/!patches). I prefer them to be clearly separated when the whole debian source package is unpacked. Not only that. Many packages make changes to upstream files that are Debian-specific (e.g. for using infrastructure or libraries that don't exist outside), but also changes to upstream files that will/should be temporary because upstream will apply the same patch, has been asked to, or the patch has been taken from their development version. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Centralized darcs
Frank Küster [EMAIL PROTECTED] writes: George Danchev [EMAIL PROTECTED] wrote: But you lose debian specific patches to be clearly separated from the upstrem source (digging diff.gz for that is not fun), unless one knows where to find First, what is a Debian-specific patch? Isn't everything in diff.gz that? Right, but you have parts which touch upstream files (debian/patches/*), and parts which does not (debian/!patches). I prefer them to be clearly separated when the whole debian source package is unpacked. Not only that. Many packages make changes to upstream files that are Debian-specific (e.g. for using infrastructure or libraries that don't exist outside), but also changes to upstream files that will/should be temporary because upstream will apply the same patch, has been asked to, or the patch has been taken from their development version. Iff we use a branch to each change we can have same behaviour using a SCM but anyone that would want to change or contrib changes will need to learn how we deal with this all. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house.
Re: Centralized darcs
On Wednesday 02 August 2006 20:11, Otavio Salvador wrote: Frank Küster [EMAIL PROTECTED] writes: George Danchev [EMAIL PROTECTED] wrote: But you lose debian specific patches to be clearly separated from the upstrem source (digging diff.gz for that is not fun), unless one knows where to find First, what is a Debian-specific patch? Isn't everything in diff.gz that? Right, but you have parts which touch upstream files (debian/patches/*), and parts which does not (debian/!patches). I prefer them to be clearly separated when the whole debian source package is unpacked. Not only that. Many packages make changes to upstream files that are Debian-specific (e.g. for using infrastructure or libraries that don't exist outside), but also changes to upstream files that will/should be temporary because upstream will apply the same patch, has been asked to, or the patch has been taken from their development version. Iff we use a branch to each change we can have same behaviour using a SCM but anyone that would want to change or contrib changes will need to learn how we deal with this all. This is fine, but (again) you forget about your 'apt-get source' users, which are not supposed to be aware of your SCM, where your repo is, patches applied to the upstream source and why they have been applied. I.e. if you have patches, do them debian way (using a debian patch system) even using SCM to manage your whole packaging. Your orig.tar.gz must be really original tar.gz, and your diff.gz should hold whole debian-specific thing. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
Otavio Salvador [EMAIL PROTECTED] wrote: Frank Küster [EMAIL PROTECTED] writes: George Danchev [EMAIL PROTECTED] wrote: But you lose debian specific patches to be clearly separated from the upstrem source (digging diff.gz for that is not fun), unless one knows where to find First, what is a Debian-specific patch? Isn't everything in diff.gz that? Right, but you have parts which touch upstream files (debian/patches/*), and parts which does not (debian/!patches). I prefer them to be clearly separated when the whole debian source package is unpacked. Not only that. Many packages make changes to upstream files that are Debian-specific (e.g. for using infrastructure or libraries that don't exist outside), but also changes to upstream files that will/should be temporary because upstream will apply the same patch, has been asked to, or the patch has been taken from their development version. Iff we use a branch to each change we can have same behaviour using a SCM but anyone that would want to change or contrib changes will need to learn how we deal with this all. Yes, and you don't see it in the source package, do you? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Centralized darcs
On Wed, Aug 02, 2006 at 08:47:01PM +0300, George Danchev wrote: to learn how we deal with this all. This is fine, but (again) you forget about your 'apt-get source' users, which NO. They need not care. They can just hack and send me diffs. My debian/changelog will already document what has been going on anyway. are not supposed to be aware of your SCM, where your repo is, patches applied to the upstream source and why they have been applied. I.e. if you have patches, do them debian way (using a debian patch system) even using SCM to manage your whole packaging. Your orig.tar.gz must be really original tar.gz, and your diff.gz should hold whole debian-specific thing. I am quite well aware of that and it is trivial to do. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wednesday 02 August 2006 21:01, John Goerzen wrote: On Wed, Aug 02, 2006 at 08:47:01PM +0300, George Danchev wrote: to learn how we deal with this all. Ok, third time. Please do not do that: To: George Danchev [EMAIL PROTECTED] CC: debian-devel@lists.debian.org Sending to debian-devel@lists.debian.org is enough, I'm subscribed. Thanks. This is fine, but (again) you forget about your 'apt-get source' users, which NO. They need not care. They can just hack and send me diffs. My debian/changelog will already document what has been going on anyway. What if I want to be able to revert your patches easily and apply only these which I want to... Then I can start hack on the top of that. are not supposed to be aware of your SCM, where your repo is, patches applied to the upstream source and why they have been applied. I.e. if you have patches, do them debian way (using a debian patch system) even using SCM to manage your whole packaging. Your orig.tar.gz must be really original tar.gz, and your diff.gz should hold whole debian-specific thing. I am quite well aware of that and it is trivial to do. Care to describe how without using your SCM but apt-get source instead ? -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
#include hallo.h * John Goerzen [Wed, Aug 02 2006, 08:27:32AM]: On Wed, Aug 02, 2006 at 09:41:02AM +0200, Eduard Bloch wrote: #include hallo.h * John Goerzen [Tue, Aug 01 2006, 04:47:13PM]: I do use darcs to track patches against upstream. I really don't understand the whole cdbs/dpatch/whatever thing -- why use a hack to manage your patches when you could use a real VC tool that does it better? Because you can make your work persistent in atoms without having a complicated meta layer inbetween. Patching with VC works well (even with Subversion) if you have just few lines to change (basic use case while developing svn-buildpackage) but the fun disappears when you have a dozen of patches from different sources. Actually, I think this is where darcs really shines. Keep in mind that, to darcs, a repository is a collection of patches. Darcs also has a notion of patch dependencies. So you can actually do things like revert a given patch and all later patches that depend upon it. This dependency support is pretty much automatic. First, I do not believe that this support is perfect. Second, in real life removing all subsequent patches to revert one does hardly make sense. And even then: if you need manual work to merge different patch chains of such kind then you will need to do the same (or more) manual work to cleanup the mess after a such chain has been reverted. And in the easy cases... where do you need a such shiny support? svn can gives you a diff between two old revisioins which you can apply with patch -R. Note that darcs is, at its heart, a patch management system rather than a history system. Each patch does have a timestamp, but darcs repositories are, fundamentally, just collections of patches. The patches don't necessarily have to be applied in the same order (for instance, it doesn't matter if you apply the patch that creates file A or file B first), though its dependencies ensure that they are applied in the correct order when necessary. Really, I think that getting patches in darcs from people that are using darcs send is not only easier for me as a maintainer, but also easier Much easier as storing the mail attachment under debian/patches? I doubt. for them as contributors. Plus it is really easy for people that don't grok darcs to just use normal tools to edit Debian source packages, create diffs, NMU packages, or whatever -- and for me to integrate their changes later. This is not the case for the other special-purpose patch tools. This does not really differ from the scenarios with patch management system. I get scared sometimes when I hear people talking proudly about managing their project using a distributed VCS as framework to link dozens of patch layers together though I admittedly never tried to recreate a such I don't know what you mean by a patch layer. Modification layers. Similar to how darcs works (if I understood you correctly). I remember reading that some maintainers link their Debian directory together from different sources with generic parts. Sometimes that does make sense, sometimes it does not. scenario. It sounds like a lot of overhead and big waste of time from the beginning, sorry. I don't know where you get that idea. As I make changes, I darcs record them. I use dbp-importorig to import new upstream sources -- this is just a script that untars them and uses darcs_load_dirs to import them as a changeset to the upstream branch. I use darcs pull (the darcs merge command) to pull it into my Debian tree, and that's that. Yes... and where is the big difference to other VCs except that you do not commit to a central repository immediately? (but you need to do it in an extra step in order to share the work). Eduard. -- ij Madkiss: Niemand kann so die Nachrichten mehr aufbereiten, dass Otto-Normal-Bürger die versteht, da dieser viel zu dämlich dafür ist. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
#include hallo.h * John Goerzen [Wed, Aug 02 2006, 01:01:51PM]: On Wed, Aug 02, 2006 at 08:47:01PM +0300, George Danchev wrote: to learn how we deal with this all. This is fine, but (again) you forget about your 'apt-get source' users, which NO. They need not care. They can just hack and send me diffs. My debian/changelog will already document what has been going on anyway. Heh. So they need two copies, one where they do modifications, then diff those and send you the diff. Or they need to change debian/changelog and learn to use interdiff. All that is more work that just callin dpatch_edit_patch foo. Why do dist.VCS fans always talk about patches like the would rain from the sky just so? are not supposed to be aware of your SCM, where your repo is, patches applied to the upstream source and why they have been applied. I.e. if you have patches, do them debian way (using a debian patch system) even using SCM to manage your whole packaging. Your orig.tar.gz must be really original tar.gz, and your diff.gz should hold whole debian-specific thing. I am quite well aware of that and it is trivial to do. And if the user has more than one patch which needs to be maintained separately, is it still is still trivial FOR HIM? (or her) Eduard. -- Naja, Garbage Collector eben. Holt den Müll sogar vom Himmel. (Heise Trollforum über Java in der Flugzeugsteuerung) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wed, Aug 02, 2006 at 09:09:12PM +0300, George Danchev wrote: On Wednesday 02 August 2006 21:01, John Goerzen wrote: On Wed, Aug 02, 2006 at 08:47:01PM +0300, George Danchev wrote: to learn how we deal with this all. Ok, third time. Please do not do that: To: George Danchev [EMAIL PROTECTED] CC: debian-devel@lists.debian.org Then SET YOUR HEADERS to reflect that, like everyone else does. NO. They need not care. They can just hack and send me diffs. My debian/changelog will already document what has been going on anyway. What if I want to be able to revert your patches easily and apply only these which I want to... Then I can start hack on the top of that. Then feel free to review them. That's no problem. If you use darcs, you can do selective commits easily. using SCM to manage your whole packaging. Your orig.tar.gz must be really original tar.gz, and your diff.gz should hold whole debian-specific thing. I am quite well aware of that and it is trivial to do. Care to describe how without using your SCM but apt-get source instead ? apt-get source packagename Really, what is the problem here? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wed, Aug 02, 2006 at 08:36:18PM +0200, Eduard Bloch wrote: NO. They need not care. They can just hack and send me diffs. My debian/changelog will already document what has been going on anyway. Heh. So they need two copies, one where they do modifications, then diff those and send you the diff. Or they need to change debian/changelog and This is not a fault of darcs; this is how Debian packages work. What's the problem? apt-get source and cp -r and that's it. learn to use interdiff. All that is more work that just callin dpatch_edit_patch foo. One extra command, and it's less work than learning how to use N different patch systems. Why do dist.VCS fans always talk about patches like the would rain from the sky just so? Because everyone knows how to use cp and diff, and because I get diffs sent to the BTS all the time. It works. And it has nothing to do with VCS -- it's just Debian packages. And if the user has more than one patch which needs to be maintained separately, is it still is still trivial FOR HIM? (or her) Who is the user? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wed, Aug 02, 2006 at 08:31:29PM +0200, Eduard Bloch wrote: Really, I think that getting patches in darcs from people that are using darcs send is not only easier for me as a maintainer, but also easier Much easier as storing the mail attachment under debian/patches? I doubt. Yes, indeed it is. darcs send will send each original darcs record as a discrete change. darcs apply can run in an interactive mode to let the person approve (or not) each individual patch. The full commit log from the original person also comes along automatically. AND, there's no need to hack the Debian build infrastructure. for them as contributors. Plus it is really easy for people that don't grok darcs to just use normal tools to edit Debian source packages, create diffs, NMU packages, or whatever -- and for me to integrate their changes later. This is not the case for the other special-purpose patch tools. This does not really differ from the scenarios with patch management system. Yes it does. If I don't understand patch tool X, I have to learn how to use patch tool X before I can even begin hacking. Nobody has to learn Darcs to hack on my packages. As I make changes, I darcs record them. I use dbp-importorig to import new upstream sources -- this is just a script that untars them and uses darcs_load_dirs to import them as a changeset to the upstream branch. I use darcs pull (the darcs merge command) to pull it into my Debian tree, and that's that. Yes... and where is the big difference to other VCs except that you do not commit to a central repository immediately? (but you need to do it in an extra step in order to share the work). I am saying in this thread that *any* VC system beats the N different patch management tool scenario. I do believe that Darcs has compelling advantages over other VCs, but that is irrelevant for this point. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wed, Aug 02, 2006 at 11:04:53AM +0200, Josselin Mouette wrote: I agree, dpatch co seem to be more accessible: they are files you can touch; they're not an abstract concept (branch) which you can work with, but which is not tangible. This is another possible reason for SVN's success: branches are directories, which are a reasonably widespread concept among Unix developers. In fact, SVN is what looks the most closely to a distributed and versioned filesystem, which is how most packaging teams use it. While I agree this is a nice feature of svn, I don't think it's a reason for SVN's success. It is true that when you really need to work with branches and tags, doing it the svn way is ages more comfortable than the cvs way, but is still a burden. In my packaging experiences with collaborative maintenance on svn we use tags (a lot!) as history of changes and just because svn-buildpackages create tags automatically. We use branches for experimental changes, usually accompanying aggressive proposals to the whole team, playing the role of proof of concepts implementation. But that's it, we would have used cvs the same way. The real reason of svn success is that it is cvs done right. A workflow a lot of people is already familiar with, which tons of nuisance (but not all of them) less than cvs. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Re: Centralized darcs
Le mercredi 02 août 2006 à 15:34 -0500, John Goerzen a écrit : Ok, third time. Please do not do that: To: George Danchev [EMAIL PROTECTED] CC: debian-devel@lists.debian.org Then SET YOUR HEADERS to reflect that, like everyone else does. Which headers? (If you are talking about Mail-Followup-To, this is a non-standard header that many MUAs don't implement.) -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Centralized darcs
On Thursday 03 August 2006 00:11, Josselin Mouette took the opportunity to say: Le mercredi 02 août 2006 à 15:34 -0500, John Goerzen a écrit : Ok, third time. Please do not do that: To: George Danchev [EMAIL PROTECTED] CC: debian-devel@lists.debian.org Then SET YOUR HEADERS to reflect that, like everyone else does. Which headers? (If you are talking about Mail-Followup-To, this is a non-standard header that many MUAs don't implement.) Yeah, and privately setting Reply-To to the list is almost as bad as when the list manager software does it. It's a pity that most MUAs don't have a separate follow-up command either (for everyone's information, Mutt has one - press L to reply to list). IMHO, the best policy still is not to CC the author unless he asks for it. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpNjPfkXa5Ra.pgp Description: PGP signature
Re: Centralized darcs
On Wed, Aug 02, 2006 at 06:01:27PM +0300, George Danchev wrote: On Wednesday 02 August 2006 17:31, John Goerzen wrote: On Wed, Aug 02, 2006 at 05:20:26PM +0300, George Danchev wrote: debian/patches/ as separate file, how do I know how to update/remove/etc There would be no debian/patches. That could be bad sometimes, or most of the time. Some people prefer to have debian-specific patches (applied to the upstream source) separated and with comments appended, which leads to more fine-grained control. They're doing an NMU, not completely reauthoring the package. What do they care about the subtleties of some random other patch? update it as well. They can send a patch against the toplevel soruce package directory. Exactly. them ? How is that different from learning darcs patch system which might happend to be new for me. There is also git arch which also pretend to be a patch system at heart. Thus the diversity is the same as in different patch system / not necessary a bat thing though /. They can build and use the package just like normal. Somebody doesn't have to know how to use my VC in order to work on my package, which is different from the situation with the patch systems. But you lose debian specific patches to be clearly separated from the upstrem source (digging diff.gz for that is not fun), They're doing an NMU. diff.gz archaeology should not be necessary. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wed, Aug 02, 2006 at 06:31:18PM +0200, Frank Küster wrote: John Goerzen [EMAIL PROTECTED] wrote: I think people that are NMUing packages rarely care about this. When NMU'ing a package, I'd really appreciate to know which changes have which purpose and which specificity. In particular when trying to incorporate a fix provided by upstream - why the hell doesn't it apply cleanly? Did the Debian maintainer already try to address the problem differently, We have changelogs for that. If a maintainer doesn't fill out changelogs adequately, what are the chances that they're going to document their patches any better? - Matt
Re: Centralized darcs
On Wed, Aug 02, 2006 at 06:54:51PM +0300, George Danchev wrote: On Wednesday 02 August 2006 18:35, John Goerzen wrote: On Wed, Aug 02, 2006 at 06:01:27PM +0300, George Danchev wrote: How is that not true if one knows a given patch system and does know about your VCS and needs to work on one of your packages. Do they have They just apt-get source, hack away, and send me a diff. Also true for any debian patch system, but with the gain the debian specific No, it's not, because for most of them, the source that you get with apt-get source is a tar.gz file and a debian/ directory. You can NOT just hack away on that like you would any package. You MUST learn the specific tool to do ANYTHING. After apt-get source you get debian source package directory with debian/patches/ inside. Learing to add/remove/update patches is easy and if one is not able to learn that, better not to send any diff, waste of time. I'm going to be charitable and assume you haven't done any significant QA work. Working with any of the debian/patches management systems (and there are oh-so-many of them) is a pest, and having to learn how all of them work (if only to get a pre-patched source tree I can try and do useful work on) is a wholesale pest. They shouldn't be converting the package to use a patch system. They can send new patch to be included in debian/patches/, remove one, or If I am using darcs, or svn, or whatever, there is no debian/patches at all. I don't understand what you are saying here. Where are you debian specific patches you apply to the upstream source tree as patches in debian/patches/ do. Or your have orig.tar.gz already patched with these and which is no more original tar.gz, and diff.gz not containing these. This is forbidden by the policy as we know. And this adds confusion. fx: slaps forehead Of course you don't modify the orig.tar.gz. the diff.gz is capable of patching more than just the contents of debian/. But you lose debian specific patches to be clearly separated from the upstrem source (digging diff.gz for that is not fun), unless one knows where to find First, what is a Debian-specific patch? Isn't everything in diff.gz that? Right, but you have parts which touch upstream files (debian/patches/*), and parts which does not (debian/!patches). I prefer them to be clearly separated when the whole debian source package is unpacked. Why? You're doing an NMU. You don't need to know which patches need to be sent upstream. Maybe you mean just stuff in debian/. Well it's easy enough to filter that out. I think people that are NMUing packages rarely care about this. see above. What, exactly? - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wed, Aug 02, 2006 at 08:47:01PM +0300, George Danchev wrote: On Wednesday 02 August 2006 20:11, Otavio Salvador wrote: Frank Küster [EMAIL PROTECTED] writes: George Danchev [EMAIL PROTECTED] wrote: But you lose debian specific patches to be clearly separated from the upstrem source (digging diff.gz for that is not fun), unless one knows where to find First, what is a Debian-specific patch? Isn't everything in diff.gz that? Right, but you have parts which touch upstream files (debian/patches/*), and parts which does not (debian/!patches). I prefer them to be clearly separated when the whole debian source package is unpacked. Not only that. Many packages make changes to upstream files that are Debian-specific (e.g. for using infrastructure or libraries that don't exist outside), but also changes to upstream files that will/should be temporary because upstream will apply the same patch, has been asked to, or the patch has been taken from their development version. Iff we use a branch to each change we can have same behaviour using a SCM but anyone that would want to change or contrib changes will need to learn how we deal with this all. This is fine, but (again) you forget about your 'apt-get source' users, which are not supposed to be aware of your SCM, where your repo is, patches applied to the upstream source and why they have been applied. Do you think you can stick to one story for a whole thread? Do you want to know what patches are in there, or not? First you said I prefer them to be clearly separated when the whole debian source package is unpacked. and Some people prefer to have debian-specific patches (applied to the upstream source) separated and with comments appended (I presume you're part of the Some people). Yet now you're saying 'apt-get source' users [...] are not supposed to be aware of [...] patches applied to the upstream source and why they have been applied. Which is it? Clearly identified patches, or not supposed to be aware? I.e. if you have patches, do them debian way (using a debian patch system) Please identify the debian way, so I may start using it. Oh wait. There isn't any single Debian way. Never has been, almost certainly never will be. - Matt
Re: Centralized darcs
On Wed, Aug 02, 2006 at 08:36:18PM +0200, Eduard Bloch wrote: #include hallo.h * John Goerzen [Wed, Aug 02 2006, 01:01:51PM]: On Wed, Aug 02, 2006 at 08:47:01PM +0300, George Danchev wrote: to learn how we deal with this all. This is fine, but (again) you forget about your 'apt-get source' users, which NO. They need not care. They can just hack and send me diffs. My debian/changelog will already document what has been going on anyway. Heh. So they need two copies, one where they do modifications, then diff those and send you the diff. Or they need to change debian/changelog and learn to use interdiff. All that is more work that just callin dpatch_edit_patch foo. $ dpatch_edit_patch zsh: command not found: dpatch_edit_patch Yep, that was very little work. Even less benefit, though. Oh, you meant dpatch-edit-patch, perhaps? That's great, but there's plenty of packages that contain debian/patches/ were dpatch-edit-patch will get you nowhere. And when you do find a package where dpatch-edit-patch works, all it does, effectively, is make two copies, one where you do modifications, and then diff those and store the diff. Gee that sounds familiar. dpatch-edit-patch also suffers from the difficulty that you need to manually revert bits and pieces that you don't want in your final dpatch, like (for instance) updated changelog entries (which you made to make test builds to ensure that everything's working OK before going through the rigamarole of wrapping up the patch, and then reopening it again -- a full-tree diff, removal, and re-copying -- if you got it wrong. Why do dist.VCS fans always talk about patches like the would rain from the sky just so? Because we've moved on from being our own VCS (a la dpatch) and are now using an automated tool to track things *for* us, instead. So now working with patches is simple and straightforward. are not supposed to be aware of your SCM, where your repo is, patches applied to the upstream source and why they have been applied. I.e. if you have patches, do them debian way (using a debian patch system) even using SCM to manage your whole packaging. Your orig.tar.gz must be really original tar.gz, and your diff.gz should hold whole debian-specific thing. I am quite well aware of that and it is trivial to do. And if the user has more than one patch which needs to be maintained separately, is it still is still trivial FOR HIM? (or her) HE (or she) can work out how to make things work FOR HIMSELF (or herself). Chances are, no matter which system you choose, someone out there isn't going to like it. So why hamstring yourself with a sub-standard system that you don't like working with, just to please some minority of users? - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Thursday 03 August 2006 00:45, Matthew Palmer wrote: On Wed, Aug 02, 2006 at 08:47:01PM +0300, George Danchev wrote: On Wednesday 02 August 2006 20:11, Otavio Salvador wrote: Frank Küster [EMAIL PROTECTED] writes: George Danchev [EMAIL PROTECTED] wrote: But you lose debian specific patches to be clearly separated from the upstrem source (digging diff.gz for that is not fun), unless one knows where to find First, what is a Debian-specific patch? Isn't everything in diff.gz that? Right, but you have parts which touch upstream files (debian/patches/*), and parts which does not (debian/!patches). I prefer them to be clearly separated when the whole debian source package is unpacked. Not only that. Many packages make changes to upstream files that are Debian-specific (e.g. for using infrastructure or libraries that don't exist outside), but also changes to upstream files that will/should be temporary because upstream will apply the same patch, has been asked to, or the patch has been taken from their development version. Iff we use a branch to each change we can have same behaviour using a SCM but anyone that would want to change or contrib changes will need to learn how we deal with this all. This is fine, but (again) you forget about your 'apt-get source' users, which are not supposed to be aware of your SCM, where your repo is, please, find 'SCM' in the above row, thanks. patches applied to the upstream source and why they have been applied. Do you think you can stick to one story for a whole thread? Yes, I think I do. Do you want to know what patches are in there, or not? First you said I prefer them to be clearly separated when the whole debian source package is unpacked. and Some people prefer to have debian-specific patches (applied to the upstream source) separated and with comments appended (I presume you're part of the Some people). Yet now you're saying 'apt-get source' users [...] are not supposed to be aware of [...] patches applied to the upstream What I wrote is 'are not supposed to be aware of your SCM' in the first place (just look above), which makes significant difference. source and why they have been applied. Which is it? Clearly identified patches, or not supposed to be aware? Obviously 'SCM' is what you missed above, which led you to such a confusion. Yes, people might be able to apt-get source and have patches which are to be (un)applied to the upstream source clearly identified without having to bother with any SCM to do the _patching_ work. (SCM == VCS) I.e. if you have patches, do them debian way (using a debian patch system) Please identify the debian way, so I may start using it. Oh wait. There isn't any single Debian way. Never has been, almost certainly never will be. There is no signle SCM you can do packaging either. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Mail headers (was Re: Centralized darcs)
On Thu, Aug 03, 2006 at 12:28:35AM +0200, Magnus Holmgren wrote: On Thursday 03 August 2006 00:11, Josselin Mouette took the opportunity to say: Le mercredi 02 août 2006 à 15:34 -0500, John Goerzen a écrit : Ok, third time. Please do not do that: To: George Danchev [EMAIL PROTECTED] CC: debian-devel@lists.debian.org Then SET YOUR HEADERS to reflect that, like everyone else does. Which headers? (If you are talking about Mail-Followup-To, this is a non-standard header that many MUAs don't implement.) Yeah, and privately setting Reply-To to the list is almost as bad as when the list manager software does it. The whole point of Reply-To is to allow the sender to specify where replies should be sent. There's no need for Mail-Followup-To. I agree that the list manager shouldn't set it, but there's nothing wrong with it being privately set. If you want your reply sent somewhere other than where the sender thinks it should be going, then you should be cognizant enough to change where the email is being sent and wouldn't care about Reply-To or M-F-T anyway. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Centralized darcs
On Thu, Aug 03, 2006 at 02:08:00AM +0300, George Danchev wrote: On Thursday 03 August 2006 00:45, Matthew Palmer wrote: On Wed, Aug 02, 2006 at 08:47:01PM +0300, George Danchev wrote: On Wednesday 02 August 2006 20:11, Otavio Salvador wrote: Frank Küster [EMAIL PROTECTED] writes: George Danchev [EMAIL PROTECTED] wrote: But you lose debian specific patches to be clearly separated from the upstrem source (digging diff.gz for that is not fun), unless one knows where to find First, what is a Debian-specific patch? Isn't everything in diff.gz that? Right, but you have parts which touch upstream files (debian/patches/*), and parts which does not (debian/!patches). I prefer them to be clearly separated when the whole debian source package is unpacked. Not only that. Many packages make changes to upstream files that are Debian-specific (e.g. for using infrastructure or libraries that don't exist outside), but also changes to upstream files that will/should be temporary because upstream will apply the same patch, has been asked to, or the patch has been taken from their development version. Iff we use a branch to each change we can have same behaviour using a SCM but anyone that would want to change or contrib changes will need to learn how we deal with this all. This is fine, but (again) you forget about your 'apt-get source' users, which are not supposed to be aware of your SCM, where your repo is, please, find 'SCM' in the above row, thanks. I did. Using an SCM and shipping a monolithic diff.gz makes it *easier* for the 'apt-get source' user to work with the package, because there isn't a randomly-chosen debian patch manager in the way to confuse and confound. source and why they have been applied. Which is it? Clearly identified patches, or not supposed to be aware? Obviously 'SCM' is what you missed above, which led you to such a confusion. Yes, people might be able to apt-get source and have patches which are to be (un)applied to the upstream source clearly identified without having to bother with any SCM to do the _patching_ work. (SCM == VCS) They don't have to know anything about the SCM to manipulate a monolithic diff.gz package. This is in contrast to a patch-managed package, where you *MUST* learn the patch management system to make a minimal, useful NMU patch. I.e. if you have patches, do them debian way (using a debian patch system) Please identify the debian way, so I may start using it. Oh wait. There isn't any single Debian way. Never has been, almost certainly never will be. There is no signle SCM you can do packaging either. No, there isn't, but the difference is that the SCM doesn't get in your way. - Matt
Re: Centralized darcs (was Re: centralized bzr)
On Tue, 01 Aug 2006, John Goerzen wrote: Darcs has a nice way of pushing patches via e-mail, with GPG signatures even. These can be processed in an automated way on the server, verified against, for instance, the Debian keyring, and then applied to the repository. Which would also be a far superior way to deal with centralized bzr. It protects the repository against screwups on the developer's local bzr package (he might be running an alpha version, for example :P), and it provides a central point of control, which is interesting *when dealing with centralized repositories*. Heck, we could adopt even the signed-of-by/acked-by workflow from the Linux kernel where desired... I think it would work even nicer. Agreed. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs (was Re: centralized bzr)
also sprach John Goerzen [EMAIL PROTECTED] [2006.08.01.2055 +0100]: Darcs has a nice way of pushing patches via e-mail, with GPG signatures even. These can be processed in an automated way on the server, verified against, for instance, the Debian keyring, and then applied to the repository. This feature is in development for bzr, called the smart server. Just for completeness. John, are you actually using the workflow you describe for maintenance of Debian packages? Single or team maintenance? Could you elaborate a bit? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system life moves pretty fast. if you don't stop and look around once in awhile, you could miss it. -- ferris bueller signature.asc Description: Digital signature (GPG/PGP)
Re: Centralized darcs (was Re: centralized bzr)
On Tue, Aug 01, 2006 at 09:06:19PM +0100, martin f krafft wrote: This feature is in development for bzr, called the smart server. Just for completeness. John, are you actually using the workflow you describe for maintenance of Debian packages? Single or team maintenance? Could you elaborate a bit? I do use darcs for almost all of my Debian packages. You can find my darcs repositories at http://darcs.complete.org/debian/ In darcs, every working copy is a repository, and a branch is just a get, and a commit to the canonical location is just a merge (darcs push). I've been using darcs push, which sends the patch over ssh, instead of the e-mail thing since I am the only committer to my repos. But sending a GPG-signed patch bundle can be as easy as darcs send and David Roundy has posted recipes for processing those on the server. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Tue, Aug 01, 2006 at 05:36:07PM -0300, Otavio Salvador wrote: Darcs has a nice way of pushing patches via e-mail, with GPG signatures even. These can be processed in an automated way on the server, verified against, for instance, the Debian keyring, and then applied to the repository. The only bad thing I know about darcs, for my kinda of use, is the miss of file permission recoring. That's annoying for packaging and like. It is a bit annoying, but --set-scripts-executable does the right thing in about 97% of cases. That can be made the default quite easily. diff also doesn't preserve permissions, so some are using debian/rules anyway. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
