Hi,
Is the following command correct in the db page, or I am missing
something obvious?
chown -Rv root:root /usr/share/doc/db-4.7.25
~
Regards,
Ag.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above
On Sun, Dec 14, at 10:10 Agathoklis D. Hatzimanikas wrote:
Hi,
Is the following command correct in the db page, or I am missing
something obvious?
chown -Rv root:root /usr/share/doc/db-4.7.25
~
Please disregard. I am trying a new method and I've missed a step.
Hello.
While browsing the wget list generated for the LFS devel book, I noticed
that
http://www.linuxfromscratch.org/patches/lfs/development/db-2.8.1-fixes-1.patch
is not present...
greets,
jens
--
[EMAIL PROTECTED]
On Thu, Apr 03, 2008 at 03:50:00PM +0200, Jens Stroebel wrote:
Hello.
While browsing the wget list generated for the LFS devel book, I noticed
that
http://www.linuxfromscratch.org/patches/lfs/development/db-2.8.1-fixes-1.patch
is not present...
This is already fixed, but
#2051: Berkeley-DB 4.6.19
--+-
Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED]
Type: enhancement | Status: closed
Priority: normal
Original Message
Subject: Re: [BLFS Trac] #2233: Berkeley DB-4.5.20
Date: Tue, 13 Feb 2007 00:00:20 -
From: BLFS Trac [EMAIL PROTECTED]
Reply-To: blfs-book@linuxfromscratch.org
To: blfs-book@linuxfromscratch.org
References: [EMAIL PROTECTED]
#2233: Berkeley DB-4.5.20
Randy McMurchy wrote:
Again, not that it really matters, as the change is probably a good
thing (I cannot say for sure if it is or is not, as there is nothing
there that directly benefits me), but it was sort of an unusual way
to incorporate a major change into the book.
Well, I'll hold my
Hi all,
The new database package in the LFS SVN book is referenced as the
DB package. This is incorrect and should be fixed. The package is
known as, and is referenced by its maintainers as Berkeley DB.
And, because this package will also have to stay in the BLFS book,
and is referenced
it. Not
that it is bad, mind you, but for those that sort of just skim over
i18n and UTF8 threads, it may have come as a surprise.
Anyway, man-db and Berkeley DB are required for UTF-8 compatibility.
Apparently, the regular 'man' package doesn't work. There was a
fairly comprehensive thread not too long ago about
Richard A Downing wrote:
Can someone point me to the discussion thread that decided this
change of man package? I want to review the reasons to make my own
decision on it.
There was no discussion thread. All reasons are explained in my
man-i18n.txt hint. I _really_ don't want to say Drop all
Randy McMurchy wrote these words on 01/07/06 08:17 CST:
The new database package in the LFS SVN book is referenced as the
DB package. This is incorrect and should be fixed.
Thanks, Ken, for updating the BDB package. However, there are still
some references of DB: the title in section 6.27.1,
Richard A Downing wrote:
Can someone point me to the discussion thread that decided this
change of man package? I want to review the reasons to make my own
decision on it.
http://linuxfromscratch.org/pipermail/lfs-dev/2005-December/054909.html
That's not the thread that decided it, but
On Sat, 07 Jan 2006 20:09:47 +0500
Alexander E. Patrakov [EMAIL PROTECTED] wrote:
Richard A Downing wrote:
Can someone point me to the discussion thread that decided this
change of man package? I want to review the reasons to make my own
decision on it.
There was no discussion thread.
Ken Moffat wrote these words on 01/07/06 12:56 CST:
Disagree. 77.9 MiB on my first build, so yes, more than it says, but I
can't get near 94 (my understanding is that we use MB as an abbreviation
for MiB, I have 79804 KiB as the raw figure).
Hey I was just trying to be helpful. And
On Sat, 7 Jan 2006, Randy McMurchy wrote:
Ken Moffat wrote these words on 01/07/06 12:56 CST:
Disagree. 77.9 MiB on my first build, so yes, more than it says, but I
can't get near 94 (my understanding is that we use MB as an abbreviation
for MiB, I have 79804 KiB as the raw figure).
Hey
Archaic wrote:
In order to make LFS usable in UTF-8 locales, and different man
program was chosen, man-DB. That program requires a database backend.
It can support GDBM or Berkeley DB.
Let me play dumb here for a minute: Why? ;-)
Would it be possible to do something similar to what we did
On 12/27/2005 01:50, Alexander E. Patrakov wrote:
snip explanation
That was very thorough, thank you.
While it would be nice to avoid another dependency the reality is that I
usually end up with both GDBM and BDB on my systems. Yea, I know that's
not really an argument... To me the most
Jason Gurtz wrote these words on 12/27/05 13:52 CST:
It is worrisome about the seemingly ever-changing API, but not always
upgrading to the latest BDB could help alleviate that. They don't seem to
have a bad history of many security updates that would necessitate
upgrading often. :)
In order to make LFS usable in UTF-8 locales, and different man program
was chosen, man-DB. That program requires a database backend. It can
support GDBM or Berkeley DB. I'll list what I think are the pros of
each.
GDBM:
1) Small
2) Easier to install
3) No external dependencies
BDB:
1) More
Archaic wrote these words on 12/26/05 21:48 CST:
Please comment on this thread with your choice and the reasoning for
your choice.
To me, it is a no-brainer. Berkeley-DB should be installed. We
already perform an abortion in one LFS package so that BDB doesn't
have to be installed
On Mon, Dec 26, 2005 at 10:06:59PM -0600, Randy McMurchy wrote:
It can be argued that neither of the above is a valid reason to
choose GDBM. What exactly is easier?
cd build_unix
../dist/configure --prefix=/usr \
--enable-compat185 \
--enable-cxx
make LIBSO_LIBS=-lpthread
Randy McMurchy wrote these words on 12/26/05 22:06 CST:
Archaic wrote these words on 12/26/05 21:48 CST:
Please comment on this thread with your choice and the reasoning for
your choice.
To me, it is a no-brainer. Berkeley-DB should be installed.
I must admit that I didn't lay out all
be a reason to absolutely discard GDBM as a choice
for support of man-db.
I do not agree with the It's not maintained so get rid of it
philosophy and obviously neither do you, but yes, it is a concern of
many, so another point for BDB. :)
2. Berkeley-DB is a moving target. Even now, with the most
Archaic wrote these words on 12/26/05 22:20 CST:
On Mon, Dec 26, 2005 at 10:06:59PM -0600, Randy McMurchy wrote:
It can be argued that neither of the above is a valid reason to
choose GDBM. What exactly is easier?
cd build_unix
../dist/configure --prefix=/usr \
--enable-compat185 \
Archaic wrote these words on 12/26/05 22:31 CST:
The LFS Book is *NOT* producing a UTF-8 only or UTF-8 default system
(ala Fedora Core). The ability to use UTF-8 is being implemented, but
the choice is still on the end user.
I saw *many* changes and patches that affect core LFS packages in
On Mon, Dec 26, 2005 at 11:05:03PM -0600, Randy McMurchy wrote:
I saw *many* changes and patches that affect core LFS packages in
the UTF patch applied (for only a short while) today. Many of which
looked to me as though it changed core functionality.
The patches add UTF support. There are
Randy McMurchy wrote:
Archaic wrote these words on 12/26/05 22:31 CST:
The LFS Book is *NOT* producing a UTF-8 only or UTF-8 default system
(ala Fedora Core). The ability to use UTF-8 is being implemented, but
the choice is still on the end user.
I saw *many* changes and patches
On 12/26/05, Archaic [EMAIL PROTECTED] wrote:
Please comment on this thread with your choice and the reasoning for
your choice.
I prefer gdbm coz the bdb api keeps changing with every new release.
An added benefit of gdbm is the small number of required dependencies.
--
Tushar Teredesai
On Tue, Dec 27, 2005 at 12:44:02AM -0500, Tushar Teredesai wrote:
I prefer gdbm coz the bdb api keeps changing with every new release.
An added benefit of gdbm is the small number of required dependencies.
I guess we really should find out if the man-db devs have a preference.
Not all apps
Archaic wrote:
BDB:
1) More widely used as a DB backend
BDB surely has many techincal advantages. But there is one problem for
the hybrid of the UTF-8 and alphabetical books: Perl looks for GDBM and
BDB as for optional dependencies. If we build the database library after
Perl, differences
On Tue, Dec 27, 2005 at 10:54:40AM +0500, Alexander E. Patrakov wrote:
BDB surely has many techincal advantages. But there is one problem for
the hybrid of the UTF-8 and alphabetical books: Perl looks for GDBM and
BDB as for optional dependencies. If we build the database library after
Archaic wrote:
On Tue, Dec 27, 2005 at 12:44:02AM -0500, Tushar Teredesai wrote:
I prefer gdbm coz the bdb api keeps changing with every new release.
An added benefit of gdbm is the small number of required dependencies.
I guess we really should find out if the man-db devs have a
On Tue, Dec 27, 2005 at 10:56:16AM +0500, Alexander E. Patrakov wrote:
Debian builds man-db with GDBM. The packager and the author of man-db is
the same person, so you can count this as a dev's preference.
There could be many reasons for his choice, one likely one could be it
was easier to
.
Agree.
2. Berkeley-DB is a moving target. Even now, with the most current
version I am hesitant to put in the BLFS book because of API changes.
I've only found Python to need a patch so far, but I've not tested
everything. I'm speaking of BDB-4.4 16.
An API change in BDB? No, can't
I wrote:
Yet another alternative would be to leave the usual Man package in the
book, configure it with +lang none (see explanation in the man-i18n
hint) and import the whole Hacks section from the man-i18n hint. But
I think that the instructions would contain too many ifs then (i.e.:
they
Alexander E. Patrakov wrote these words on 12/27/05 00:15 CST:
Forgot to say: if this variant is chosen, the LiveCD will continue using
Man-DB, because users can't be expected to do any configuration on the
LiveCD.
At this point, I think a new thread should be started, one where
the crux of
Randy McMurchy wrote:
Alexander E. Patrakov wrote these words on 12/27/05 00:15 CST:
Forgot to say: if this variant is chosen, the LiveCD will continue using
Man-DB, because users can't be expected to do any configuration on the
LiveCD.
At this point, I think a new thread should be
37 matches
Mail list logo
