From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=qQlkwQpS6S9DBc910CeEIjncrE225rCmiycFm7ius1Q=; b=AggBuBOWuq3IiYdHQP2dCwTQOcnS2j+jYb3JUPBSi7JoEbjkF3229TT9ni5aLaYILL SbE5W0LkQBRp3uBAlYIrfi1hASGEf7/xz3bFFsmJGqmtyGE5WUw6sMudJT0NER+vkhWy gtGVPGu2A2i9yn3/quz/xW2kVXXnwfUqX6gVoS67LhsiG6DtyHwVjnqliwqsdVgUKsRy 7+jxtlC183HeGHiwWU3hBkTUCWiCy2x410Ob5WQyjmYD4iwmawWPvsLp3uRxtWOui9Ze h335xz3FN8ymlWiGBZF8NQGM9G1zKDl8Vguke2TFBzzxefEGoNseQm+/Jd/J/cUITcec 3vjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=qQlkwQpS6S9DBc910CeEIjncrE225rCmiycFm7ius1Q=; b=NCgXZvdeFTFJHmrCMpXm1ZLJi2hByuKjw9I+6Q+9JrWWkfFcxdsCyiAH7zEt/FQObO kaZY89fsM0XAqeJ5fsa4q+HNgC9ehSXTN23Drsq93ZyhPrqDu66ysMveI//gNz/ZlTyh digWSfZygVYhF/GYcThfS/WneJyV/8SZfYCbOy8/jxwcKpcu29g8+5lLsZtzuE8C/3N6 eaZO2Q2ymiwrPPhISO8llmLA4CGDvRECyuSbFFhi4CggUHLNf7aDjvPI3+U3h1fOZmtz 1Qw98HJZluhhDgOsutkqsbFgXKQsj4GsQo5Z/22NOtrXcAFKjClZBkl7rLvuHw3+wY4j eR2A== X-Gm-Message-State: AOAM531vx/TKqbEIXo0FMokr9zC2adeWD/IySa+vBSfIYDYnEoj+2Tkz VCiksx4/dzqDo+CkQPSkVlARvCvjCmU= X-Google-Smtp-Source: ABdhPJyd5FkaM00zdX9F+asbzcaGZ2X4NhR3nO7e/TQfzHSYf8h14JtJqboIU5jY9VwfERdBoNq2HQ== X-Received: by 2002:a05:6512:3608:: with SMTP id f8mr11104367lfs.57.1629114172186; Mon, 16 Aug 2021 04:42:52 -0700 (PDT) To: devel@lists.altlinux.org References: <3f9aefd6-27a5-612d-361e-f578ab2ec14f@gmail.com> From: Leonid Krivoshein Message-ID: <4f29caa3-d9c5-7b57-eb57-a63d9c59ca5b@gmail.com> Date: Mon, 16 Aug 2021 14:42:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru Subject: Re: [devel] =?utf-8?b?0J3QsNC30L3QsNGH0LXQvdC40Y8g0L/QvtC70Y8gUGFj?= =?utf-8?b?a2FnZXIg0LIg0YHQv9C10LrQtTog0LrQsNC6INCyINCQ0LvRjNGC0LUg0Lgg?= =?utf-8?b?0LrQsNC6INCyINCk0LXQtNC+0YDQtQ==?= 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: Mon, 16 Aug 2021 11:42:55 -0000 Archived-At: List-Archive: List-Post: К слову, эксперимент с локальной сборкой показал, что: - в спек, попадающий в .src.rpm, поле Packager, если есть, значение заменяется на текущего сборщика пакета; - в поле Packager в .rpm и .src.rpm прописывается значение поля Packager из исходного гита, а не текущего сборщика пакета; - только если не указывать поле Packager в исходном гите, только тогда пакеты собираются с текущим сборщикам. - мне удалось собрать пакет с Packager: John Doe ; Первая особенность интересна, поскольку незаметно для сборщика и автора ("тихо") заменяется "исходник". Исходя из сказанного: - наши полиси на ВиКи противоречат тому, что в Федоре; - мне эти полиси кажутся логичными, но не везде достаточными; Взять, к примеру, бэкпортирование. Если я уберу или Packager или поменяю его, автор обидится и правильно сделает. В спеке это поле выглядит как авторство первоначального документа. Можно сравнить это полями СУБД для табличных записей CREATOR и EDITOR. Получается, что сейчас rpm -bb в каких-то случаях ведёт себя как CREATOR, в каких-то, как EDITOR. CREATOR меняться не должен. 16.08.2021 10:39, Anton Farygin пишет: > Да, где встречаю и где осмысленно удаляю поле Packager из спека. > > В целом придерживаюсь рекомендации, что поле Packager скорее вредное, > чем полезное. > А настоящего ментейнера, отвечающего за пакет можно определять по > changelog. > > > На wiki надо бы тоже поправить. > > > On 16.08.2021 04:37, Leonid Krivoshein wrote: >> >> Цель обсуждения: внести ясность и, при необходимости, корректировки >> на ALT ВиКи. >> >> В Fedora Packagin GuideLines [1] сказано: >> The Copyright:, Packager:, Vendor: and PreReq: tags MUST NOT be used. >> >> Такую же рекомендацию уже второй раз встречаю за последнее время: не >> надо использовать поле Packager *в спеке*, т.к. наша сборочница его и >> так автоматически проставляет. Однако git grep по spec.git by vt@ >> покажет огромное число пакетов, где поле Packager прописано. Мне >> кажется, что назначение поля Packager *в спеке* -- обозначить, кто >> *первый* опакетил данное ПО в Сизиф или какая группа разработки за >> него сейчас отвечает. Конечно, можно это выяснить и более длинным >> путём, но так проще и интуитивно соответствует программистской >> логике. Исходя из этого в наших полиси должны быть прописаны все >> случаи, когда изменение этого поля уместно, и когда его можно >> действительно не указывать. Сейчас это именно так, судя по ВиКи. Если >> поле и правда лишнее, в чём лично я сильно сомневаюсь, стоит хотя бы >> предупреждение выдавать. >> >> >> Ссылки: >> 1. >> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_tags_and_sections >> 2. https://www.altlinux.org/ALT_Packaging_HOWTO#Порядок_тэгов >> 3. https://www.altlinux.org/ACL#ACL >> 4. https://www.altlinux.org/NMU >> 5. https://www.altlinux.org/Сборка_модулей_ядра >> 6. https://www.altlinux.org/Backports_Policy#Исправления_spec-файла >> 7. https://www.altlinux.org/Packager_Teams >> 8. https://www.altlinux.org/SampleSpecs/cmakeprogram -- и таких >> примеров там десятки. >> 9. И ещё очень много других статей на той же ВиКи... >> >> > > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel -- Best regards, Leonid Krivoshein.