From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <49EB92CE.9030806@altlinux.com> Date: Mon, 20 Apr 2009 01:08:30 +0400 From: Anton Farygin User-Agent: Thunderbird 2.0.0.18 (X11/20090322) MIME-Version: 1.0 To: ALT Linux Team development discussions References: <9d5146970904180201t202b2aedp91c317053bc2e733@mail.gmail.com> <9d5146970904180645x7634c975u68e74fc7a62cafd3@mail.gmail.com> <87d4ba6p6d.fsf@vertex.dottedmag.net> <9d5146970904180704x63bc91dv75a6b27c1c8ace84@mail.gmail.com> <878wly6oc7.fsf@vertex.dottedmag.net> <9d5146970904180724v1c9614f7wd469a3e5826e5651@mail.gmail.com> <20090418143414.GD11969@altlinux.org> <49EB20DE.9090900@altlinux.ru> <87tz4k3i0j.fsf@vertex.dottedmag.net> <49EB2611.2070301@altlinux.ru> <777d80610904190632p4de7fd43tc573d0caf34edcd5@mail.gmail.com> <49EB2AF9.6020503@altlinux.ru> <49EB8CE5.7040503@altlinux.com> <874owk2ww6.fsf@vertex.dottedmag.net> In-Reply-To: <874owk2ww6.fsf@vertex.dottedmag.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] NMU Policy 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: Sun, 19 Apr 2009 21:09:59 -0000 Archived-At: List-Archive: List-Post: Mikhail Gusarov пишет: > Twas brillig at 00:43:17 20.04.2009 UTC+04 when rider@altlinux.com did gyre and gimble: > > >> Если вы говорите про сроки значит извещение об NMU должно быть "не > >> позднее, чем данный пакет будет ГОТОВ БЫТЬ отправлен на сборку И НЕ > >> РАНЬШЕ N часа(ов)". > > AF> Как будем вычислять N часов ? И как будем контролировать N часов ? > > Таймштамп на баге. На какой баге ? т.е. - предлагается, в случае прохождения в сизиф ломающего всё пакета: 1) повесить багу 2) подождать 5-10-15-20-35 часов, пока мантейнер проснётся, позавтракает, доедет до работы, походит по сайтам, прочитает почту, почешет репу (в течении нескольких часов), доберётся до дома (на работе у него видите-ли ключей нет), зальёт пакет, тот не соберётся, зальет его ещё пару раз... и так до тех пор, пока он не соберётся... А тем временем, весь devel@ будет с нетерпением ожидать, пока он это всё проделает ? А если он в баге напишет, что не согласен ? Давайте посмотрим на другое: - убираем пункт 2 в NMUPolicy - отнимаем права NMU у админа - даём права выдавать NMU для некоего другого админа (которого тоже надо ещё найти и связаться с ним) Тогда я на следующий день, заливаю пакет allsisyphus, который будет Provides, например, всё что возвращает $ rpm -q --provides glibc-core В пакете будет библиотека - обвязка над libc.so.6 (по типу libfakeroot), которая будет устанавливаться в /lib/libtest/ в post-скрипте копировать libc.so.* в /lib/tmp, а на себя делать из /lib/ ссылки. Так-же по именам и весям предоставлять весь функционал glibc-core, но через промежуточные функции. В этих функциях, сделаем, например, запись всех введённых с клавиатуры символов в какой-нить файл с дальнейшей отправкой на адрес в интернете... это просто фантазия, но такое сделать вполне реально. ну, и я безусловно долго буду пытаться динамить с "незаконным" NMU, говорить про то, что админ сизифа не нужен и всё остальное... Да - не имея пункта 2 policy я смогу довольно долго держать всех пользователей сизифа раком, более того - делать это эффективно и безнаказанно. Поймите, пункт 2 нужен для нашей же безопасности, что бы не пришёл какой-то Rider и не собрал непойми чего, из-за чего всем будет хреново, одному ему будет хорошо. И я не понимаю ваше желание этот пункт как-то убрать.. зачем ? Вы боитесь, что админ сизифа из вашего пакета сделает непойми-что ? Та вы всегда сможете откатить его изменения. Какие ещё страхи вас сопровождают ? Давайте их обсудим ...