Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
On 2004-09-04 Colin Watson <[EMAIL PROTECTED]> wrote: > On Fri, Sep 03, 2004 at 11:02:26PM +0200, Michael Schiansky wrote: [...] > > Why do you call dpatch 'obfuscated' ? [...] > Compared to simply making the source changes directly, it's obfuscated. Agreed. > It's also obfuscated for users who can no longer use 'dpkg-source -x' > (as documented since the dawn of time) to see the source code from which > programs are built; instead, they have to hunt through a maze of twisty > makefiles in order to work out the correct debian/rules invocation to > produce the patched source, which is different for almost every patch > system used in Debian and is often poorly documented. dpatch is actually documented quite well. (The packaged dbs also features usable documentation.) Hell starts with the homegrown patch-systems or cdbs. > I recommend using a good revision control system instead, which offers > similar benefits to developers while leaving things clear for users. I disagree that this is so clear-cut. The still most popular system CVS simply does not offer this functionality. e.g. you have two distinct patchsets: patchset A fixing issue A touching files 1, 2, and 3 and patchset B fixing issue B touching files 2, 3 and 4. CVS simply does not offer the possibility to keep these patchsets separate (except for checking in diff-files.) over several generations of a file. I doubt svn favours a lot better in this respect (otherwise why would xfree-packaging still use a dpatch-like system?) Bitkeeper can do it, and I guess arch, too. If you are thinking "use separate .diff files in your repository but upload a plain diff.gz with everything mangled together" I disagree. I'd rather have slightly more complicated but usable sourcepackages in the archive. (Think of maintainer goes MIA or NMU.) cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash"
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
On Sat, Sep 04, 2004 at 09:17:20AM +0200, Andreas Metzler wrote: > On 2004-09-04 Colin Watson <[EMAIL PROTECTED]> wrote: > > I recommend using a good revision control system instead, which offers > > similar benefits to developers while leaving things clear for users. > > I disagree that this is so clear-cut. The still most popular system > CVS simply does not offer this functionality. e.g. you have two > distinct patchsets: patchset A fixing issue A touching files 1, 2, > and 3 and patchset B fixing issue B touching files 2, 3 and 4. > > CVS simply does not offer the possibility to keep these patchsets > separate (except for checking in diff-files.) over several generations > of a file. CVS clearly doesn't count as a good revision control system (any more, at least). > I doubt svn favours a lot better in this respect (otherwise why would > xfree-packaging still use a dpatch-like system?) Subversion at least has changesets, so it's not anywhere near as bad. It doesn't have proper merge tracking yet. This is not necessarily a big problem if you don't have too many branches of the repository. I don't think "xfree86 still uses separated patches" implies that Subversion can't do what you want here; it implies that the xfree86 maintainers didn't want to overhaul their build system too much when they moved to Subversion and have had better things to do since, but that's about it. I believe xfree86's build system is derived from an early version of DBS. > Bitkeeper can do it, and I guess arch, too. Arch can, yes. > If you are thinking "use separate .diff files in your repository but > upload a plain diff.gz with everything mangled together" I disagree. > I'd rather have slightly more complicated but usable sourcepackages in > the archive. I don't mind if there's also a debian/patches/ directory in the source package (yes, I know that would double the size of the diff, but I don't think that's important), but I think it should be a requirement that 'dpkg-source -x foo.dsc' should produce the code that is built. (I don't expect this requirement to start being fulfilled again in Debian any time soon, but that doesn't stop me trying to stop the situation getting worse.) Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
Colin Watson <[EMAIL PROTECTED]> writes: > On Fri, Sep 03, 2004 at 11:02:26PM +0200, Michael Schiansky wrote: >> On Fri, Sep 03, 2004 at 07:04:52PM +0100, Colin Watson wrote: >> > ... or indeed any such obfuscated patching system ... >> >> Why do you call dpatch 'obfuscated' ? >> Before I used it for one of my packages i quickly checked the code and it >> simply works. No big fancy stuff etc. >> >> Did I miss a part? > > Compared to simply making the source changes directly, it's obfuscated. Personally I find a bunch of unrelated changes lumped together in a big diff (like, say, in openssh to pick a purely random example) is a much worse obfuscation than being forced to learn './debian/rules patch'. > I recommend using a good revision control system instead, which > offers similar benefits to developers while leaving things clear for > users. A good revision control system is of little use to other developers if it's not available to them ... -- James
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
On Sat, Sep 04, 2004 at 02:50:35PM +0100, James Troup wrote: > Colin Watson <[EMAIL PROTECTED]> writes: > > On Fri, Sep 03, 2004 at 11:02:26PM +0200, Michael Schiansky wrote: > >> Why do you call dpatch 'obfuscated' ? > >> Before I used it for one of my packages i quickly checked the code and it > >> simply works. No big fancy stuff etc. > >> > >> Did I miss a part? > > > > Compared to simply making the source changes directly, it's obfuscated. > > Personally I find a bunch of unrelated changes lumped together in a > big diff (like, say, in openssh to pick a purely random example) is a > much worse obfuscation than being forced to learn './debian/rules > patch'. Or 'debian/rules patched-source' or 'debian/rules source.make' or 'make -f debian/scripts/somethingorother blah' or any number of other things; every time I unpack a separated-patches source package and want to look at it I always have to either read lots of twisty included makefiles (and my make is pretty fluent, I dread to think what it would be like if it weren't) or else run random debian/rules targets until I find one that works. Sometimes I just give up, run 'debian/rules build', and Ctrl-C it part-way through, which is just crap. If they all had the common decency to use the same simple target name I probably wouldn't mind, but every patch system in Debian is so freaking NIH that they're never going to cooperate enough for that to happen. openssh is not my most shining example of source packaging; it's maintained in a strange way (CVS, God help me) for historical reasons. Some day I'll fix it. > > I recommend using a good revision control system instead, which > > offers similar benefits to developers while leaving things clear for > > users. > > A good revision control system is of little use to other developers if > it's not available to them ... Like I say, I'm happy with the patches being exposed in debian/patches/, I just want them pre-applied if they're there. perl does this, and it's *so* much easier to deal with. Lots of people arguing for patch systems are arguing for their own convenience, not for other people's. Revision control should be able to solve that part of the puzzle. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
Hi, On Fri, Sep 03, 2004 at 11:00:47PM +0200, Michael Schiansky wrote: > Hi > > On Fri, Sep 03, 2004 at 07:26:56PM +0200, Nicolas Boullis wrote: > > >please use dpatch to manage paches on upstream source > > Since when is the use of dpatch mandatory? > It was never and hopefully will never be. > > I simply like dpatch. I also like dpatch, but I would not try to force Kevin to use it... Nicolas
RFS: qtorrent - PyQT client for the BitTorrent network
I am looking for a sponsor for QTorrent. It is a PyQt GUI for BitTorrent and allows easy configuration and allows multiple torrents to be open from within a single application. Here is the relevant information package: qtorrent Upstream URL: http://thegraveyard.org Upstream Author: Hyriand <[EMAIL PROTECTED]> Debian URL: http://www.angelfire.com/linux/debian_1/qtorrent.tar.gz Unlike the bittorrent package currently in Debian, QTorrent uses Python and the QT widgets to create a clean interface. QTorrent includes the experimental client by TheSHAD0W, with useful features such as upload rate limiting, and handles multiple torrents in one window, reducing desktop clutter. The package is pbuilder and lintian clean and is buildable against Debian's default python version.
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
On 2004-09-04 Colin Watson <[EMAIL PROTECTED]> wrote: > On Fri, Sep 03, 2004 at 11:02:26PM +0200, Michael Schiansky wrote: [...] > > Why do you call dpatch 'obfuscated' ? [...] > Compared to simply making the source changes directly, it's obfuscated. Agreed. > It's also obfuscated for users who can no longer use 'dpkg-source -x' > (as documented since the dawn of time) to see the source code from which > programs are built; instead, they have to hunt through a maze of twisty > makefiles in order to work out the correct debian/rules invocation to > produce the patched source, which is different for almost every patch > system used in Debian and is often poorly documented. dpatch is actually documented quite well. (The packaged dbs also features usable documentation.) Hell starts with the homegrown patch-systems or cdbs. > I recommend using a good revision control system instead, which offers > similar benefits to developers while leaving things clear for users. I disagree that this is so clear-cut. The still most popular system CVS simply does not offer this functionality. e.g. you have two distinct patchsets: patchset A fixing issue A touching files 1, 2, and 3 and patchset B fixing issue B touching files 2, 3 and 4. CVS simply does not offer the possibility to keep these patchsets separate (except for checking in diff-files.) over several generations of a file. I doubt svn favours a lot better in this respect (otherwise why would xfree-packaging still use a dpatch-like system?) Bitkeeper can do it, and I guess arch, too. If you are thinking "use separate .diff files in your repository but upload a plain diff.gz with everything mangled together" I disagree. I'd rather have slightly more complicated but usable sourcepackages in the archive. (Think of maintainer goes MIA or NMU.) cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
On Sat, Sep 04, 2004 at 09:17:20AM +0200, Andreas Metzler wrote: > On 2004-09-04 Colin Watson <[EMAIL PROTECTED]> wrote: > > I recommend using a good revision control system instead, which offers > > similar benefits to developers while leaving things clear for users. > > I disagree that this is so clear-cut. The still most popular system > CVS simply does not offer this functionality. e.g. you have two > distinct patchsets: patchset A fixing issue A touching files 1, 2, > and 3 and patchset B fixing issue B touching files 2, 3 and 4. > > CVS simply does not offer the possibility to keep these patchsets > separate (except for checking in diff-files.) over several generations > of a file. CVS clearly doesn't count as a good revision control system (any more, at least). > I doubt svn favours a lot better in this respect (otherwise why would > xfree-packaging still use a dpatch-like system?) Subversion at least has changesets, so it's not anywhere near as bad. It doesn't have proper merge tracking yet. This is not necessarily a big problem if you don't have too many branches of the repository. I don't think "xfree86 still uses separated patches" implies that Subversion can't do what you want here; it implies that the xfree86 maintainers didn't want to overhaul their build system too much when they moved to Subversion and have had better things to do since, but that's about it. I believe xfree86's build system is derived from an early version of DBS. > Bitkeeper can do it, and I guess arch, too. Arch can, yes. > If you are thinking "use separate .diff files in your repository but > upload a plain diff.gz with everything mangled together" I disagree. > I'd rather have slightly more complicated but usable sourcepackages in > the archive. I don't mind if there's also a debian/patches/ directory in the source package (yes, I know that would double the size of the diff, but I don't think that's important), but I think it should be a requirement that 'dpkg-source -x foo.dsc' should produce the code that is built. (I don't expect this requirement to start being fulfilled again in Debian any time soon, but that doesn't stop me trying to stop the situation getting worse.) Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
Colin Watson <[EMAIL PROTECTED]> writes: > On Fri, Sep 03, 2004 at 11:02:26PM +0200, Michael Schiansky wrote: >> On Fri, Sep 03, 2004 at 07:04:52PM +0100, Colin Watson wrote: >> > ... or indeed any such obfuscated patching system ... >> >> Why do you call dpatch 'obfuscated' ? >> Before I used it for one of my packages i quickly checked the code and it >> simply works. No big fancy stuff etc. >> >> Did I miss a part? > > Compared to simply making the source changes directly, it's obfuscated. Personally I find a bunch of unrelated changes lumped together in a big diff (like, say, in openssh to pick a purely random example) is a much worse obfuscation than being forced to learn './debian/rules patch'. > I recommend using a good revision control system instead, which > offers similar benefits to developers while leaving things clear for > users. A good revision control system is of little use to other developers if it's not available to them ... -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
On Sat, Sep 04, 2004 at 02:50:35PM +0100, James Troup wrote: > Colin Watson <[EMAIL PROTECTED]> writes: > > On Fri, Sep 03, 2004 at 11:02:26PM +0200, Michael Schiansky wrote: > >> Why do you call dpatch 'obfuscated' ? > >> Before I used it for one of my packages i quickly checked the code and it > >> simply works. No big fancy stuff etc. > >> > >> Did I miss a part? > > > > Compared to simply making the source changes directly, it's obfuscated. > > Personally I find a bunch of unrelated changes lumped together in a > big diff (like, say, in openssh to pick a purely random example) is a > much worse obfuscation than being forced to learn './debian/rules > patch'. Or 'debian/rules patched-source' or 'debian/rules source.make' or 'make -f debian/scripts/somethingorother blah' or any number of other things; every time I unpack a separated-patches source package and want to look at it I always have to either read lots of twisty included makefiles (and my make is pretty fluent, I dread to think what it would be like if it weren't) or else run random debian/rules targets until I find one that works. Sometimes I just give up, run 'debian/rules build', and Ctrl-C it part-way through, which is just crap. If they all had the common decency to use the same simple target name I probably wouldn't mind, but every patch system in Debian is so freaking NIH that they're never going to cooperate enough for that to happen. openssh is not my most shining example of source packaging; it's maintained in a strange way (CVS, God help me) for historical reasons. Some day I'll fix it. > > I recommend using a good revision control system instead, which > > offers similar benefits to developers while leaving things clear for > > users. > > A good revision control system is of little use to other developers if > it's not available to them ... Like I say, I'm happy with the patches being exposed in debian/patches/, I just want them pre-applied if they're there. perl does this, and it's *so* much easier to deal with. Lots of people arguing for patch systems are arguing for their own convenience, not for other people's. Revision control should be able to solve that part of the puzzle. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
Hi, On Fri, Sep 03, 2004 at 11:00:47PM +0200, Michael Schiansky wrote: > Hi > > On Fri, Sep 03, 2004 at 07:26:56PM +0200, Nicolas Boullis wrote: > > >please use dpatch to manage paches on upstream source > > Since when is the use of dpatch mandatory? > It was never and hopefully will never be. > > I simply like dpatch. I also like dpatch, but I would not try to force Kevin to use it... Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: qtorrent - PyQT client for the BitTorrent network
I am looking for a sponsor for QTorrent. It is a PyQt GUI for BitTorrent and allows easy configuration and allows multiple torrents to be open from within a single application. Here is the relevant information package: qtorrent Upstream URL: http://thegraveyard.org Upstream Author: Hyriand <[EMAIL PROTECTED]> Debian URL: http://www.angelfire.com/linux/debian_1/qtorrent.tar.gz Unlike the bittorrent package currently in Debian, QTorrent uses Python and the QT widgets to create a clean interface. QTorrent includes the experimental client by TheSHAD0W, with useful features such as upload rate limiting, and handles multiple torrents in one window, reducing desktop clutter. The package is pbuilder and lintian clean and is buildable against Debian's default python version. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
