package EOL

[Patrice Dumas]

> 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