On 29/11/2018 16:57, Douglas R. Reno via blfs-dev wrote:
On 11/26/18 12:28 PM, Alain Toussaint via blfs-dev wrote:
Le lundi 26 novembre 2018 à 12:24 -0600, Bruce Dubbs via blfs-dev a
écrit :
Reference:
http://wiki.linuxfromscratch.org/blfs/ticket/11246 (git and shipped
perl
modules)
http://wiki.linuxfromscratch.org/blfs/ticket/11295 (Error-0.17027
(Perl
module))
I've been looking at these tickets, but want to raise them here for
more
visibility. In #11246, Ken prefers to remove Error from the perl
modules because it is only used by git and git provides a copy in
/usr/share/perl5/Git.
I agree. Actually, I think we can just archive
general/prog/perl-modules/perl-error.xml, mark #11295 as
overcomebyevents, and mark #11246 fixed.
I do not see a need to put a comment in the git section. That sets
a
precedent to document every package that has some sort of shell
script
or an executable in /usr/libexec or in a dedicated location.
Opinions?
-- Bruce
Entirely agreed to archiving perl-error.xml
Alain
I still do think that it has to be documented. A Perl Module is a
different story from a library executable, especially modules like
Error. In my opinion, We should add MailUtils as well, so that git can
send automated commit messages if running as a server.
I'd add MailUtils but archive Error, but seeing what the replies might
be in this thread, my opinion could change. I'm finally catching up on
email.
Error is used by more of git than MailUtils (they use it for error
handling in almost all their perl scripts). ISTR that generating patches
(git format-patch) uses it, for example. But, as I said, both modules
are provided in the git sources, so technically, they are not needed as
separate modules. My main concern is the same we have for libraries:
Some errors can be fixed upstream and not be included in the bundled
modules (as for libraries). Also, I think it's a good idea to separate
projects coming from different groups of developers. Actually, I think
there would be no question about including those modules in the book, if
there were more editors. It's only the lack of manpower, which makes us
have this discussion.
Off topic, but related: I think when big projects take over upstream
libraries to modify them, or to use library internals (such as
libreoffice with a lot of libraries, or chromium with qtwebengine), it's
a way for them to restrict our control on what is installed on our
computers. The normal way should be either to send mods upstream if the
project really needs them, or to fork the library if upstream is
reluctant to include the mods, but still keeping the library out of the
project. Actually, another drawback of modifying and bundling a big
library such as qtwebengine is that you may end up building the library
twice, once for other packages using it, and once for the big project,
which is just a waste of time...
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
