Please keyword it and its dependencies for ~amd64-fbsd. dev-java/pdfbox/pdfbox-0.7.3-r2.ebuild: DEPEND: ~amd64-fbsd(default/bsd/fbsd/amd64/9.1) ['>=dev-java/bcprov-1.32:1.3', '=dev-java/bcmail-1.38*:0'] dev-java/pdfbox/pdfbox-0.7.3-r2.ebuild: RDEPEND: ~amd64-fbsd(default/bsd/fbsd/amd64/9.1) ['>=dev-java/bcprov-1.32:1.3', '=dev-java/bcmail-1.38*:0'] Thank you in advance.
12 Jul 2013; Patrick Lauer <patrick@gentoo.org> pdfbox-0.7.3-r2.ebuild: QA: Adding ~amd64-fbsd keyword to avoid keyword removal cascade 11 Jul 2013; Tom Wijsman <TomWij@gentoo.org> pdfbox-0.7.3-r2.ebuild: Fixed dependencies to not depend on newest versions which break compilation; might need better slotting, planning to look into that tomorrow. Fixes bug #476018, reported by Jason Mours. you should not be introducing broken deps like that. if you have to introduce a new dep causing your package to have missing deps then take it as a hint you're doing something wrong and dont drop keywords blindly: make a rev. bump of your package with less keywords. note: Im not sure what you were fixing but it was fine when I keyworded it... 12 May 2012; Alexis Ballier <aballier@gentoo.org> pdfbox-0.7.3-r2.ebuild: keyword ~amd64-fbsd 12 May 2012; Alexis Ballier <aballier@gentoo.org> bcmail-1.45.ebuild: keyword ~amd64-fbsd thanks patrick anyway
(In reply to Alexis Ballier from comment #1) > you should not be introducing broken deps like that. Why do you think the dependencies are broken? > if you have to introduce a new dep causing your package to have missing deps That's not what happened; the version ranges were restricted, nothing more. > make a rev. bump Compilation fixes don't need a revision bump; as asked in #gentoo-dep, dependency changes don't need a revision bump either. I don't see a reason to do a revision bump here; nothing is changed that causes a change in the image, or a change in the behaviour of the image. Please elaborate if you still think one is needed.
(In reply to Tom Wijsman (TomWij) from comment #2) > (In reply to Alexis Ballier from comment #1) > > you should not be introducing broken deps like that. > > Why do you think the dependencies are broken? That's what the bug is about and what I understood from reading ChangeLogs. > > if you have to introduce a new dep causing your package to have missing deps > > That's not what happened; the version ranges were restricted, nothing more. But then why, when it used to be fine, it was not anymore ? > > make a rev. bump > > Compilation fixes don't need a revision bump; as asked in #gentoo-dep, > dependency changes don't need a revision bump either. I don't see a reason > to do a revision bump here; nothing is changed that causes a change in the > image, or a change in the behaviour of the image. Please elaborate if you > still think one is needed. In general you are right but this case is one of the exceptions. I still don't get how you managed to obtain broken deps, so let me make up an example. You have a package bar, stable on most arches, depending on || ( libfoo1 libfoo2 ). libfoo1, being very old, has the same keyword visibility as bar. libfoo2 has much less keywords and in particular is not stable. libfoo1 is very buggy and installs a header with old style C that breaks building bar with gcc 4.10, so you want to replace that || dep with only libfoo2, which has the advantage of fixing compilation of bar and avoiding some bugs. You cannot do it because repoman yells at you libfoo2 is missing keywords. So you remove the keywords that do not match from bar and, in particular, de-stabilize it. Which in turns breaks the deps of every stable package depending on bar, but you didn't notice because repoman didn't yell when checking the deps of bar. You probably undesrstand easily what's wrong in the above scenario and how a revbump of bar, dropping non matching keywords, would have solved the problem. This commit is another instance of this scenario: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-java/pdfbox/pdfbox-0.7.3-r2.ebuild?r1=1.13&r2=1.14 Now the revbump is not needed anymore since patrick rekeyworded everything.
(In reply to Alexis Ballier from comment #3) > > Why do you think the dependencies are broken? > > That's what the bug is about and what I understood from reading ChangeLogs. I filed the bug because I dropped a keyword to satisfy repoman; that is, because the version range did not have that keyword. This doesn't make the dependencies broken, because they did not have the keyword; why, no idea how that happened. > > That's not what happened; the version ranges were restricted, nothing more. > > But then why, when it used to be fine, it was not anymore ? As stated in the previous paragraph, things were not fine; let me elaborate: Because the slots of the bc* packages aren't consistent, a bug for bcmail was filed as well but I would like it to be the same as bcprov because that would reflect bcmail the most; I'm not sure if I can restore bcprov to a sane state without breaking stuff, that's why I'm leaving things working as is before looking at this in further detail or just let it naturally work out as we go forward. Don't fix things that ain't broken; so, this is what we ended up with. Help is welcome and I'm all ears on solving those slot problems; though, I don't think this is a problem in just those packages but rather among a part of the Portage tree. Maybe we need to revise this issue on a larger scale. > > > make a rev. bump > > > > Compilation fixes don't need a revision bump; as asked in #gentoo-dep, > > dependency changes don't need a revision bump either. I don't see a reason > > to do a revision bump here; nothing is changed that causes a change in the > > image, or a change in the behaviour of the image. Please elaborate if you > > still think one is needed. > > In general you are right but this case is one of the exceptions. I still > don't get how you managed to obtain broken deps, so let me make up an > example. Explained in my previous paragraph. > You have a package bar, stable on most arches, depending on || ( libfoo1 > libfoo2 ). libfoo1, being very old, has the same keyword visibility as bar. > libfoo2 has much less keywords and in particular is not stable. > > libfoo1 is very buggy and installs a header with old style C that breaks > building bar with gcc 4.10, so you want to replace that || dep with only > libfoo2, which has the advantage of fixing compilation of bar and avoiding > some bugs. You cannot do it because repoman yells at you libfoo2 is missing > keywords. So you remove the keywords that do not match from bar and, in > particular, de-stabilize it. Which in turns breaks the deps of every stable > package depending on bar, but you didn't notice because repoman didn't yell > when checking the deps of bar. Yes, that is indeed the problem here; bonsaikitten scripts catches this, and ideally I would like repoman to catch this so yet another thing already on my list is to implement checks that run only the dependency checks against the ebuilds that list this as a dependency. This should be fairly easy to do; ignoring eclasses to start with, that's a problem to solve on its own for later. We already discussed this on gentoo-dev; I can elaborate on this later, but it's outside of the scope of this bug. > You probably undesrstand easily what's wrong in the above scenario and how a > revbump of bar, dropping non matching keywords, would have solved the > problem. > This commit is another instance of this scenario: > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-java/pdfbox/ > pdfbox-0.7.3-r2.ebuild?r1=1.13&r2=1.14 > > Now the revbump is not needed anymore since patrick rekeyworded everything. What I assumed wrong here, is that I thought it was an application; for an application, I assumed nothing depends on it which is almost always the case. So, if a package cannot build on a platform; it is required to drop keyword. I agree with you that for a library like this pkg, a rev bump is the way to go; though, this could be argued as well, since the stable version would still be broken on that platform which means that basically per QA rules the keyword would have to be dropped anyway, or the stable version would need to be masked. Long story short; we're dealing with a nasty dependency, resulting in this cascade which is a non common case where you can't simply do what you suggest. If the dependency was proper, this cascade wouldn't have happened; unfortunate.
(In reply to Tom Wijsman (TomWij) from comment #4) > (In reply to Alexis Ballier from comment #3) > > > Why do you think the dependencies are broken? > > > > That's what the bug is about and what I understood from reading ChangeLogs. > > I filed the bug because I dropped a keyword to satisfy repoman; that is, > because the version range did not have that keyword. This doesn't make the > dependencies broken, because they did not have the keyword; why, no idea how > that happened. > bug #476018 shows a failure with bcmail/pcprov 1.49. from comment #1 you can see those were fine with 1.45: You restricted the version too much. > What I assumed wrong here, is that I thought it was an application; for an > application, I assumed nothing depends on it which is almost always the > case. So, if a package cannot build on a platform; it is required to drop > keyword. even in this case it is still wrong because you are downgrading the visibility of a package: users might have it installed and end up having it uninstallable for no good reason. > I agree with you that for a library like this pkg, a rev bump is the way to > go; though, this could be argued as well, since the stable version would > still be broken on that platform which means that basically per QA rules the > keyword would have to be dropped anyway, or the stable version would need to > be masked. only the latest, ~arch version, of bc* broke it, so no, stable ain't broken. > Long story short; we're dealing with a nasty dependency, resulting in this > cascade which is a non common case where you can't simply do what you > suggest. It is pretty common here. The common way to handle it is to mask latest bc*, fix its rev deps, and unmask when everything is fine. I don't know what you're trying to solve with slots, but heh, I'm not a java guy :)
btw, please have a look at: http://devmanual.gentoo.org/keywording/
(In reply to Alexis Ballier from comment #5) > bug #476018 shows a failure with bcmail/pcprov 1.49. from comment #1 you can > see those were fine with 1.45: You restricted the version too much. Oh, I see, I thought it had to do with a change in slot; appears not. Thanks. > even in this case it is still wrong because you are downgrading the > visibility of a package: users might have it installed and end up having it > uninstallable for no good reason. True, it also bails out because there are no ebuilds to satisfy dependencies. > only the latest, ~arch version, of bc* broke it, so no, stable ain't broken. Makes sense; but it could still break with stabilization of bc* in the future. Your next paragraph deals with that; I understand the importance now, thanks! > It is pretty common here. The common way to handle it is to mask latest bc*, > fix its rev deps, and unmask when everything is fine. I needed the new bc* for another package, so I can't just mask that; well, not at this point in time but I see that I could do that in advance, I'll check for reverse dependencies more carefully without any assumptions in the future when I bump a version on a library. Most dev-java packages are libs, I will make this into a habit in the future; because I don't want to break things. > I don't know what you're trying to solve with slots, but heh, I'm not a java guy :) Some people are getting automatically resolved slot conflicts, a red herring; that's why I think slots could benefit some fixing, to avoid future problems. (In reply to Alexis Ballier from comment #6) > btw, please have a look at: > http://devmanual.gentoo.org/keywording/ Will definitely do, it's been nearly six months since I started maintaining; I did a full read over all documentation back then, but as with any learning attempt not everything sticks if you only read it once. I'll read over that page again once I return from devaway; perhaps read everything again then, because taking a break likely gets me out of the usual habits. I'm also planning to cover some of these things with repoman then. Thank you very much for your reminder and explanations.
