On Fri, 5 Oct 2007 09:57:54 -0700 Michael Jennings <[EMAIL PROTECTED]> babbled:
> On Friday, 05 October 2007, at 15:39:46 (+0200), > Albin Tonnerre wrote: > > > I'm quite dubious about the fact they'd want to package what they're > > developping (during the devel process). Just too much overhead to > > rebuild the package everytime you change something > > Talk about being hypocritical! You're USING software that's in > development, and you're PACKAGING it too! What is it that gives a > packager some unalienable right to package up development software and > yet somehow fails to give the authors themselves that very same right? > :-P > > > While this might help, they don't necessary belong to the source > > folder. If the packagers want exemples, easy enough for them to > > checkout the trees from a dedicated branch on the cvs. > > The packaging info belongs with the source. That's where it's been > since the very earliest days when bma was doing our Debian packages, > and there's no reason at all for them to not stay. > > > I understand that you want to provide samples etc, but as there are > > already ubuntu and debian repos available, I'm not quite sure that > > it is used by any user at all (of course falko uses them for the > > debian repo, but still), and it's mostly why I believe that moving > > them out of the sources wouldn't hurt much > > If they really bother you that much, "cvs remove" them from your > anonymous checkout or write yourself a little wrapper script. :-) > > > I can't remember having ever distributed evas as a single package > > since I started maintaining the ubuntu packaging a year back. > > Just because you didn't make a particular mistake means neither that > you haven't made others (not accusing...I have no idea...just making > the point) nor that others haven't made them. We make mistakes > ourselves as well. But we (collectively, not me in particular) have > the advantages of having been doing Debian packaging for a very long > time and having made, corrected, and learned from numerous errors in > that time. > > > While I understand that you experienced issues with various > > packagers, please keep in mind that it's not because some of them > > don't things the way they should be that every single packager does. > > The problem is not that some or all packagers do things in any > particular (or right, or wrong) way. That's not the issue. > > The simple fact is this: We keep RPM spec files in CVS because > developers (like me) and others like to be able to build RPM packages > directly from the CVS repository. (It doesn't get much easier than > "./autogen.sh && make distcheck && mzbuild" IMHO.) We keep Debian > packaging directories in the same place for the same reason. We will > continue to do so because it makes things easier and better for us, > the developers. CVS is *our* territory; it does not belong to end > users, packagers, distribution maintainers, or anyone else, as we've > been saying over and over again for years. CVS is a developer tool, > not a user tool. > > > Either ways, a good communication upstream <-> packging will be > > better than forcing packagers into doing things, and making their > > job harder (yes, keeping debian/ in the sources make our job > > harder. surprising isn't it ?) > > Sorry, but if keeping one little directory in CVS makes your job > harder, you're doing it wrong. It's painfully easy to use various > combinations of "rm," "cvs rm," and "$EDITOR" to perform whatever > changes you deem necessary to your local copy of any tree you > choose. :-) i think though it might be that we ALSO add the debian dir and its contents in the dist tarballs - ie make dist and the tarball we ship ships with debian packaging info. personally i think this is a very nice service to early adopters, packagers for all distros to get the source and go "ooh - they did 90% of my work for me already! thanks!" or for us devs to take any snapshot or release and insta-build (i always loved rpm -ta blah-1.0.0.tar.gz if you just throw a .spec file into the tarball). debian doesn't have such an instant-build tool as such as debian "policy" vetos us shipping debian packaging info (yes - debian has a tonne of anal policies. no point in arguing over them), so to do the same you need to botch up a script of your own. so i'm willing to leave the debian/ dir in cvs, but remove it from the dist tarballs (going to keep spec - i know you and many others like and and can instantly use it direct from the tarball). > Michael > > -- > Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> > Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) > ----------------------------------------------------------------------- > "When all is said and all has come undone; when the sun, the moon, > and stars grow dark; before the days of youth are left in vain; > before the dust reclaims its own again. Breathe on me, breathe oh > breath of God. Breathe on me till my heart is new." -- Newsboys > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
