| Summary: | Document the recommendation of *not* setting downgrading dependencies on 'the same stabilization level | ||
|---|---|---|---|
| Product: | Documentation | Reporter: | Samuli Suominen (RETIRED) <ssuominen> |
| Component: | Devmanual | Assignee: | Gentoo Devmanual Team <devmanual> |
| Status: | CONFIRMED --- | ||
| Severity: | enhancement | CC: | creffett, kensington, pacho, sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 414997 | ||
This should be in devmanual, I believe, propably in the dependencies section... Looks like a devmanual topic, and thus not something that GDP helps with. The council has found on 2012-11-13 that there exists no policy which makes downgrading dependencies illegal. They are strongly discouraged however. patches are welcomed :) |
If ~arch package called libfoo-2.0 breaks packages like bar-1.0 but works for foobar-2.0 you can't set <libfoo-2.0 dependency to bar-1.0 because they all are in ~arch But you can set the dependency *after* first masking libfoo-2.0 and foobar-2.0 so that none of the packages try to downgrade another on the same stabilization level This seems to be unclear to our 'new' developers: 18:54 <@Mr_Bones_> kensington: x11-plugins/pidgin-otr-4.0.0: nonsolvable depset(depends) keyword(~x86) profile (default/linux/x86/10.0/desktop): solutions: [ >=net-libs/libotr-4.0.0 ] 18:55 <@ssuominen> Mr_Bones_: umm, libotr-4.0.0 is in tree 18:55 <@Mr_Bones_> it's masked 18:55 <@ssuominen> ah 18:55 <@creffett|mobile> for good reason 18:55 <@ssuominen> right, of course, since it breaks every other dep than that 18:55 <@ssuominen> api 18:55 <@bonsaikitten> ssuominen: it's a dirty hack I did. if infra set up a commit hook we wouldn't need such an ugly thing 18:56 <@bonsaikitten> ssuominen: it's an email scraper, can't get much more ugly :) 18:56 <@ssuominen> bonsaikitten: of course I appericiate there is something there :) 18:56 <@Zero_Chaos> bonsaikitten: let infra upgrade to git before complaining for commit hooks 18:56 <@ssuominen> bonsaikitten: but some irkkk kolours would make it better ;p 18:56 <@bonsaikitten> Zero_Chaos: wrong fix 18:56 <@kensington> irk colours++ 18:56 <@kensington> Mr_Bones_: thanks 18:56 <@bonsaikitten> ssuominen: yeah, the ssh gateway in between makes that a bit tricky 18:57 <@bonsaikitten> ssuominen: would be easier if I could do things the right way :) 18:57 <@ssuominen> nod 18:59 <@ssuominen> Mr_Bones_: I just went and masked pidgin-otr too 18:59 <@ssuominen> kensington: ^ 18:59 <@hasufell> ssuominen: it still has that security issue (when dbus is activated) 19:00 <@hasufell> should have been masked long ago 19:00 <@kensington> ssuominen: too fast ;) 19:01 <@ssuominen> hasufell: it breaks kde-base/kopete and, NO setting dependency like <libotr-4.0.0 is not acceptable if it's not in p.mask 19:01 <@ssuominen> we have a tracker for those violations 19:01 <@WilliamH> Mr_Bones_: ping 19:01 <@hasufell> https://developer.pidgin.im/ticket/14830 19:01 <@ssuominen> bug 414997 19:01 <+willikins> ssuominen: https://bugs.gentoo.org/414997 "[TRACKER] Packages depending on old versions at the same stabilization level"; Gentoo Linux, Applications; CONF; pacho:qa 19:02 <@ssuominen> but you can remove kopete from any kde metas, and same for others, then mask <libotr-4.0.0 for security 19:02 <@ssuominen> along with anything that doesn't build 19:02 <@ssuominen> i'm sure kde users will appericiate that ;pp 19:03 <@kensington> a few maintainers have already set <libotr-4.0.0 19:03 <@ssuominen> that's OK now because >=libotr-4.0.0 is masked 19:04 <@ssuominen> but it can't be unmasked until those packages have a revision that doesn't set that < depend 19:04 <@ssuominen> you cannot, ever, set < dependency that downgrades other packages 19:04 <@ssuominen> without a mask 19:04 -!- mschiff [~mschiff@port-93088.pppoe.wtnet.de] has joined #gentoo-dev 19:04 -!- mschiff [~mschiff@port-93088.pppoe.wtnet.de] has quit [Changing host] 19:04 -!- mschiff [~mschiff@gentoo/developer/mschiff] has joined #gentoo-dev 19:04 -!- mode/#gentoo-dev [+o mschiff] by ChanServ 19:04 -!- fisted [~fisted@unaffiliated/fisted] has quit [Read error: Operation timed out] 19:05 <@creffett|mobile> ssuominen: it was a quick fix and it did work, and i 19:05 <@ssuominen> thats been the policy since the beginning, just some people have lately been skipping it, hence we opened the tracker with pacho to track down the offenders 19:05 <@creffett|mobile> did not know that that was not allowed 19:06 <@ssuominen> creffett|mobile: it's something your mentor should have explained to you :) 19:06 <@creffett|mobile> I guess we missed that lesson 19:06 * kensington had the same mentor as creffett and also did not have that explained :p 19:06 <@Zero_Chaos> lol 19:07 <@ssuominen> (ok I have no idea who your mentor is and I don't want to enter any blame-game) :) 19:07 <@ssuominen> off to supper -> 19:09 <@kensington> is this rule documented in the devmanual? 19:11 <@ssuominen> kensington: it's been vetted in the gentoo-dev ML twice to same conclusion; it's been deemed common sense. 19:12 -!- hanno [~hanno@91-64-39-125-dynip.superkabel.de] has quit [Quit: Verlassend] 19:12 <@ssuominen> kensington: if you wish it to be documented, I would suggest a bug to qa@ for devmanual update. 19:12 <@ssuominen> with a reference to the Tracker 19:12 <@creffett|mobile> +1 19:13 <@kensington> ssuominen: I don't disagree that it is a good idea, just wondering if it's written out somewhere (given that both creffett and myself missed this rule) 19:13 <@ssuominen> it might be, really, I don't know 19:14 <@creffett|mobile> I don't remember it, and since we both missed this I'm all for writing it down.