On Fri, 5 Oct 2007 15:39:46 +0200 Albin Tonnerre <[EMAIL PROTECTED]> babbled:
> On Fri, Oct 05, 2007 at 11:28:28AM +0900, Carsten Haitzler wrote : > > On Sun, 2 Sep 2007 21:16:31 +0200 Albin Tonnerre <[EMAIL PROTECTED]> > > babbled: > > > > > On Sat, Aug 25, 2007 at 12:43:28PM +0900, Carsten Haitzler wrote : > > > > On Tue, 14 Aug 2007 16:50:09 -0300 "Gustavo Sverzut Barbieri" > > > > <[EMAIL PROTECTED]> babbled: > > > > > > > > > Hi, > > > > > > > > > > I want to package e17 for maemo the "proper way" (so far I'm creating > > > > > .deb with tar + ar and a custom shell script), but I'd like to disable > > > > > build of some subpackages, like every evas engine other than > > > > > software-x11 and software-16-x11 (which is not built right now). > > > > > > > > > > Maybe we could have a way to select which packages to generate? > > > > > > > > > > PS: May I add software-16-x11 to the list of build modules? > > > > > > > > sure - though really the debian or rpm packaging info is intended as a > > > > SAMPLE for packagers to build off - to show them how best to package and > > > > then add all the little bits their distribution demands or needs. it's a > > > > starting point rather than an end point - IMHO. :) > > > > > > > > > > About that ....Now that there is a team dedicated to package > > > enlightenment for debian, is there really a point maintaining the debian/ > > > dir *in* E's CVS ? I mean, this is generally seen as a bad practice in > > > debian to have debian/ dirs > > > > bad in debian - not bad for us. basically it is meant to be: > > > > 1. an easy way for upstream to package themselves if they want. > > 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 no - we wouldnt build packages every time we compile something and run it - but we may use it for weekly or monthly snapshots etc. > > 2. a template/example of how to package for packagers (how to plit things > > up, what files to include or not include in packages (eg module .la and .a > > files are pointless so don't keep them), other special things (some > > binaries e produces are suid-root and so the packages need to reflect that, > > if they don't things won't work like cpufreq, system reboot/shutdown etc.). > > > > you, as a packager are free to strip this out or follow it, but it is your > > distribution, but this is our source - and we are giving a helping hand to > > you guys in many ways this way as per above. > > > > 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. > 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 i believe it would hurt. there are other distributions about. we provide an "official" example of packaging. if your distro policies demand it not be there then you need to remove it yourselves. > > > provided with upstream sources. As long as users now where the can grab > > > the debian tree, wouldn't it possible to maintain it outside cvs ? > > > Cheers > > > > in my experience, packagers of e have generally done a poor job (no offense > > intended). they have modified things, broken things, and left things in an > > inconsistent state (eg modifying e16 defaults but never updating the runtime > > help docs for starters). there have been other numerous mis-packagings of > > libs like evas which is modular, but keeping modules in the same package > > instead of splitting them out as separate packages that should be depended > > on not by evas, but by apps if they require certain engines/loaders etc. > > I can't remember having ever distributed evas as a single package since I > started maintaining the ubuntu packaging a year back. older deb and rpm packages did. until we actually updated and fixed al the in-cvs packaging info. > 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. 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 ?) yes - it does seem amazing. i definitely don't want it out of cvs - but i'd be willing to compromise and not have it disted into the tarballs. so when we ship release tarballs (do a make dist) you wont have it in the tarball. nwe will keep the .spec file for rpm's and no rpm distro maintainers have no policies regarding this and are happy as-is as best i know. > Regards > > > > > > Albin Tonnerre > > > > > > > > -- > > > > > Gustavo Sverzut Barbieri > > > > > -------------------------------------- > > > > > Jabber: [EMAIL PROTECTED] > > > > > MSN: [EMAIL PROTECTED] > > > > > ICQ#: 17249123 > > > > > Skype: gsbarbieri > > > > > Mobile: +55 (81) 9927 0010 > > > > > > > > > > ------------------------------------------------------------------------- > > > > > 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 > > > > > > -- > > > Albin Tonnerre, aka Lutin > > > - Search a little longer, travel a little further > > > > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] > > 裸好多 > > Tokyo, Japan (東京 日本) > > -- > Albin Tonnerre, aka Lutin > - Search a little longer, travel a little further > -- ------------- 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
