Bug 34252 - [FR] Реализовать RPMTAG_AUTOINSTALLED
: [FR] Реализовать RPMTAG_AUTOINSTALLED
Status: NEW
: Sisyphus
(All bugs in Sisyphus/librpm7)
: unstable
: all Linux
: P3 enhancement
Assigned To:
:
:
:
:
: 34036
  Show dependency tree
 
Reported: 2017-11-28 21:11 by
Modified: 2018-03-27 10:26 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2017-11-28 21:11:58
Необходимо для отслеживания пакетов, установленных по зависимостям apt'ом. По
умолчанию, значение для устанавливаемых пакетов. Принимает целочисленные
значения; по умолчанию значение "0" — пакет установлен вручную; когда apt будет
устанавливать зависимости, необходимо менять для них значение в "1".
------- Comment #1 From 2017-11-29 18:37:18 -------
Переформулировка задачи:

реализовать новый тег altflags типа 32bit integer, один из битов которого
использовать для обозначения пакетов, установленных по зависимостям:

enum ALT_FLAGS {
  AUTOINSTALLED_FLAG = 0x1;
};
------- Comment #3 From 2018-03-02 18:36:25 -------
а зачем непременно нужно делать битовые флаги внутри одного тэга с расплывчатым
смыслом,не имея при этом удобного способа манипулировать битами librpm'ным api
?
Предлагаю, коль нужен некий признак AUTOINSTALLED, сделать тэг ровно с этим
смыслом и не пытаться экономить на спичках.
keep it simple, как говоридзе.
------- Comment #4 From 2018-03-02 19:11:30 -------
При добавлении новых тэгов рекомендую называть их ALT_имя и следовать разумному
предложению Jeff Johnson:

From: Jeff Johnson <n3npq@me.com>
Date: February 28, 2018 at 5:35:34 AM EST
To: rpm-maint@lists.rpm.org
Subject: Re: [Rpm-maint] Reserve ALT RPM tags range

You might try the convention of assigning tags in the 1Gb space from 0x40000000
to 0x4fffffff as you wish.

(aside)
RPM5 has something called "arbitrary tags" in the 0x40000000 -> 0x4fffffff
range.

Short answer:
Choose any tagno in that range and do what you wish.

Longer answer:

Choose a tag name string.

The  tagno is computed from a (configurable) tag name string as follows:

1) the tag name plain text is canonicalized (leading alphabetic, alphanumeric
characters, 1st letter uppercase, rest lowercase). E.g. "Mynewtag42"

2) the  4 binary bytes of the SHA1 of the canonical string are copied into a
uint32 (which needs to be swabbed on big endian platforms).

3) the tagno is assigned by then masking on the 0x40000000 arbitrary tag
identifier onto the least significant 30 bits of the uint32.
------- Comment #5 From 2018-03-08 22:43:05 -------
(In reply to comment #3)
> а зачем непременно нужно делать битовые флаги внутри одного тэга с расплывчатым
> смыслом,не имея при этом удобного способа манипулировать битами librpm'ным api
> ?
> Предлагаю, коль нужен некий признак AUTOINSTALLED, сделать тэг ровно с этим
> смыслом и не пытаться экономить на спичках.
> keep it simple, как говоридзе.

Да, это была экономия на спичках. Лучше пусть будет RPMTAG_AUTOINSTALLED.
------- Comment #6 From 2018-03-08 22:53:02 -------
(In reply to comment #4)
> При добавлении новых тэгов рекомендую называть их ALT_имя и следовать разумному
> предложению Jeff Johnson:

Предложение Jeff'а Johnson'а действительно хорошее, но апстрим согласился
принять RPMTAG_AUTOINSTALLED в список тегов (но с другим индексом), поэтому в
этом случае пожалуй будет лучше использовать этот тег.

Из переписки с Panu:
> > Tracking the install reason is a common need across pretty much all the                                                                                                                    
> > depsolvers. Send a patch and we'll see where it goes from there?
> 
> Ok, but the tag is just for record to RPM database, all the logic is on apt                                                                                                                  
> side.

Sure, rpm cli wouldn't set such a tag by itself because the notion of "pulled   
in as a dependency" doesn't happen there. But if/when present, there might be   
some uses for it in rpm too - even if just informational display.
------- Comment #7 From 2018-03-13 12:16:16 -------
Хорошо, я сделаю новую версию с RPMTAG_AUTOINSTALLED.
------- Comment #8 From 2018-03-13 14:02:57 -------
(In reply to comment #7)
> Хорошо, я сделаю новую версию с RPMTAG_AUTOINSTALLED.

См. тж. http://lists.rpm.org/pipermail/rpm-maint/2018-March/007544.html
и http://lists.rpm.org/pipermail/rpm-maint/2018-March/007576.html
------- Comment #9 From 2018-03-14 16:57:27 -------
(In reply to comment #8)
> (In reply to comment #7)
> > Хорошо, я сделаю новую версию с RPMTAG_AUTOINSTALLED.
> 
> См. тж. http://lists.rpm.org/pipermail/rpm-maint/2018-March/007544.html
> и http://lists.rpm.org/pipermail/rpm-maint/2018-March/007576.html

См. также http://lists.rpm.org/pipermail/rpm-maint/2018-March/007601.html

Можно обсудить получающуюся реализацию с rpm-maint@ напрямую.


Just noting that we should consider those other values with some care 
because it's not just a binary yes/no value, at least buildrequires and 
different levels and types of weak dependencies seem worth tracking 
separately. Maybe an enum defining the legal values.

Other future ponderings:

We'll should probably add some sort of API for this later on. IIRC C/C++ 
callers can set it in the header directly from the callback (IIRC), but 
that wont work with the python bindings and wouldn't hurt to have an 
explicit API for C/C++ too.

Optimally there would also be a way to change the install-time recorded 
value from cli, since the reason might change. And it might be something 
that wants to be inherited on package upgrades without explicitly 
setting (a package might be installed as a dependency but then updated 
manually with rpm, etc)

    - Panu -
------- Comment #10 From 2018-03-27 10:26:43 -------
Новая версия патчей готова, тестовое задание #199955.