Temporary "junk" Packages Are A Best Practice 📎
At the beginning of a project it is hard to find good names for packages--there are only a few classes to package and usually you are still in the phase of grasping the domain knowledge.
Particularly hard to find are good package names for classes with infrastructural responsibilities. In the first iterations class names and their packages are constantly refactored. A chance to find perfect name and home for all classes is negligible.
Instead of using generic, but good sounding names like, util, common, base, infrastructure, model, framework, a really bad sounding name like "waste", "junk" or "unrelated" does a better job by forcing you to refactor such a "kitchen sink" package with its contents in a later iteration.
Kitchen-sink "util" packages with un-cohesive contents have a far better chance of surviving a code review, than an intentionally "bad" named package like "waste" or "sink".
[See also an in-depth discussion in the "Real World Java EE Patterns--Rethinking Best Practices" book (Second Iteration, "Green Book"), page 420 in, chapter "Pragmatic Java EE Architectures"]