From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DMARC_MISSING, MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=4.0.0 Received: from kumiko.freeside.com (kumiko.freeside.com [199.33.241.1]) by chiba.3jane.net (Postfix) with ESMTP id 055802000157 for ; Fri, 12 Apr 2002 08:22:52 -0500 (CDT) Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by kumiko.freeside.com (8.11.6/8.11.6) with ESMTP id g3CAUsY61404 for ; Fri, 12 Apr 2002 05:30:55 -0500 (CDT) (envelope-from terjekv@nommo.uio.no) Received: from nommo.uio.no ([129.240.222.179]) by pat.uio.no with esmtp (Exim 2.12 #7) id 16vyGo-0004Gd-00 for gentoo-dev@gentoo.org; Fri, 12 Apr 2002 12:27:06 +0200 Received: from terjekv by nommo.uio.no with local (Exim 2.12 #1) id 16vyGj-00052i-00 for gentoo-dev@gentoo.org; Fri, 12 Apr 2002 12:27:01 +0200 To: gentoo-dev@gentoo.org Subject: Re: [gentoo-dev] ebuild policy questions. References: <1018562103.2980.1.camel@silica.localmosci> X-URL: http://terje.kvernes.no/ Organization: do you Gentoo? From: Terje Kvernes Date: 12 Apr 2002 12:27:01 +0200 In-Reply-To: <1018562103.2980.1.camel@silica.localmosci> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: 25b19c07-82ce-46ef-8399-7e56e46903d0 X-Archives-Hash: 03d726726fd890e09627d832682f36c7 "Tod M. Neidt" writes: > Hi! arp. :) > I'll take a stab at this and offer some suggestions. Please note > that these comments should not be considered "policy" and it should > be a given that any drobbins pronouncements on this issue > automatically trump mine. okidoki. thanks. > On Thu, 2002-04-11 at 15:30, Terje Kvernes wrote: > > [ ... ] > > > first off, if I see an ebuild that is out of date, do I contact > > the author of the out-of-date ebuild or do I submit a new one? so > > far I've thought "if the old one is _really_ out of date, I'll > > submit a new ebuild, if it's a week or two since the new version > > came out, I'll take it with the author." the real question is > > probably how "possessive" authors are / are supposed to be with > > regards to their ebuilds. is there any set policy on this? > > I would suggest submitting any changes to bugzilla and notifying the > "author" or "maintainer" by cc'ing them on the bug submission if > they don't happen to be the automatic assignee. good point. > Note that you should probably check the Changelog for that > particular package to see who has been actively maintaining the > ebuild, as this developer is not necessarily the same as the one > listed in the ebuild header. that much I figured on my own, but it is none the less good advice. besides, this happens to be stored in the list archives, so additional information is always a good thing[tm]. > If the ebuild update just requires a copy of the ebuild to the new > revision number, it is not necessary to attach the ebuild. A > comment stating that "version 1.2 of foo has been released,a simple > copy of foo-1.1-r3.ebuild to foo-1.2.ebuild works" or something to > that effect is sufficient. oki. > If the ebuild update requires changes to the ebuild, I find it > convenient when people attach a diff between the original and > updated ebuild instead of the entire updated ebuild as this makes it > very easy to see the changes that are proposed. good point again. I wasn't all that comfortable with creating diffs until I wrote the xgammon ebuild yesterday. then I didn't have much choice. :) > > second, and a bit more tricky. I thought I'd make an xgammon > > ebuild. all fine and dandy, but there are a few patches (from > > RedHat) to xgammon which are nice to have (they fix minor bugs -- > > void main -> int main and a few other things). what to do? if I > > include the patches, how do I link to them? or do I just put them > > in the "files"-directory with the ebuild? > > For patch files (especially large ones) include the URL to the patch > in the SRC_URI string so that it will be downloaded with the source > tarball and stored in ${DISTDIR}, i.e. /usr/portage/distfiles by > default. See the dev-lang/python ebuild for a good example (In fact > the python ebuild is a good example for a variety ebuild techniques > for uncommon situations) hm. the patches I need total about 1K, and I _could_ host the patches via http. > If the patch files are small (working definition of small not much > larger than the ebuild itself), placing them in the files directory > is ok, but the former method is prefereable. okay, I'll try getting them to work via http. . okay, done. :) now just to check that things work and submit. should I attach the patches as well? > Contributions are always welcome and appreciated. considering how much the Gentoo community (well, the linux community in general actually) has given me I feel bad for not contributing more than I do. :/ > Hope that helps, always, thank you. -- Terje