Summary: | [FR] Реализовать RPMTAG_AUTOINSTALLED | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Vladimir D. Seleznev <vseleznv> |
Component: | librpm7 | Assignee: | darktemplar <darktemplar> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | enhancement | ||
Priority: | P3 | CC: | at, darktemplaralt, glebfm, imz, ldv, mike, placeholder, rider, sbolshakov, vseleznv, vt |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux | ||
Bug Depends on: | |||
Bug Blocks: | 34036 |
Description
Vladimir D. Seleznev
2017-11-28 21:11:58 MSK
Переформулировка задачи: реализовать новый тег altflags типа 32bit integer, один из битов которого использовать для обозначения пакетов, установленных по зависимостям: enum ALT_FLAGS { AUTOINSTALLED_FLAG = 0x1; }; а зачем непременно нужно делать битовые флаги внутри одного тэга с расплывчатым смыслом,не имея при этом удобного способа манипулировать битами librpm'ным api ? Предлагаю, коль нужен некий признак AUTOINSTALLED, сделать тэг ровно с этим смыслом и не пытаться экономить на спичках. keep it simple, как говоридзе. При добавлении новых тэгов рекомендую называть их 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. (In reply to comment #3) > а зачем непременно нужно делать битовые флаги внутри одного тэга с расплывчатым > смыслом,не имея при этом удобного способа манипулировать битами librpm'ным api > ? > Предлагаю, коль нужен некий признак AUTOINSTALLED, сделать тэг ровно с этим > смыслом и не пытаться экономить на спичках. > keep it simple, как говоридзе. Да, это была экономия на спичках. Лучше пусть будет RPMTAG_AUTOINSTALLED. (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. Хорошо, я сделаю новую версию с RPMTAG_AUTOINSTALLED. (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 (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 - Новая версия патчей готова, тестовое задание #199955. rpm-4.13.0.1-alt2 -> sisyphus: Fri Jun 08 2018 Gleb F-Malinovskiy <glebfm@altlinux> 4.13.0.1-alt2 - darktemplar@: + Added tag RPMTAG_AUTOINSTALLED (closes: #34252); + spec: use strong interpackage dependencies. - Readded armh arch support (by Sergey Bolshakov). - librpm7: changed C: librpm to match 4.0.4-alt101.M80P.* versions from p8 (ALT#34505). - Synced macros definitions with rpm-build 4.0.4-alt112 (ALT#34684). - Fixed posttrans filetriggers when different root path is used (ALT#34430). - Changed rpm output format of non-terminal output to avoid truncation of package names. |