| Summary: | app-portage/gentoolkit and sys-apps/portage both install glsa-check. Different versions. | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Miles Georgi <azimux> |
| Component: | Tools | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | flow, leio, maffblaster, security |
| Priority: | Normal | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 693088 | ||
| Bug Blocks: | 606136, 691278 | ||
|
Description
Miles Georgi
2013-03-31 00:50:53 UTC
The version 1.0 in portage's copy is meaningless. The version that comes with gentoolkit is the official one. So, I think we should just fix portage to not install its copy of glsa-check. why it's in portage still, then? Well, the copy that's in Portage might be useful for testing Portage's glsa code for compatibility with Gentoolkit's. Portage's glsa library is used to implement the @security package set for emerge. So maybe it'd be meaningful to move it completely to Portage instead of keeping two copies of the same code with different modifications and a lot confusion on top?! (In reply to Michał Górny from comment #4) > So maybe it'd be meaningful to move it completely to Portage instead of > keeping two copies of the same code with different modifications and a lot > confusion on top?! Yeah that sounds reasonable to me. I've merged a couple of glsa patches from the gentoolkit repo: https://gitweb.gentoo.org/proj/portage.git/commit/?id=9a506b4d7429a589416eee48d02ca7ed42ef1898 https://gitweb.gentoo.org/proj/portage.git/commit/?id=652202b382c247dbc32296f03a9e654713776cbe There's one more here that I haven't tested yet: https://github.com/gentoo/portage/pull/91 And there's one more attached to bug 605612. Zac, would it make sense to also make the glsa-check be runnable by emaint as well as emerge? That would make an equivalent command to the gentoolkit one for those people that have the gentoolkit one scripted. It would make an easier changeover for them. side note. In the same idea, maffblaster was suggesting some other gentoolkit commands be merged like "equery check". That could be an emaint module instead. maffblaster, open bugs for each module you feel should be part of portage releases. Also keep in mind that the emaint module system can have modules released on their own as plug-ins and installed via ebuild separately. (In reply to Brian Dolbec from comment #6) > Zac, would it make sense to also make the glsa-check be runnable by emaint > as well as emerge? That would make an equivalent command to the gentoolkit > one for those people that have the gentoolkit one scripted. It would make > an easier changeover for them. Yes, that sounds good to me. > side note. In the same idea, maffblaster was suggesting some other > gentoolkit commands be merged like "equery check". That could be an emaint > module instead. I like that idea too. As per my suggestion in bug 605612, could we make gentoolkit use portage's glsa module? That might be as simple as moving portage glsa-check to gentoolkit, if all the arguments line up. Or might be also as simple as changing "from gentoolkit import glsa" to "from portage import glsa" or some such. Then we have one module to worry about for the revised count attribute bug and other things at least, that glsa-check, @security set and any future emaint module can use. (In reply to Mart Raudsepp from comment #8) > As per my suggestion in bug 605612, could we make gentoolkit use portage's > glsa module? > That might be as simple as moving portage glsa-check to gentoolkit, if all > the arguments line up. Or might be also as simple as changing "from > gentoolkit import glsa" to "from portage import glsa" or some such. > Then we have one module to worry about for the revised count attribute bug > and other things at least, that glsa-check, @security set and any future > emaint module can use. Yes, that is entirely possible. Once it is done we can make another gentoolkit release so that we can get it stabled asap, and proceed with the emaint module replacement. (In reply to Brian Dolbec from comment #9) > (In reply to Mart Raudsepp from comment #8) > > As per my suggestion in bug 605612, could we make gentoolkit use portage's > > glsa module? > > That might be as simple as moving portage glsa-check to gentoolkit, if all > > the arguments line up. Or might be also as simple as changing "from > > gentoolkit import glsa" to "from portage import glsa" or some such. > > Then we have one module to worry about for the revised count attribute bug > > and other things at least, that glsa-check, @security set and any future > > emaint module can use. > > Yes, that is entirely possible. Once it is done we can make another > gentoolkit release so that we can get it stabled asap, and proceed with the > emaint module replacement. I think the best option here is to remove glsa-check from gentoolkit and move it to Portage. I am not sure if this breaks what is codified in PMS or not, but security should be default to the system vice being optionally installed through gentoolkit. This may be a long term solution given merging the code. Thoughts? The short term approach is to push the appropriate fixes to gentoolkit. This will also allow security to conform to the standing GLSA DTD and make all published GLSAs uniform. Portage team's thoughts here would be much appreciated. If the merging of code is trivial then the short term solution may not be needed. Thanks. (In reply to Aaron Bauman from comment #10) > (In reply to Brian Dolbec from comment #9) > > (In reply to Mart Raudsepp from comment #8) > > > As per my suggestion in bug 605612, could we make gentoolkit use portage's > > > glsa module? > > > That might be as simple as moving portage glsa-check to gentoolkit, if all > > > the arguments line up. Or might be also as simple as changing "from > > > gentoolkit import glsa" to "from portage import glsa" or some such. > > > Then we have one module to worry about for the revised count attribute bug > > > and other things at least, that glsa-check, @security set and any future > > > emaint module can use. > > > > Yes, that is entirely possible. Once it is done we can make another > > gentoolkit release so that we can get it stabled asap, and proceed with the > > emaint module replacement. > > I think the best option here is to remove glsa-check from gentoolkit and > move it to Portage. I am not sure if this breaks what is codified in PMS or > not, but security should be default to the system vice being optionally > installed through gentoolkit. This may be a long term solution given > merging the code. Thoughts? > > The short term approach is to push the appropriate fixes to gentoolkit. > This will also allow security to conform to the standing GLSA DTD and make > all published GLSAs uniform. > > Portage team's thoughts here would be much appreciated. If the merging of > code is trivial then the short term solution may not be needed. Thanks. READ comment #8 and the other comments...: 1) The idea is to make the portage repo contain the one updated copy of the glsa code. There are very few changes to the code as already noted by Mart. It is mostly for it to fit into the portage eco-system and configs. So migration should not be difficult. 2) make the gentoolkit glsa-check command use the code from portage instead of it's current code. gentoolkit already deps on portage since many of it's commands already use portage APIs. 3) release new portage and gentoolkit versions with appropriate blocks. 4) Create the new emaint replacement command, portage release 5) deprecate the gentoolkit glsa-check command 6) eventually remove glsa-check from gentoolkit. Aaron, as I recall, the glsa-check code was put in gentoolkit for initial development, debugging, to later become part of portage. Only problem is it never migrated out of gentoolkit (primary dev retired). So there ended up being 2 copies of the code. (In reply to Brian Dolbec from comment #11) > (In reply to Aaron Bauman from comment #10) > > (In reply to Brian Dolbec from comment #9) > > > (In reply to Mart Raudsepp from comment #8) > > > > As per my suggestion in bug 605612, could we make gentoolkit use portage's > > > > glsa module? > > > > That might be as simple as moving portage glsa-check to gentoolkit, if all > > > > the arguments line up. Or might be also as simple as changing "from > > > > gentoolkit import glsa" to "from portage import glsa" or some such. > > > > Then we have one module to worry about for the revised count attribute bug > > > > and other things at least, that glsa-check, @security set and any future > > > > emaint module can use. > > > > > > Yes, that is entirely possible. Once it is done we can make another > > > gentoolkit release so that we can get it stabled asap, and proceed with the > > > emaint module replacement. > > > > I think the best option here is to remove glsa-check from gentoolkit and > > move it to Portage. I am not sure if this breaks what is codified in PMS or > > not, but security should be default to the system vice being optionally > > installed through gentoolkit. This may be a long term solution given > > merging the code. Thoughts? > > > > The short term approach is to push the appropriate fixes to gentoolkit. > > This will also allow security to conform to the standing GLSA DTD and make > > all published GLSAs uniform. > > > > Portage team's thoughts here would be much appreciated. If the merging of > > code is trivial then the short term solution may not be needed. Thanks. > > READ comment #8 and the other comments...: > > 1) The idea is to make the portage repo contain the one updated copy of the > glsa code. There are very few changes to the code as already noted by Mart. > It is mostly for it to fit into the portage eco-system and configs. So > migration should not be difficult. > > 2) make the gentoolkit glsa-check command use the code from portage instead > of it's current code. gentoolkit already deps on portage since many of it's > commands already use portage APIs. > > 3) release new portage and gentoolkit versions with appropriate blocks. > > 4) Create the new emaint replacement command, portage release > > 5) deprecate the gentoolkit glsa-check command > > 6) eventually remove glsa-check from gentoolkit. > > > Aaron, as I recall, the glsa-check code was put in gentoolkit for initial > development, debugging, to later become part of portage. Only problem is it > never migrated out of gentoolkit (primary dev retired). So there ended up > being 2 copies of the code. Sounds great to me. Let me know how I can assist. Thanks to Mart and the Portage team for reinvigorating the work :) (In reply to Brian Dolbec from comment #11) > 2) make the gentoolkit glsa-check command use the code from portage instead > of it's current code. gentoolkit already deps on portage since many of it's > commands already use portage APIs. > > 3) release new portage and gentoolkit versions with appropriate blocks. And if glsa-check binary is kept in gentoolkit side per 2), the list of appropriate blocks for 3) is zero, and the new gentoolkit release should probably just depend on newest portage, even though strictly not even necessary - though probably should after the revised count attribute fix is ported to portage and perhaps the other stuff (the merges Zac already did in git). I'm not sure if we can ever anytime soon really remove glsa-check beyond deprecating, or if we even should, though I like the emaint one to get some better naming than "--list affected" for a fresh design, especially in terms of bug 606136 if it goes anywhere. We could start by (In reply to Zac Medico from comment #14) > We could start by I was going to say we could make gentoolkit's glsa-check simply an entry point for portage APIs. Looks like both versions are currently in sync. Last commit: https://gitweb.gentoo.org/proj/portage.git/commit/?id=aa0cf0c993759f559988c8d0d6ea50be8cf716ce https://gitweb.gentoo.org/proj/gentoolkit.git/commit/?id=8aed03d3c4170943568ff1446574f21e0c7396d7 Make portage install /usr/bin/glsa-check and glsa-check.1 man page: https://archives.gentoo.org/gentoo-portage-dev/message/ba89ba4782a35f6f8ea7cef4e033e038 https://github.com/gentoo/portage/pull/445 Remove glsa-check from gentoolkit: https://archives.gentoo.org/gentoo-portage-dev/message/347d8c8caffb75181ad397bb2aee43b4 https://github.com/gentoo/gentoolkit/pull/5 The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/gentoolkit.git/commit/?id=429b629e3bb0469cf34d170ad06663e0eabd2d9f commit 429b629e3bb0469cf34d170ad06663e0eabd2d9f Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-08-13 01:24:04 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-08-19 03:42:40 +0000 glsa-check moved to portage repository (bug 463952) This copy of glsa-check is no longer need since it has moved to the portage repository. Bug: https://bugs.gentoo.org/463952 Signed-off-by: Zac Medico <zmedico@gentoo.org> README | 1 - bin/glsa-check | 418 ----------------------- man/glsa-check.1 | 66 ---- pym/gentoolkit/glsa/__init__.py | 741 ---------------------------------------- setup.py | 2 - 5 files changed, 1228 deletions(-) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=cd5e6d8d4e84bc042c041f75e428410d6cdb5475 commit cd5e6d8d4e84bc042c041f75e428410d6cdb5475 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-08-13 01:02:55 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-08-19 04:09:54 +0000 glsa-check: install in /usr/bin (bug 463952) In order to eliminate the duplicate implementation from gentoolkit, install glsa-check into /usr/bin and add man page from gentoolkit. Bug: https://bugs.gentoo.org/463952 Signed-off-by: Zac Medico <zmedico@gentoo.org> man/glsa-check.1 | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ setup.py | 2 +- 2 files changed, 67 insertions(+), 1 deletion(-) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=08557524dc6c8eec3a366e43ab2587d2cdd8f133 commit 08557524dc6c8eec3a366e43ab2587d2cdd8f133 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-08-19 04:24:07 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-08-19 05:06:15 +0000 sys-apps/portage: Bump to version 2.3.72 #463952 glsa-check: install in /usr/bin #646090 preserve-libs: get dep graph from EROOT #690484 detect internal collisions for /usr merge #690786 repoman: support metadata/layout.conf restrict-allowed #691776 unpack: Unconditionally die if an unpacker returns an error #691638 Show get/setfattr stderr #692024 econf: Unconditionally die on error in EAPIs 0 to 3 #692262 QA Notice: EXPORT_FUNCTIONS is called before inherit in kernel-2.eclass #692412 emerge IndexError for ambiguous package atom with pypy Bug: https://bugs.gentoo.org/691278 Bug: https://bugs.gentoo.org/463952 Bug: https://bugs.gentoo.org/646090 Bug: https://bugs.gentoo.org/690484 Bug: https://bugs.gentoo.org/690786 Bug: https://bugs.gentoo.org/691776 Bug: https://bugs.gentoo.org/691638 Bug: https://bugs.gentoo.org/692024 Bug: https://bugs.gentoo.org/692262 Bug: https://bugs.gentoo.org/692412 Package-Manager: Portage-2.3.71, Repoman-2.3.17 Signed-off-by: Zac Medico <zmedico@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-2.3.72.ebuild | 264 +++++++++++++++++++++++++++++++++ 2 files changed, 265 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e5b2a1086997f3bda772910edf5199a3827b5137 commit e5b2a1086997f3bda772910edf5199a3827b5137 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-08-19 04:00:56 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-08-19 05:06:14 +0000 app-portage/gentoolkit: Bump to version 0.4.6 Bug: https://bugs.gentoo.org/463952 Bug: https://bugs.gentoo.org/634824 Package-Manager: Portage-2.3.71, Repoman-2.3.17 Signed-off-by: Zac Medico <zmedico@gentoo.org> app-portage/gentoolkit/Manifest | 1 + app-portage/gentoolkit/gentoolkit-0.4.6.ebuild | 74 ++++++++++++++++++++++++++ 2 files changed, 75 insertions(+) |
