half baked idea for further baking: "fedora-ugly" repo

[Toshio Kuratomi]

On Mon, Feb 10, 2014 at 03:49:51AM -0500, Matthew Miller wrote:
> On Sun, Feb 09, 2014 at 06:56:41PM +0100, Bill Nottingham wrote:
> > IOW, why not just restrict the super strict guidelines to the core product
> > repos of Fedora, and have this repo be for things outside of that, which can
> > include things that follow the guidelines, and things like chef that don't.
> 
> I think there are different levels here. If we keep the core reasonably
> small, we can more reasonably say things like "must be ported to systemd
> timer units" for that subset.
> 
> Also, I hear from a lot of Fedora developers who strongly believe that even
> if we allow messier software, improving the packaging quality is still
> important. The idea of calling this "staging" or "incubating" implies that
> packages at this level can be "in" easily but are expected to be polished
> over time, with the aim of graduating to the fully-FPG-compliant level.
> 
> (At the DevConf panel discussion, someone (Stephen, I think) made the
> suggestion that packages that aren't aiming for this could comfortably live
> in COPRs forever. Or, we *could* have both fedora-incubator and fedora-ugly,
> but I don't know how much value that gives.)
> 

I think we need to support the use-cases of both Incubator (packages here
are destined for Commons once the packages are polished up) and Ugly (these
packages are usful for Fedora End Users to have access to but the upstream
and downstream packaging is such that we'd never want to push them to people
features as is).  We might also want to satisfy a third use case that's
"This package is too ugly for Commons and no one wants to make it prettier
but Product X desperately wants to ship it" but I think that could be its
own topic.

I would like to avoid having two repositories for these two use cases if one
repository would fit the bill.  Additional repositories are not without cost
for releng and infrastructure and packagers so I think it would be good to
think about whether we can meet all needs within one repository before
thinking about making two.

I think the top things that people want to shortcut in the packaging
guidelines are about how your package fits in with the other packages in the
distribution.

* Bundled libraries are essentially a disagreement between an application
  package and a library package on what the upstream library's code should do
  (One of hte things the FPC asks about bundling libraries is whether the
  Fedora package could/would carry a patch to the library to support the
  needed additions).
* Conflicts of all sorts: filesystem, package naming, multiple versions that
  are not parallel installable
* alternate systems that do similar things: systemd, SysVinit, minit, etc;
  rsyslog, syslog-ng, systemd journal
* Different compilations of the same thing: lua, libev, and liblzma all
  create -source packages so that dependencies can compile the libraries in
  particular ways without actually bundling.
* Combinations of the above two: compiling with clang vs gcc, compiling
  against dietlibc vs glibc,

There's also fesco policy that's largely about the relation between packages
that people want to circumvent:
* New, incompatible library versions for some software while other software
  needs the old versions.
* Legal addons to the kernel
* Things that indirectly point to non-free software (which we'd probably
  allow into the main repositories if the Board voted to allow it)

I think that many of these things get left out in the cold if we're
specifying that the new repo doesn't support conflicts between the new repo
and the Fedora Commons repo, the Core (once we figure out how to distribute
that), or each other.  On the other hand, the inter-package conflicts are
one of the major drawbacks that you see with the idea of people running copr
repos so...

Perhaps we need a repository where we don't have rpm Conflicts and we don't
have filesystem Conflicts but we have some specified method of handling
parallel versions.  SCLs could fit here (and we do need a repository for
non-fedora SCLs to be available for fedora users... so that could kill two
birds with one stone) or other, similar technologies that are essentially
bundling of requirements at the distribution level instead of bundling at
the upstream level.

We would definitely want people to know that we weren't promising security,
timely updates, etc... (indeed, we might want to tell people to expect
insecure code, packages that would languish, etc...) as there would be
a much higher duplication of code in this repo and likely more packages
which included versions that were no longer accepted upstream.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/env-and-stacks/attachments/20140211/4cdcb6b3/attachment.sig>