On Sun, 2007-09-16 at 17:03 +0200, Shachar Shemesh wrote:
> 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.
I understood what it means, but it is orthogonal to the problem which I
am discussing. The discussion is under the assumption that the big
project in question is sufficiently Libre (Free as in Free Speech) that
anyone can recompile it and modify it. It does not matter to which
archive it is officially assigned (a package with Libre C++ files could
be relegated to contrib or non-free due to license problems with
documentation, image files, or BLOBs, which do not need to be recompiled
anyway).
> 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.
All of them?
> > I suppose that a similar situation exists also for Python, PHP and other
> > scripting languages.
> >
> And a similar answer, yes.
My actual experience was that the Eclipse PHP plugin is not in Debian
Etch. If I'll need this plugin before Lenny becomes stable, I'll have
to install the plugin outside of Debian packaging system.
> > 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.
"you have to fix stuff yourself" - is not a scalable solution, in the
general case. In a large project, there'll probably be several fixes to
be manually made.
> > 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).
Again, not scalable for very large and complicated projects.
> > 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.
Nowadays, it is not necessary to break stability. We have fat hard
disks, and we have virtualization. This combination means that only
dunces (and people duncified by tightfisted PHBs) break stability.
In another message, Dan Armak suggested to use Gentoo, and cited also
support for different versions of toolchain components needed by
different projects. This is probably the right approach if one does not
need to use a different kernel to run the project in question. If a
different kernel is needed, however, then a VM is again advisable.
Besides, people who usually work with Debian, would probably prefer to
run Gentoo inside a VM, if at all.
--- Omer
--
Every good master plan involves building a time machine. Moshe Zadka
My own blog is at http://www.zak.co.il/tddpirate/
My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which
I may be affiliated in any way.
WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html
=================================================================
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]
