manual update of apt database (was Best way to update perl on Woody Stable?)
Changed the subject of this because it looks like a religious discussion coming up.
> this:
>
> On Thu, Oct 09, 2003 at 08:40:23PM -0500, Rod Rodolico wrote:
>> Is there a way to tell apt (dselect) you have certain packages
>> installed? If so, it would make sense to just trash the Debian perl
>> install and install it all from source. I agree with your Perl guru --
>> roll your own is the best way to go.
>
> and this:
>
>> > On Thu, 2003-10-09 at 16:14, Rod Rodolico wrote:
>> >> You could install the CPAN module on your current system, then use
>> >> it to update Perl.
>
> are seriously bad advice. i find it difficult to believe that it is
> being given on a debian mailing list. package managers (like dpkg and
> apt) are not annoyances to be worked around, they are useful tools that
> make systems administration much easier. they exist for a reason, and
> that reason is that managing software installation and upgrades without
> decent tools is a serious PITA. why bother to even use a package-based
> distribution like debian if you're going to throw out one of the main
> reasons for doing so?
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, is there a way to manually update the apt
database to tell it a package is installed. The reason I use Debian is because, for most of my
needs, it is a perfect fit. So, it saves me time. But, for the other 10%, I must actually get
my hands dirty and do what needs to be done. In this case, the Perl he needs is not available
in backports.org (or any other place I checked). So some other solution is required.
>
>
> "rolling your own" (as opposed to recompiling a package locally) is not
> a particularly good solution even in the best of circumstances, and is a
> spectactularly bad solution for perl, especially if you have any need to
> use the many debian perl module packages. debian's directory layout is
> different to the default perl directory layout.
>
Sorry, I disagree. I started "rolling my own" around 10 years ago using Slackware. I just
don't have the time any more. 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. But, there are
always things I can not do because using any tool limits you to the tasks that tool is
designed to accomplish.
>
> your best bet is to either:
>
> 1. upgrade completely to 'testing' or 'unstable'. this is nowhere
> near as scary or dangerous as the names imply. the packages in these
> pre-release distributions are generally as bug-ridden and as bug-free
> as packages in the release distribution.
>
Do not do this on a production box without testing first. Bad advice. I have used testing for
production boxes for the past two years, and they have worked flawlessly. Two months ago, I
upgraded my test box, and found that the testing release update broke two of the web sites I
was hosting. Testing is good, it is nice, and it makes RH and especially Windoze look like
alpha releases. But, be prepared for it to break something, generally when it is most
inconvenient. Also, security updates are slow. I still use testing on some servers, but it is
not a quick fix to an "I need this package now" problem. It could solve this problem simply to
create two or three others.
> or
>
> 2. upgrade partially to unstable. simplest way is to temporarily
> configure /etc/apt/sources.list to use "unstable" rather than
> "stable" and then apt-get install perl related packages. this will
> bring in a lot of other upgraded packages too (e.g. libc6).
>
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). So, in one
case I know of, if you install perl, and dselect wants to update perl-magic also, and you
allow it to, any code (in current testing) that relies on perl-magic will be broken, possibly
for a while since that package has been broken in testing for a month or so now (that I know
of).
> another method is to use apt's "pinning" features where you can tell
> it to upgrade certain packages from one distribution (e.g. unstable)
> and the rest from another (e.g. stable).
>
> NOTE: this partial upgrade is likely to be buggier and less reliable
> than a complete upgrade to 'unstable' because the other packages you
> have installed were not compiled against the new libs or with the
> latest compiler and may have incompatibilities that no-one else has
> spotted.
>
Have never used this function, so have no opinion
> or
>
> 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. I assume I can find out by RTFM'ing, but since you suggested it, maybe you know.
The only advantage I see of doing it this way instead of from CPAN is that it will use the
Debian perl directory trees. The disadvantage is that it doesn't allow you to keep to the
latest and greatest of perl installs.
Note: I do not suggest you blindly install perl from CPAN. See my original response.
Installing perl from CPAN onto a Debian box will break the box, and require a few hours of
tinkering to repair. Actually, I like #3 above as the best solution, but it would likely take
the most time of all (even the CPAN install).
Rod
> or
>
> 4. hunt for one of the backport repositories where people have done 3.
> above and made their work available to others. the quality of work
> here may or may not be as high as you would expect from debian
> packages. YMMV.
I checked. Did not find any. They may exist, but if so, are hidden.
--
Missiles of ligneous or osteal consistency have the potential of fracturing osseous structure,
but appellations will eternally remain innocuous.
Reply to: