> 2. upstream is dead or has decided to switch to another preferred > version/something else Upstream is dead is not relevant. Some usefull but stable apps have no upstream and that's not an issue. For an example there is asa, a package that convert fortran carriage control characters I maintain which has no upstream, but don't need one. > 3. known vulns/design problems Also shouldn't be a blocker. For example I maintain the cernlib in extras which has an upstream which is dead (except that the debian maintainer is a kind of upstream), it has some major design flows in the build system, ship some daemons that run as root, and, although they have no known issue haven't been audited seriously as far as I know. Is it a reason not to ship them? A user using those daemons should do that on purpose, more precisely I think that the cernlib users are not lambda users so having those issues in the cernlib is not a problem. For other packages it may be, but different packages have different user bases. Moreover it is said in the description I quote here: %description packlib I/O, network and miscalleneous utilities based on the CERN Program Library. According to the responsible of the cernlib debian package, some of these utilities may have security flaws. I personally think that it is acceptable and shouldn't be a reason not to ship those programs and even less not to ship the cernlib as a whole. Otherwise said fool users that install and and run random programs without knowing the consequences shouldn't stop those who use programs with flaws on purpose in an environemnt where it makes sense. <off-topic> To me it is the same with static versus shared libs. The fact that some uses of static libraries are broken, and that in some cases static don't make sense at all shouldn't prevent to ship static libs in the other cases for the users that have a relevant use of thoses libs. </off-topic> > 4. (for a lib) nothing depends on it in the repo, so there's no one to > check it actually works But a lib may be usefull in itself! > 5. (for a lib) almost nothing depends on it, and the few remaining users > are scheduled to switch in the next month In that case the maintainer should be smart enough to avoid propagating the lib to devel and to the following fedora version. > 6. (for an app) depends on a lib/susbsystem which falls under the previous > rules Agreed, in the sense that apps depends on orphaned libs should be considered as also in a kind of orphaned state. -- Pat -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
