From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on sa.local.altlinux.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DNS_FROM_AHBL_RHSBL,FUZZY_XPILL,RCVD_IN_MSPIKE_BL, RCVD_IN_MSPIKE_L3,RP_MATCHES_RCVD,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ngs.ru; s=mail1; t=1448955454; bh=AQTGYbE4RD0pzOn4/uNzr86kThPswLdh0JqTiPzrnTU=; l=1089; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=KOHQRnPs9BFpMbTDW83ha+3bElNAlXXjXyKScNdn6turWeSY8Uhind1+89U6wHmTp 9NCbpA74mc7AgGuYFg3j96QPZPJCTnrj8dxoihzBCPxay6Ao8IdZtdSbjH4cpnVZwt dTSCh7JGT3y7nly7xsNiU6o+6rbMcCJX9MqsmeTo= To: ALT Linux Team development discussions From: Alexey Morozov X-Enigmail-Draft-Status: N1110 Message-ID: <565D4E3C.6050808@ngs.ru> Date: Tue, 1 Dec 2015 13:37:32 +0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 87563 [Dec 01 2015] X-KLMS-AntiSpam-Version: 5.5.6 X-KLMS-AntiSpam-Envelope-From: morozov_ml@ngs.ru X-KLMS-AntiSpam-Rate: 15 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 3846701, 3846799, 3846193 X-KLMS-AntiSpam-Info: LuaCore: 349 349 43fada1e31f1a0fa2275e2e3b14e0264699ec5ab, Auth:dmarc=none header.from=ngs.ru; spf=softfail smtp.mailfrom=ngs.ru; dkim=none, {spf:softfail; mailfrom:ngs.ru}, 127.0.0.200:7.1.3; 89.189.185.230:7.1.2,7.1.3; d41d8cd98f00b204e9800998ecf8427e.com:7.1.1; 127.0.0.199:7.1.2; ngs.ru:4.0.4,4.0.3,7.1.1 X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: not scanned, disabled by settings X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, not scanned, license restriction X-Virus-Scanned: clamav-milter 0.98.6 at mc-filter2 X-Virus-Status: Clean Subject: [devel] =?utf-8?b?0JfQsNCy0LjRgdC40LzQvtGB0YLQuCDQv9Cw0LrQtdGC?= =?utf-8?b?0L7QsiAtZGVidWdpbmZv?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 07:37:36 -0000 Archived-At: List-Archive: List-Post: Здравствуйте! Граждане, а подскажите, пожалуйста, зачем наши -debuginfo пакеты автоматически получают зависимости на -debuginfo тех библиотек, от которых зависит библиотека, чей код я хотел бы видеть в процессе отладки? Очевидно, что эти зависимости не являются необходимыми, т.к. и без них всё прекрасно грузится (прямо сейчас сижу в отладчике, установив с --nodeps liblog4cplus-debuginfo), это некоторая искусственная зависимость, добавленная по каким-то не вполне понятным мне соображениям. Типичным для меня сценарием, при котором требуется заглядывать в код библиотеки, является ситуация, когда при предположительно правильных параметрах поведение _данной конкретной библиотеки_ или, ещё точнее, данного конкретного вызова данной конкретной библиотеки отличается от ожидаемого. Мне совсем не нужно отлаживать glibc или весь стек libX*, у меня конкретная маленькая задача, которую я хотел бы решить наиболее простым способом, без гигабайтов ненужных пакетов и файлов. А какие сценарии использования предполагались в нашей схеме? С уважением, Алексей Морозов.