package EOL

Michael A. Peters mpeters at
Fri Apr 28 20:56:11 UTC 2006

On Fri, 2006-04-28 at 22:27 +0200, Nicolas Mailhot wrote:

> I didn't propose to stop shipping them, but putting them in a separate
> Fedora repo to highlight the fact the level of support/testing/fixing
> which can be expected is way lower than that of main FE repo itself.

Some maintainers may do a better job at maintaining a package with no
active upstream than some packagers can with an active upstream.

> > But a lib may be usefull in itself!
> If the lib is useful then there should be at least one packageable user.

Some libraries are not intended to be used in end user applications, but
are intended to be used by users writing programs to solve a specific
problem - such as in the sciences, where they sometimes write programs
specifically to deal with the experiment they are doing.

> If *no* lib user can be packaged :
> 1. then it may not be so useful after all
> 2. or it's only used by unpackageable stuff, in which case I  don't see
> why it should be packaged when its users aren't

It may be of value to third party repositories, or to end users who want
to install foo.rpm they downloaded off the net, or want to build
something from source.

If someone wants to maintain it, then it doesn't matter if an extras
package currently uses it.

A library is no different from a perl module. Some perl modules are
provided not because packaged perl applications need them, but because
people who use perl on their system need them.

If a library doesn't have a package that uses it - there very well may
be people who write compiled programs on their local system that use
want them.

> Also it's going to be loads of fun when users report problems with the
> lib and there are no users in the repo to test it against/reproduce the
> problem

The user should be able to specify what software they are using that has
a problem with the lib. Very often the devel packages have sample code
that can be used to test. A maintainer shouldn't submit a package that
they are not able in some way to test.

> > > 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.

If the maintainer is willing to maintain it, it should go into the next
version for compatibility reasons. Backwards compatibility makes it
easier for people to run the latest version of Fedora - reducing the
number of people who _need_ to run legacy versions of Fedora to use
Linux for what they need to get accomplished.

More information about the fedora-extras-list mailing list