From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1OXsNB-000560-1I for garchives@archives.gentoo.org; Sun, 11 Jul 2010 08:58:53 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C7F9AE0B27; Sun, 11 Jul 2010 08:58:49 +0000 (UTC) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.213.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 32188E0A76 for ; Sun, 11 Jul 2010 08:58:36 +0000 (UTC) Received: by yxm34 with SMTP id 34so1074588yxm.40 for ; Sun, 11 Jul 2010 01:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=698IhcwLtt6dNrT5MYrIUXYxov46J7+722AbY2tQjAg=; b=Yw40rEw3tkPNujCzzrQG0N8MGH0OKRNEQ5fp7IE9WYs3Z8/uBLFHCWK7kX/fAdn8uv VBSbLREQ+YiSM3pGxRIqZyS24tnanomFogNccPcJj9oMbwt+kQwNE8dWX4a/zXT3uZdp OK5HNH4t//MExpm1U79KCzyVVspb6ZpP5NMJU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=i4a/DglJ0h4x5Rktoy47KYCleG3y2OF1Fn7YH3341fmHFouStBIsqsZJmgsEqSwftV b1hE9XDoq528N2V58hwqA8r9m7pWcsKfS7eVVjk6g1c1DiqupqcyNUn19EzIoVulq7HR GYBUYw+3V9jdrvWsKImh5PYee1fBOlHFiLO6g= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.150.97.4 with SMTP id u4mr4261507ybb.97.1278838715217; Sun, 11 Jul 2010 01:58:35 -0700 (PDT) Sender: nirbheek.chauhan@gmail.com Received: by 10.151.10.11 with HTTP; Sun, 11 Jul 2010 01:58:35 -0700 (PDT) In-Reply-To: <20100711070902.GA30793@nibiru.local> References: <20100707225651.GA8832@nibiru.local> <4C35099C.2010202@gentoo.org> <20100710161343.GC15161@nibiru.local> <1278831707.1752.17.camel@localhost> <20100711070902.GA30793@nibiru.local> Date: Sun, 11 Jul 2010 14:28:35 +0530 X-Google-Sender-Auth: sno3jQtkSy3KtIhY1IuJPV3-pHk Message-ID: Subject: Re: [gentoo-dev] [bugzilla-daemon@gentoo.org: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs] From: Nirbheek Chauhan To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 6c3645f3-fe41-42d7-ade1-66b599ff3dfa X-Archives-Hash: 3dbf1eac6610ca695e682fe7b3f6a869 On Sun, Jul 11, 2010 at 12:39 PM, Enrico 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