Re: RFS: vfu (updated package)
OoO En cette soirée bien amorcée du vendredi 30 mai 2008, vers 22:42, William Vera [EMAIL PROTECTED] disait: In fact, is not a bug, because vfu say 'support' for list and read, does not depend on them (unzip, bzip2, etc) for build o run the program. Well, without unzip, vfu is unable to read a zip file. Without tar and gzip, it is not able to read a tar.gz. If you look at wrappers in rx/, you see that they use tar, unzip, etc. should include them in control then? Yes. As Depends or as Recommends. Moreover, those wrappers are some security issue. They use predictable name in a world writable directory (/tmp/XX.rx.cache). They should use mktemp based filename instead. Suggests a patch for this case? You should discuss this issue with upstream. The cache should survive accross invocations so you cannot just use mktemp. vfu should provide those wrappers a unique directory to store this cache. -- BOFH excuse #269: Melting hard drives pgpFn3ePm5w9f.pgp Description: PGP signature
Re: RFS: vfu (updated package)
Hi 2008/5/31 Vincent Bernat [EMAIL PROTECTED]: OoO En cette soirée bien amorcée du vendredi 30 mai 2008, vers 22:42, William Vera [EMAIL PROTECTED] disait: In fact, is not a bug, because vfu say 'support' for list and read, does not depend on them (unzip, bzip2, etc) for build o run the program. Well, without unzip, vfu is unable to read a zip file. Without tar and gzip, it is not able to read a tar.gz. If you look at wrappers in rx/, you see that they use tar, unzip, etc. should include them in control then? Yes. As Depends or as Recommends. Done, package updated: http://mentors.debian.net/debian/pool/main/v/vfu/ Moreover, those wrappers are some security issue. They use predictable name in a world writable directory (/tmp/XX.rx.cache). They should use mktemp based filename instead. Suggests a patch for this case? You should discuss this issue with upstream. The cache should survive accross invocations so you cannot just use mktemp. vfu should provide those wrappers a unique directory to store this cache. I sent an email to upstream to discuss about it. I think that will be a new upstream version. Thanks -- BOFH excuse #269: Melting hard drives -- William Vera [EMAIL PROTECTED] PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need some tips on building Debian packages
* Paul Johnson [EMAIL PROTECTED] [080530 22:08]: Keep in mind that my background is in RPM building, where the emphasis is on distributing pristine source code. I was initially shocked/dismayed by the Debian approach because the source code gets untarred and fiddled with by the packager. Some of the example guides that people referred me to may have been bad examples--packagers were opening the source directory and liberally applying patches and making changes, and all of those fiddles were getting wrapped up into the one big diff file, making it impossible to figure out who did what. Please note that this is all a matter of perspective. I'm shocked every time trying to look at source prms, which are very effective in both hiding the pristine source and the differences from me. (As opposed to the Debian way, where you are supposed to have the original pristine tar file and cleary seperated differences in unversaly readable format.) The format has indeed a serious disadvantage that done natively in a single patch without additional descriptions, it is hard to read this, but unlike source rpms, it is at least getable without needing special programs or magic perl scripts. There's not much information on how to manage patches in the Debian New Maintainer's Guide, Ideally, you do not need patches at all, or only temporary until upstream includes them. Thus I think a longer descriptions would be out of scope for the New Maintainer's Guide. (Though the description in Developer's Reference looks a bit too shot, perhaps it should be modernized a bit). I keep wondering, If the goal is to re-distribute 'pristine' source code and patches, why doesn't Debian discourage users from untarring the sourced code? I don't understand. Why should anyone want to not unpack the source code? How are you supposed to build it without source code? Why can't you make it so the debian directory is not inside the source tree? What advantages would this have? It would needlessly complicate the format, makeing it harder for people to see what we have changed. After configuring those, I try to do a package build. While testing this out, I realize I've made some mistakes while attempting to revise the Makefile to match the packaging requirements. It appears to me that I have to 1) move the debian directory to a safe place, 2) erase the code tree, 3) untar a fresh copy, 4) copy the debian directory back into the source tree, and 5) start over trying to fix the Makefile. Why do you think you need to do this? Is that how you do it? One suggestion I receive is to do this work in a directory managed by rcs or subversion. I think that would be fine too, but harder to set up when you just want to quickly build some small package that somebody distributed for, say, RedHat or such. And the Debian diff for the package would then pick up all the rcs files, right? You can tell dpkg-source (or dpkg-buildpackage which you will usually call to call dpkg-source for you) to exclude some files using the -i option. In a test case I was working on, the build failed because of a mismatch between the libtool automake that were used to create the source_orig.tar.gz file and the versions available on the current system. As a result, it was necessary to run autogen.sh in the source directory before trying configure. That process creates a bunch of files that should NOT be included in the Debian diff file, such as changes in config.sub or such, but the Debian package does include those things. In the Debian aproach you have to supply a clean target in debian/rules that undoes all the changes you did to it. If you run autogen.sh (or autoreconf if it is a modern enough package), you just delete all the files in generates/renews in the clean target. Having the single .diff.gz file is an advantage here: you just take a look at it (for example using diffstat) and see what was modified in your build. It occurred to me that I could try to work around this by using a build directory that is completely outside of the source code tree. In many packages that use autotools, we've found it convenient to build outside of the source tree and add the --srcdir option to the configure command. This leaves the source completely unchanged. This is indeed a possible way and many Debian packages do this. But many upstream build systems do not support this (even autotools using packages are often buggy in that regard). And for the majority of packages this is not needed, as it is a very absurd thing for a build system to modify the source and not properly clean up after it. (And it is very easy to catch, just take a look at the diff). I've not succeeded in doing this while building a Debian package, however, because it seems to always want to build stuff in the source tree itself. Try again then. Using something like produced by dh_make, it should mostly be replacing the ./configure call with a mkdir builddir cd
Re: RFS: hwinfo (updated package)
On Saturday 31 May 2008, William Vera wrote: Dear mentors, Hi, I am looking for a sponsor for the new version 14.17-1 of my package hwinfo. Looks solid. Uploaded. -- 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 signature.asc Description: This is a digitally signed message part.
Re: Need some tips on building Debian packages
Paul Johnson wrote: While testing this out, I realize I've made some mistakes while attempting to revise the Makefile to match the packaging requirements. It appears to me that I have to 1) move the debian directory to a safe place, 2) erase the code tree, 3) untar a fresh copy, 4) copy the debian directory back into the source tree, and 5) start over trying to fix the Makefile. Is that how you do it? One suggestion I receive is to do this work in a directory managed by rcs or subversion. I think that would be fine too, but harder to set up when you just want to quickly build some small package that somebody distributed for, say, RedHat or such. And the Debian diff for the package would then pick up all the rcs files, right? Best is to work with dpatch files. Get a package that has some to see how it works (so you can read the debian/rules and debian/patches folder content). You an take libdbi in SID, that I (try my best to) maintain, as an example. I don't know how other do, but this is work flow. If other have more efficient way, please correct me, there's always room for improvements. Let's say the package is named x in version 1.01. 1 - I detect a patch that has to be done in x.c and x.h, as let's say 2 path have to be adapted to the Debian file system standard. So I first do cp x.c x.c.orig and cp x.h x.h.orig. 2 - I do whatever changes I want to x.c x.h. If I do a mistake, I always have the .orig in case. 3 - When I'm done with testing, I do cd .., then: diff -u x-1.01/x.c.orig x-1.01/x.c \ x-1.01/debian/patches/0001-x.c_change_path_to_var_lib_x.dpatch Then same for x.h 4 - I add the dpatch header by hand to x.c x.h patches in x-1.01/debian/patches/ (is there a better way than doing this header by hand???). 5 - I build the list of patches 6 - I remove the .orig files. You can do this process as many times as you want, I found that it's preferable to have one dpatch per original source file, as this minimize the possibility to fail patching in an eventual new upstream release. In a test case I was working on, the build failed because of a mismatch between the libtool automake that were used to create the source_orig.tar.gz file and the versions available on the current system. As a result, it was necessary to run autogen.sh in the source directory before trying configure. That process creates a bunch of files that should NOT be included in the Debian diff file, such as changes in config.sub or such, but the Debian package does include those things. As other said, you can safely erase any file in the debian/rules clean target, if they are generated during the build (otherwise, they will be included in the diff.gz). Make it so after a call of debian/rules clean (you can call this on the shell, it works...) your sources are exactly the same as when you first extracted them. A very quick test to know that no unwanted files are in the diff.gz is to do: zcat x_1.01-1.diff.gz | grep +++. This gives you a quick list of patched files. It occurred to me that I could try to work around this by using a build directory that is completely outside of the source code tree. In many packages that use autotools, we've found it convenient to build outside of the source tree and add the --srcdir option to the configure command. This is REALLY the RPM way. Forget about it, it doesn't fit the Debian system at all, you would complicate things. This leaves the source completely unchanged. I've not succeeded in doing this while building a Debian package, however, because it seems to always want to build stuff in the source tree itself. In the process of changing that, I've become confused about the sorting of installed files into packages. I'm building library packages and haven't yet mastered the problem of installing the files into debian/tmp and then using package.listing files to specify the files that need to be selected for each Debian package. As much as I know, the debian/tmp folder is to be forgotten. Use debian/x instead, as a lib will have to build a libx1-dev and a libx1 package (and eventually a libx-doc). Generally, best option is to use the upstream Makefile and do: $(MAKE) install DESTDIR=$(CURDIR)/debian/libx1 in your install target of debian/rules, and later on the same target, move files, maybe like this if it fits your package: mkdir -p debian/libx1-dev/usr mv debian/libx1/usr/include debian/libx1-dev/usr There are other ways, like using a debian/libx1-dev.install with in it: include/x/x.h /usr/include/x and then in the debian/rules file install target, you just delete the files with rm from the debian/libx folder. Both work, I don't think one is better than another, maybe try to use the method that will produce the less number of lines in all the debian files. You are quite free to use what you want, when doing packaging, as much as I know. I hope this helped, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of
New Packager question again: can you point me to a not flawed package?
OK, thanks for the advice yesterday. I think we are agreeing on
principle, it is just the implementation that's concerning me now.
I'm starting back at the basics. I'm building stuff for Ubuntu
workstations. Because I don't know how to manage patches (did not
decipher quilt or cdbs yet, but will eventually), I'm starting with a
simple problem. Here's one of my jobs. I need to make a package that
will insert a single text file under /etc/emacs/site-lisp. I think I
need to make a meta package and just add an emacsen-startup file under
the debian directory. I'm trying to study how to do that by looking
at examples.
You may recall I was the one who asked yesterday Why do you encourage
packagers to open the source code and fool around? I got answers
which indicate that the source code generally should not be changed
directly, and all changes should either be in patches that are stored
in the debian/patches directory or in the other configuration files
like rules. I say Yes, I agree I am used to that from RPM
building. I think you should force people to prove they can build
packages by applying patches to an original, untouched tarball or
putting details in a debian directory.
I just need to see some examples of how this can be done. I wonder if
I'm running into a problem that is peculiar to Ubuntu. I can't find
packages that follow the principles we were discussing yesterday. In
fact, I can't find any that adhere to this guideline in a complete
way. (It appears to me the temptation is too great to make
undocumented changes in source code.)
For example, consider the source for the ess package, an Emacs addon
that I use (apt-get source ess). Peruse the diff file, and you
find several items that are not in debian rules, such as this:
--- ess-5.3.0.orig/lisp/ess-mode.el
+++ ess-5.3.0/lisp/ess-mode.el
@@ -167,6 +167,8 @@
(define-key ess-mode-map { 'ess-electric-brace)
(define-key ess-mode-map } 'ess-electric-brace)
(define-key ess-mode-map \e\C-h'ess-mark-function)
+ (if (featurep 'xemacs)
+ (define-key ess-mode-map [(meta backspace)] 'backward-kill-word))
(define-key ess-mode-map \e\C-q'ess-indent-exp)
(define-key ess-mode-map \177 'backward-delete-char-untabify)
(define-key ess-mode-map \t'ess-indent-command)
I think this should be a patch. If Debian guidelines required people
to prove that they can build packages without opening (and exposing
the source to possible editing), things like this would go into
patches. I think. Isn't that what people were recommending to me
yesterday in here?
I was thinking, well, maybe it is just that one package. I also use
the emacs addon auctex. So I got the source for that, examined the
diff, and found many changes that were confined to the debian
directory, but also plenty that float about in various parts of the
source code. Consider just a couple, which don't seem trivial to my
eye:
--- auctex-11.84.orig/tex.el
+++ auctex-11.84/tex.el
@@ -1292,11 +1292,14 @@
(directory-files (or master-dir .) nil regexp
(if files
(when (or (not TeX-clean-confirm)
- (dired-mark-pop-up *Deletions* 'delete
-(if ( (length files) 1)
-files
- (cons t files))
-'y-or-n-p Delete files? ))
+ (condition-case nil
+ (dired-mark-pop-up *Deletions* 'delete
+(if ( (length files) 1)
+files
+ (cons t files))
+'y-or-n-p Delete files? )
+ (wrong-type-argument ; e.g. with Emacs 21
+(y-or-n-p (format Delete %S? (car files))
(dolist (file files)
(delete-file (concat master-dir file
(message No files to be deleted
--- auctex-11.84.orig/preview/Makefile.in
+++ auctex-11.84/preview/Makefile.in
@@ -60,7 +60,7 @@
install-hint:
@echo 'Congratulations! Build is complete.'
- @echo
+ @echo
@echo 'Now, run make install as root, or whatever user has
permissions'
@echo 'to write to the install directory.'
@@ -130,13 +130,13 @@
clean:
rm -f latex.out testdocstrip.tex preview-latex.el
- rm -rf *.prv *.elc *~ *.aux *.dvi *.log
+ rm -rf *.prv *.elc *~ *.aux *.dvi *.log
(cd latex ; $(MAKE) clean)
distclean: clean
rm -f config.log config.cache config.status
rm -f Makefile */Makefile auto.el
-maintainer-clean:
+maintainer-clean: distclean
$(MAKE) distclean
rm -rf autom4te.cache
--- auctex-11.84.orig/preview/latex/Makefile.in
+++ auctex-11.84/preview/latex/Makefile.in
@@ -65,5 +65,5 @@
$(PDFLATEX) '\nonstopmode
Re: New Packager question again: can you point me to a not flawed package?
On Sat, May 31, 2008 at 03:19:02PM -0500, Paul Johnson wrote: I'm randomly downloading packages. If you can point me to one that has source code patches correctly applied, I'd really appreciate it. I want to get it right :-) http://packages.qa.debian.org/usermode The usermode source debian package has one single patch which is applied to the original source with the patch command in debian/rules. Aníbal Monsalve Salazar -- Red Rosa now has vanished too Bertolt Brecht signature.asc Description: Digital signature
Re: New Packager question again: can you point me to a not flawed package?
Paul Johnson [EMAIL PROTECTED] writes: I just need to see some examples of how this can be done. I wonder if I'm running into a problem that is peculiar to Ubuntu. I can't find packages that follow the principles we were discussing yesterday. In fact, I can't find any that adhere to this guideline in a complete way. (It appears to me the temptation is too great to make undocumented changes in source code.) At this point, I've converted most of my packages to use Git, which means that the source package as uploaded to Debian has one collapsed patch including upstream changes and you have to check out the Git repository to see the separate branches and how they relate to upstream. At some point, I'm hoping to be able to generate format 3.0 packages from Git in some way that exposes the way that I'm actually working to other people working on packages. In the meantime, you can still look at the openafs package, which is currently using quilt and applies a whole bunch of patches (although we may switch to Git at some point down the road). -- 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: New Packager question again: can you point me to a not flawed package?
Paul Johnson [EMAIL PROTECTED] writes: On Sat, May 31, 2008 at 9:59 PM, Russ Allbery [EMAIL PROTECTED] wrote: At this point, I've converted most of my packages to use Git, which means that the source package as uploaded to Debian has one collapsed patch including upstream changes and you have to check out the Git repository to see the separate branches and how they relate to upstream. You don't keep a patches subdirectory under debian? The idea of using a distributed VCS to manage the package is to use its merge capability rather than a more manual patch update process. To some extent it's an experiment, since I really do like quilt, but it's working fairly well so far. Git lets me manage branches the way that I managed patches and provides a much richer set of commands to manipulate those branches (although it requires some work to figure out which ones to use and how). At some point, I'm hoping to be able to generate format 3.0 packages from Git in some way that exposes the way that I'm actually working to other people working on packages. I can't understand why you would do it this way. Seems like it would lead to hard-to-catch coding mistakes. Using Git with feature branches for each patch is exactly equivalent to using separate patches in a debian directory. You can transform one into the other (although feature branches allow more complex merges). It's the same work flow, except you work on nodes rather than edges. It's a classic graph transform. If there were 50 patches, some of which others contribute, there might be a chance to figure which one blows something up. As long as the patches are separate, there's a chance I could back-track and find the problem. But it seems like you are saying that you apply those 50 patches, and then make one jumbo diff including all changes. Only in the final build of the source package after everything has already been merged. The working object is 50 separate feature branches, each of which contain only one change, and which I can merge and update indepedently. The only difference is when one does the merge and what artifact of the merge one puts into the source package. Right now, the Git method is less than ideal for anyone working only on the source package, since they get the merge artifact without any of the underlying structure. 3.0 package formats will fix that; in the meantime, if they have Git, debcheckout will get the actual repository and let them work on the same thing that I'm working on. -- 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: New Packager question again: can you point me to a not flawed package?
On Sat, May 31, 2008 at 9:59 PM, Russ Allbery [EMAIL PROTECTED] wrote: Paul Johnson [EMAIL PROTECTED] writes: I just need to see some examples of how this can be done. I wonder if I'm running into a problem that is peculiar to Ubuntu. I can't find packages that follow the principles we were discussing yesterday. In fact, I can't find any that adhere to this guideline in a complete way. (It appears to me the temptation is too great to make undocumented changes in source code.) At this point, I've converted most of my packages to use Git, which means that the source package as uploaded to Debian has one collapsed patch including upstream changes and you have to check out the Git repository to see the separate branches and how they relate to upstream. You don't keep a patches subdirectory under debian? At some point, I'm hoping to be able to generate format 3.0 packages from Git in some way that exposes the way that I'm actually working to other people working on packages. I can't understand why you would do it this way. Seems like it would lead to hard-to-catch coding mistakes. If there were 50 patches, some of which others contribute, there might be a chance to figure which one blows something up. As long as the patches are separate, there's a chance I could back-track and find the problem. But it seems like you are saying that you apply those 50 patches, and then make one jumbo diff including all changes. I thought--yesterday in this list--that people were telling me that is a bad practice.. It destroys accountability. In the meantime, you can still look at the openafs package, which is currently using quilt and applies a whole bunch of patches (although we may switch to Git at some point down the road). Cool, will look now! I like openafs and will probably re-package it with customized server cache settings for our lab. -- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New Packager question again: can you point me to a not flawed package?
On Sunday 01 June 2008, Russ Allbery wrote: Paul Johnson [EMAIL PROTECTED] writes: --cut-- If there were 50 patches, some of which others contribute, there might be a chance to figure which one blows something up. As long as the patches are separate, there's a chance I could back-track and find the problem. But it seems like you are saying that you apply those 50 patches, and then make one jumbo diff including all changes. Only in the final build of the source package after everything has already been merged. The working object is 50 separate feature branches, each of which contain only one change, and which I can merge and update indepedently. The only difference is when one does the merge and what artifact of the merge one puts into the source package. Right now, the Git method is less than ideal for anyone working only on the source package, since they get the merge artifact without any of the underlying structure. 3.0 package formats will fix that; in the meantime, if they have Git, debcheckout will get the actual repository and let them work on the same thing that I'm working on. True. This is cool and helpful for the DD point of view while working with their $VCS, but might leave users of diff.gz with one single jumbo diff which modifies several upstream files. Please note that these users (which might happen to be the upstream developers of your package) might not even have your $VCS of choice installed or devscripts package to use debcheckout, they might be pure $UNIX users relying on patch, diff and a simple text editor. So, will you generate at some point a series logically separeted quilt patches and store them in debian/patches/ in the final diff.gz which is the canonical way of Debian to distibute changes. -- 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: New Packager question again: can you point me to a not flawed package?
Paul Johnson wrote: At some point, I'm hoping to be able to generate format 3.0 packages from Git in some way that exposes the way that I'm actually working to other people working on packages. I can't understand why you would do it this way. Seems like it would lead to hard-to-catch coding mistakes. If there were 50 patches, some of which others contribute, there might be a chance to figure which one blows something up. As long as the patches are separate, there's a chance I could back-track and find the problem. But it seems like you are saying that you apply those 50 patches, and then make one jumbo diff including all changes. I thought--yesterday in this list--that people were telling me that is a bad practice.. It destroys accountability. I'm not a DD, so I might be wrong, but: Different people have different work flow, there's nothing in the Debian policy that I know that tells that a big .diff is wrong. I would agree it's a bad practice (I personally don't like it), but this is only my taste. If working with Git it should be possible to track changes too, so if somebody feels happy like this, it's not a problem in Debian. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New Packager question again: can you point me to a not flawed package?
George Danchev [EMAIL PROTECTED] writes: So, will you generate at some point a series logically separeted quilt patches and store them in debian/patches/ in the final diff.gz which is the canonical way of Debian to distibute changes. I'm currently not doing this for a very prosaic reason: I don't have a simple tool that does it for me, and I'm too busy with other things to write one. The choice was to stay with quilt or to give this up in exchange for experimenting with Git, and I decided to take the latter approach since I really needed to learn Git. I'm hopeful that the 3.0 package format will address this, or that otherwise one of the people who are talking about doing this with their packages will write up a good set of tools to let me do this easily, so that I don't have to do the work of writing such a tool. -- 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: Need some tips on building Debian packages
On Fri, 30 May 2008 15:07:57 -0500, Paul Johnson [EMAIL PROTECTED] said: Keep in mind that my background is in RPM building, where the emphasis is on distributing pristine source code. I was initially shocked/dismayed by the Debian approach because the source code gets untarred and fiddled with by the packager. Yes. There is also a viewpoint that Debian is a full participant in open source development, and some of us DD's participate in the free software movement by actively developing the software, and some of the changes get incubated in Debian for a while before being accepted upstream. Some of the example guides that people referred me to may have been bad examples--packagers were opening the source directory and liberally applying patches and making changes, and all of those fiddles were getting wrapped up into the one big diff file, making it impossible to figure out who did what. This sounds like chaotic development. I try and manage my enhancements to software I develop using separate lines of development, and I use a sloppy branch for testing new ideas, and an integration branch to ship the combination of the lines of development I am working with. I eventually found out that these were bad examples. At the end of the day, the recommendation for Debian packaging is essentially the same as in RedHat: we are aiming to distribute unchanged source that is patched in a clear and orderly way. There's not much information on how to manage patches in the Debian New Maintainer's Guide, but in section 6.4 it does acknowledge the problem and refers to dpatch. Not all of use stacked patch management systems. I keep wondering, If the goal is to re-distribute 'pristine' source code and patches, why doesn't Debian discourage users from untarring the sourced code? Why can't you make it so the debian directory is not inside the source tree? One response I've received is that we are not RedHat, try to get over it. We are also not scared of free software development models, where users are supposed to be given the sources. If they are to be discouraged from fiddling with the source cod4e, why get all hot and bothered about the freedom angle? manoj -- Excellent day for drinking heavily. Spike the office water cooler. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
