[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.
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.
I propose the following wording in "recommended dependencies":
"shadow (should be rebuilt after this package)"
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)...
Actually we have a similar situation with the circular dependencies of
freetype and harfbuzz. That has worked out well.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
