Shachar Shemesh
Sun, 16 Sep 2007 08:09:38 -0700
Please use that "reply to all" button at the top of your mail software when replying to me. Thank you. Omer Zak wrote: > > Thanks for the tip. > So, the problem is solved in the special use case of rebuilding the > version which is in Debian main archive, for the purpose of making a > small change in it (such as fixing a security bug). > Yes, but I think you may not understand what that means. Debian's "main" archive is where all software totally free goes. The other standard archives are "non-free" which is free as in beer software that is not free, and "contrib" which is free software that may need non-free components (i.e. - components from Debian non-free) to either build or run. The above procedure will, generally, work for software under contrib as well, and may or may not work for software under non-free, depending on the case. In any case, the Debian flavors (Sid, Etch, Lenny etc.) do not enter into it - each of those have their own three archives. > How are the following use cases handled? > > 1. Several Perl modules are in CPAN but not packaged in .deb files. > They are installed using cpan rather than apt-get. > CPAN Perl modules generally get a package in Debian as well. It follows that I can rebuild them like that as well. > I suppose that a similar situation exists also for Python, PHP and other > scripting languages. > And a similar answer, yes. > 2. Building a bleeding-edge version, for which you want to get the > source code from SVN HEAD (or CVS HEAD). Generally, you get the Debian files (mostly the patch file, which is the changes the Debian maintainer applied to your package) for a version as close as possible, add the upstream source, run "dpkg-source -x", and continue with the last step and hope for the best. If the best does not happen, you have to fix stuff yourself. > Such a version is not in > Debian main, and probably did not make it even to Debian Sid. > It may be in Sid's main archive, though. If it is, you can pull the source from sid, compile on etch (or whatever it is that stable happens to be at the time), and hope for the best. If the best does not happen you may need to backport some of the dependencies as well, or edit the debian/control file (if the dependency problem is only in the definition). > In the general case, to execute the new version, you also need also more > recent versions of the system libraries - yet you do not want to screw > up your development environment for other projects, which rely upon > stable versions of those system libraries. > Yes, if you want to break stability, you run the risk that stability will be broken. Just work with Sid and if that's the case, though. Do note that many unofficial archives (such as backports.org) contain apt sources that will contain not only the newer versions of things, but also their sources. If they do, the original procedure will work as is (or, at least, should. It depends on how careful the maintainer was). > --- Omer > > Shachar ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]