[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: manual update of apt database (was Best way to update perl on Woody Stable?)

On Fri, Oct 10, 2003 at 12:08:08AM -0500, Rod Rodolico wrote:
> Correct, dpkg and apt are useful tools. All tools have strengths and
> weaknesses. I love perl, and can not imagine living without it. But, I doubt
> I'll use it to create a database engine.
> So, I use the tool best for a given task. In 90% of my tasks, dselect works
> just fine. For the other 10%, I download source and install. 

so, why not either:

a) download the debianised source (if available) and build a package OR b)
spend an extra 10-20 minutes creating the debian/rules files etc and building a
local package rather than just "make && make install".  that gives you the same
custom-compiled software, but managed by dpkg.

> I started "rolling my own" around 10 years ago using Slackware. I just don't
> have the time any more. 

yes, so did i.  i don't have the time either.  that's why i learnt how to use
the debian packaging tools - they save me a lot of time and wasted/duplicated
effort, they mostly eliminate the hassle of dealing with cruft (i.e. local
stuff that isn't managed by the packaging system), and generally make my job a
lot easier.

i don't bother packaging every individual script i write (/usr/local/[s]bin/ is
good enough for them), but i do package anything more complicated than a set of
1-3 little scripts.  by taking the time to package anything i download and
compile, i get to manage and upgrade it with dpkg, and i have a binary package
which i can install on as many of my servers as i need....i.e. compile once,
install many :)

of course, i use my fastest/least-loaded current machine to build packages.
then distribute them with scp.  if the package is of general use (and if i've
done a good enough job making the config/install generic enough rather than
specific to my needs) then i upload it to debian and it becomes part of the

> However, to get the exact system I want, "rolling your own" is the only
> solution. I have just decided that "almost right" is close enough for me if I
> can do a full server install as rapidly as I can using Debian and its
> packages tools. 

it's not an either/or question.  building packages doesn't prevent you from
making whatever custom changes you need to a program when you compile it.

> But, there are always things I can not do because using any
> tool limits you to the tasks that tool is designed to accomplish.

i think that the limitations you imagine are more in your understanding of the
tool, than in the tool itself.

you can do anything in a package that you can do in a Makefile, or a shell
script or a perl script (or any other script/program for that matter).

> > your best bet is to either:
> >
> > 1. upgrade completely to 'testing' or 'unstable'. this is nowhere
> Do not do this on a production box without testing first. 

of course.  anyone using 'unstable' on a production server *SHOULD* test all
upgrades on unimportant machine(s) first.

the same kind of testing should be done when compiling and installing software
locally, too.

overall, there is less work and less time in running unstable.

> > 2. upgrade partially to unstable. simplest way is to temporarily
> This could work. It is also a PITA because if you screw up, there is no way I
> am aware of to back out of a version and go to a previous one (I'd love to
> proven wrong here). 

keep a copy of the old package....either from your installation CD, or by using
dpkg-repack just before you upgrade the package.

revert by installing the old package with 'dpkg -i'.

> > 3. (if you have a lot of time on your hands)
> >
> >    download the debianised source for perl 5.8 from "unstable" and
> >    recompile it on your woody system. do the same for any module packages
> >    that you need. i.e. backport the new perl to the old debian.
> >
> >    a lot of people recommend this method. personally, i find it to be far
> >    too time consuming, for very little benefit. far easier (and much better
> >    tested) to just run unstable.
> Back to my original question. At this point, how do you tell apt that the
> package is installed. 


with this method, you build a package and install it with dpkg.  that's why i
said "download the debianised source...".

it's not just "make all && make install", you build a package (in most cases,
that's as simple as running "dpkg-buildpackage" rather than "make") and then
you install the package when it is built, same as any other package.

so, you end up with a version of the package (same as in 'sid'), compiled with
the woody compiler and linked against the woody libraries.

for simple cases, i.e. single packages, or when you just want to build a
package with different compile-time options, this is the right thing to do.

for complex cases, e.g. when there are dozens or hundreds of co-dependant
packages, it is simpler and safer to just upgrade to unstable.  IMO, perl is
one of these complex cases - not so much because of perl itself but because of
all the module packages.


Reply to: