On 06/01/2018 16:55, DJ Lucas wrote: > > > On 01/05/2018 03:26 PM, Bruce Dubbs wrote: >> [email protected] wrote: >>> Hi, >>> >>> On Fri, 5 Jan 2018, Pierre Labastie wrote: >>> >>>> On 05/01/2018 17:43, Bruce Dubbs wrote: >>>>> >>>>> The only reason for shadow in BLFS is to add PAM/cracklib. The term >>>>> 'Required' may be a little inconsistent, but we need something stronger >>>>> than >>>>> 'Recommended'. >>>> Maybe remove any dep in shadow, since it'd be better to have it the >>>> other way >>>> around, see below. > > The issue is that for jhalfs dependency tracking, what is needed is a "rebuild > trigger" (thank you Uwe) that jhalfs can parse programmatically. > >>>> >>>>>> Actually, Linux-PAM is pretty useless without recompiling shadow. >>>>> I'm OK with that, but I do add pam without rebuilding shadow in System >>>>> V and >>>>> it seems to not cause any problems. > > PAM is just never used for the roles in that case. You are using shadow for > authentication and password policy, and session and environment are handled > strictly via scripts in /etc. > >>>> >>>> I propose the following wording in "recommended dependencies": >>>> "shadow (should be rebuilt after this package)" >>> > > What about extending the role attribute for para to include a "runtime" value? > Pierre, this seems like it would work well for Shadow specifically, but what > about reciprocal deps such as harfbuzz/freetype? I admit that I don't know how > jhalfs parses the source, I presume some run of xsltproc, so comments are > probably removed. I suggest this: if a "sect4->para role="runtime"->xref > linkend=freetype" is encountered in harfbuzz, then jhalfs interprets this as a > "rebuild trigger" for freetype in the dependency graph? The term "runtime" > might be a bit loose here, but it seems to me to be better than "rebuild" or > other. This might be a bit overkill, but most of the packages are small, also > seems like there might be the possibility of an endless loop hidden in there. > I count only four instances...cracklib/pam/shadow{,/systemd}, {,systemd/dbus}, > freetype/harfbuzz, and mesa/libva. Any others? > >>> I kind of like that idea. IMHO this kind of information is pretty >>> valuable. I wouldn't call it a dependency, though. It is more like a >>> rebuild trigger. Every now and then I stumble across a package where >>> updating it is not enough because some package down the dependency chain >>> would need a rebuild because of that too. Getting perl modules into a new >>> perl version comes to mind, but there more subtile cases. On the other >>> hand, this happens seldom enough to justify just always rebuilding >>> everything depending in some way on an updated. >>> >>> Therefore, I appreciate the idea of specifying known critical "reverse >>> dependencies" like "if you install *this* (first time, although update is >>> the more likely use-case for me), it is highly recommended to rebuild >>> those packages (if installed):..." >>> Not sure whether this would be too much effort or whether PAM->shadow is a >>> good candidate. But it would simplify to process of having to find out >>> whether (in this cases) shadow depends on PAM in a really relevant (but >>> possibly indirect/long/optional way)... > > I agree with that it is useful, but it should also be useful for our tools. > >> >> Actually we have a similar situation with the circular dependencies of >> freetype and harfbuzz. That has worked out well. >> > > Yes, and the same problem there (as mentioned above). How does jhalfs deal > with this currently? > > --DJ >
Actually, I'm writing a new version of jhalfs, which implements roughly this: It's based on two types of dependencies: "before" deps are usual ones: they are built before the package which depends on them. "after" deps are dependencies which must (if required), should (if recommended) or may (if optional) be built after the package which depends on them. Typically "runtime" deps are of the "after" type. But this is not limited to runtime deps (we could still use role="runtime" for them, though). Note that solving the freetype<->harfbuzz cycle is slightly more complicated: you have to tell the system that freetype should be built *both* before and after harfbuzz, but the "before" one does not depend on harfbuzz... Uwe's suggestion is slightly different: it would involve signaling when package B, which depends on package A, should be rebuilt when package A is rebuilt. It's a rather good suggestion, I'd say. It involves adding some text to the book (and implementation in jhalfs). One example, which comes to my mind is poppler. Almost each new version of poppler changes the so version of libpoppler, so that any package using the library should be rebuilt after an update of poppler, at least if the previous library is removed. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
