Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Nirbheek Chauhan <nirbheek@g.o>
Subject: Re: [bugzilla-daemon@g.o: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]
Date: Sun, 11 Jul 2010 14:28:35 +0530
On Sun, Jul 11, 2010 at 12:39 PM, Enrico Weigelt <weigelt@...> wrote:
> The point is: I have to maintain lots of packages for different distros,
> as well as for my own build system. I cannot do this manually for each
> single distro, so I prefer doing _generic_ fixes and let the distro
> buildfiles only do the plain standard build process
> (eg. ./autogen.sh && ./configure && make && make install).
>
>

I know the problem you are trying to solve is quite important.
Various distros apply their own patches ontop of products, which often
leads to duplicated work, regressions and even security bugs, all
because there aren't enough eyeballs. We need a solution for this.

Now, in a perfect world, we wouldn't need this, since upstream would
quickly merge bugfixes, and patches would only have to be kept till
the next release. However, we have seen that upstreams are often
stubborn, or don't agree with us. Some distros (like Gentoo,
Slackware, ArchLinux) prefer to keep patching to a *minimum*. A lot of
teams have a policy of "upstream first" before adding a patch to the
tree (unless it is small/hackish/temporary, very distro specific, and
has no place upstream).

On the other hand, Debian/Ubuntu like to carry a thousand lines of
patches on top of packages like Firefox, and Ubuntu likes to diverge
/majorly/ from upstream releases. Fedora also suffers from this
problem of not agreeing with upstream quite often[1]; but w.r.t.
GNOME/Xorg/udev they *are* upstream, so the effect is lessened. IIRC,
OpenSuse has had a good policy of upstreaming often.


If I understand your system correctly, you essentially maintain clones
of upstream repos, with all the various distro patches applied on top,
and release tarballs as well. I don't see how these various distros
can be made to agree with each other and I certainly can't see them
using a common tarball source. On a technical level, it's got serious
security, trust, and redundancy problems. It is extremely important
that distros collaborate in some form when it comes to patches that
*can* be shared, but the solution you have devised is fundamentally
flawed.

I can say today with extreme confidence that no major distros will use
your repositories and your tarballs, or work with you to collaborate
with each other. There is simply very little incentive to change the
way we work.

A practical solution to the problem of patch sharing is to have a
website with a search interface for upstream source tarballs, which
can display all the patches that various distros apply, as well as a
download link for the patchsets (hotlinked to the distro files where
possible). Currently, it is extremely painful to find out what patches
each distro has applied on top of a give source package, and as a
result, collaboration is minimal.

As the popularity of such a website increases (you'll need to
advertise it!), you'll find that at least the divergent/community
supported distros (debian/slackware/arch/gentoo/opensolaris) will
start using it heavily and sharing of patches (wherever feasible) will
occur automatically.

Distro packagers are much more comfortable with downloading patchsets
from a foreign source than complete tarballs. They already have a
trust-relationship with upstream, and they can verify the integrity of
a patchset much easier than an arbitrary tarball.

I know you have spent a lot of time on this already, but please
understand it from where we stand. We're short on manpower, and
there's no real benefits of shifting our tarball source; OTOH there
are major disadvantages too unless we pitch in with manpower
ourselves. And honestly speaking, that manpower is better spent making
stuff work locally.

Please consider the "patch-website" idea above. We definitely need
someone to code it up, gather the source-package to distro patches
mappings,
and advertise it. And this is a solution that can easily be created
and maintained by one man alone, and will solve the problem of distro
collaboration as well!

Best,

1. https://bugs.gentoo.org/291328

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team


Replies:
Re: [bugzilla-daemon@g.o: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]
-- Enrico Weigelt
References:
[bugzilla-daemon@g.o: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]
-- Enrico Weigelt
Re: [bugzilla-daemon@g.o: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]
-- Samuli Suominen
Re: [bugzilla-daemon@g.o: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]
-- Enrico Weigelt
Re: [bugzilla-daemon@g.o: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]
-- Jacob Godserv
Re: [bugzilla-daemon@g.o: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]
-- Hans de Graaff
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: [bugzilla-daemon@g.o: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]
Next by thread:
Re: [bugzilla-daemon@g.o: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]
Previous by date:
Re: [bugzilla-daemon@g.o: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]
Next by date:
Re: [bugzilla-daemon@g.o: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.