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
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
