pertusus at free.fr
Fri Apr 28 12:04:15 UTC 2006
> 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:
I/O, network and miscalleneous utilities based on the CERN Program
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.
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.
> 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
Agreed, in the sense that apps depends on orphaned libs should be considered
as also in a kind of orphaned state.
More information about the fedora-extras-list