| To: | Nathan Scott <nathans@xxxxxxxxxx> |
|---|---|
| Subject: | Re: Multi-lib support problem & possible fix |
| From: | fche@xxxxxxxxxx (Frank Ch. Eigler) |
| Date: | Wed, 29 Jan 2014 11:13:48 -0500 |
| Cc: | pcp developers <pcp@xxxxxxxxxxx> |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <2079478185.15183762.1390974204857.JavaMail.root@xxxxxxxxxx> (Nathan Scott's message of "Wed, 29 Jan 2014 00:43:24 -0500 (EST)") |
| References: | <1288830274.15173866.1390972567394.JavaMail.root@xxxxxxxxxx> <2079478185.15183762.1390974204857.JavaMail.root@xxxxxxxxxx> |
| User-agent: | Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) |
Nathan Scott <nathans@xxxxxxxxxx> writes: > [...] > There is a section of /etc/pcp.conf which doesn't meet this > need and that is these two lines ... > > PCP_LIB_DIR=/usr/lib64 > PCP_LIB32_DIR=/usr/lib > > I initially looked at simply removing these, since they are not used > in the source code directly. However, I later on found they are > used in builddefs/buildmacros, which might be used when a third > party is building software using pcp-libs [...] How about a change consisting of moving those two definitions from pcp.conf into builddefs, and likely builddefs/buildmacros into pcp-libs-devel? If the pcp sources we ship continue working, and our pmdas continue installing, that's good enough. We shouldn't hold back cleanups on the basis of hypothetical third party packages that could very well work with the changes. This is not like a major API/ABI break. - FChE |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | pcp_3.8.12_i386.changes ACCEPTED into unstable, Debian FTP Masters |
|---|---|
| Next by Date: | Re: Multi-lib support problem & possible fix, Nathan Scott |
| Previous by Thread: | Multi-lib support problem & possible fix, Nathan Scott |
| Next by Thread: | Re: Multi-lib support problem & possible fix, Nathan Scott |
| Indexes: | [Date] [Thread] [Top] [All Lists] |