From: Gustavo S. B. <bar...@gm...> - 2007-08-14 19:50:12
|
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? -- Gustavo Sverzut Barbieri -------------------------------------- Jabber: bar...@gm... MSN: bar...@gm... ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 |
From: Gustavo S. B. <bar...@gm...> - 2007-08-14 21:21:07
|
On 8/14/07, Gustavo Sverzut Barbieri <bar...@gm...> wrote: > 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? Just to make this clear why: the embedded system I work with (maemo) don't provide some libraries, like libungif, librsvg, opengl and some others. Also, builds can take lots of time, so selecting what to compile can save me much time. We did this "selective build" here by having debian/control.in, generating debian/control with some comands, maybe debian/rules or some other script. -- Gustavo Sverzut Barbieri -------------------------------------- Jabber: bar...@gm... MSN: bar...@gm... ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 |
From: Carsten H. (T. R. <ra...@ra...> - 2007-08-25 03:49:21
|
On Tue, 14 Aug 2007 16:50:09 -0300 "Gustavo Sverzut Barbieri" <bar...@gm...> 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. :) > -- > Gustavo Sverzut Barbieri > -------------------------------------- > Jabber: bar...@gm... > MSN: bar...@gm... > 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 > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... 裸好多 Tokyo, Japan (東京 日本) |
From: Albin T. <lut...@gm...> - 2007-09-02 19:16:35
|
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" > <bar...@gm...> babbled: >=20 > > Hi, > >=20 > > 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). > >=20 > > Maybe we could have a way to select which packages to generate? > >=20 > > PS: May I add software-16-x11 to the list of build modules? >=20 > sure - though really the debian or rpm packaging info is intended as a S= AMPLE > for packagers to build off - to show them how best to package and then ad= d all > the little bits their distribution demands or needs. it's a starting point > rather than an end point - IMHO. :) >=20 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/ di= rs 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 Albin Tonnerre > > --=20 > > Gustavo Sverzut Barbieri > > -------------------------------------- > > Jabber: bar...@gm... > > MSN: bar...@gm... > > ICQ#: 17249123 > > Skype: gsbarbieri > > Mobile: +55 (81) 9927 0010 > >=20 > > -----------------------------------------------------------------------= -- > > 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 > > enl...@li... > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >=20 >=20 >=20 > --=20 > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ra...@ra... > =E8=A3=B8=E5=A5=BD=E5=A4=9A > Tokyo, Japan (=E6=9D=B1=E4=BA=AC =E6=97=A5=E6=9C=AC) >=20 > ------------------------------------------------------------------------- > 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 > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel --=20 Albin Tonnerre, aka Lutin - Search a little longer, travel a little further |
From: Gustavo S. B. <bar...@gm...> - 2007-09-02 23:03:09
|
On 9/2/07, Albin Tonnerre <lut...@gm...> wrote: > 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" > > <bar...@gm...> 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 > 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 ? Ed (nokia guy) and myself are maintaining maemo-efl packages at https://garage.maemo.org/svn/maemo-efl -- Gustavo Sverzut Barbieri -------------------------------------- Jabber: bar...@gm... MSN: bar...@gm... ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 |
From: Carsten H. (T. R. <ra...@ra...> - 2007-10-05 03:09:06
|
On Sun, 2 Sep 2007 21:16:31 +0200 Albin Tonnerre <lut...@gm...> 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" > > <bar...@gm...> 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. 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. > 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. > Albin Tonnerre > > > > -- > > > Gustavo Sverzut Barbieri > > > -------------------------------------- > > > Jabber: bar...@gm... > > > MSN: bar...@gm... > > > 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 > > > enl...@li... > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ra...@ra... > > 裸好多 > > 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 > > enl...@li... > > 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) ra...@ra... 裸好多 Tokyo, Japan (東京 日本) |
From: Albin T. <alb...@gm...> - 2007-10-05 13:39:52
|
On Fri, Oct 05, 2007 at 11:28:28AM +0900, Carsten Haitzler wrote : > On Sun, 2 Sep 2007 21:16:31 +0200 Albin Tonnerre <lut...@gm...> ba= bbled: >=20 > > 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" > > > <bar...@gm...> babbled: > > >=20 > > > > Hi, > > > >=20 > > > > I want to package e17 for maemo the "proper way" (so far I'm creati= ng > > > > .deb with tar + ar and a custom shell script), but I'd like to disa= ble > > > > build of some subpackages, like every evas engine other than > > > > software-x11 and software-16-x11 (which is not built right now). > > > >=20 > > > > Maybe we could have a way to select which packages to generate? > > > >=20 > > > > PS: May I add software-16-x11 to the list of build modules? > > >=20 > > > 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. :) > > >=20 > >=20 > > About that ....Now that there is a team dedicated to package enlightenm= ent for > > debian, is there really a point maintaining the debian/ dir *in* E's CV= S ? I > > mean, this is generally seen as a bad practice in debian to have debian= / dirs >=20 > bad in debian - not bad for us. basically it is meant to be: >=20 > 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 develo= pping (during the devel process). Just too much overhead to rebuild the package everytime you change something > 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 fi= les > 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.). >=20 > 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 t= o 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 us= ed 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 > > 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 >=20 > in my experience, packagers of e have generally done a poor job (no offen= se > intended). they have modified things, broken things, and left things in an > inconsistent state (eg modifying e16 defaults but never updating the runt= ime > 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 inste= ad 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. While I understand that you experienced issues with various packagers, plea= se keep in mind that it's not because some of them don't things the way they s= hould be that every single packager does. Either ways, a good communication upstream <-> packging will be better than forcing packagers into doing thin= gs, and making their job harder (yes, keeping debian/ in the sources make our j= ob harder. surprising isn't it ?) Regards >=20 > > Albin Tonnerre > >=20 > > > > --=20 > > > > Gustavo Sverzut Barbieri > > > > -------------------------------------- > > > > Jabber: bar...@gm... > > > > MSN: bar...@gm... > > > > ICQ#: 17249123 > > > > Skype: gsbarbieri > > > > Mobile: +55 (81) 9927 0010 > > > >=20 > > > > -------------------------------------------------------------------= ------ > > > > 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 brow= ser. > > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > > _______________________________________________ > > > > enlightenment-devel mailing list > > > > enl...@li... > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > >=20 > > >=20 > > >=20 > > > --=20 > > > ------------- Codito, ergo sum - "I code, therefore I am" -----------= --- > > > The Rasterman (Carsten Haitzler) ra...@ra... > > > =E8=A3=B8=E5=A5=BD=E5=A4=9A > > > Tokyo, Japan (=E6=9D=B1=E4=BA=AC =E6=97=A5=E6=9C=AC) > > >=20 > > > ---------------------------------------------------------------------= ---- > > > 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 browse= r. > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > _______________________________________________ > > > enlightenment-devel mailing list > > > enl...@li... > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >=20 > > --=20 > > Albin Tonnerre, aka Lutin > > - Search a little longer, travel a little further > >=20 >=20 >=20 > --=20 > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ra...@ra... > =E8=A3=B8=E5=A5=BD=E5=A4=9A > Tokyo, Japan (=E6=9D=B1=E4=BA=AC =E6=97=A5=E6=9C=AC) --=20 Albin Tonnerre, aka Lutin - Search a little longer, travel a little further |
From: Carsten H. (T. R. <ra...@ra...> - 2007-10-05 15:45:40
|
On Fri, 5 Oct 2007 15:39:46 +0200 Albin Tonnerre <alb...@gm...> 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 <lut...@gm...> > > 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" > > > > <bar...@gm...> 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: bar...@gm... > > > > > MSN: bar...@gm... > > > > > 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 > > > > > enl...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > > > > > -- > > > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > > > The Rasterman (Carsten Haitzler) ra...@ra... > > > > 裸好多 > > > > 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 > > > > enl...@li... > > > > 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) ra...@ra... > > 裸好多 > > 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) ra...@ra... 裸好多 Tokyo, Japan (東京 日本) |
From: Michael J. <e-...@ka...> - 2007-10-05 16:57:59
|
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. :-) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <me...@ka...> 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 |
From: Carsten H. (T. R. <ra...@ra...> - 2007-10-06 03:40:26
|
On Fri, 5 Oct 2007 09:57:54 -0700 Michael Jennings <e-...@ka...> 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/ <me...@ka...> > 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 > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... 裸好多 Tokyo, Japan (東京 日本) |
From: Albin T. <alb...@gm...> - 2007-11-07 19:22:48
Attachments:
eet_autofoo.diff
|
On Sat, Oct 06, 2007 at 11:44:33AM +0900, Carsten Haitzler wrote : > On Fri, 5 Oct 2007 09:57:54 -0700 Michael Jennings <e-...@ka...> 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). > OK - as it seems to be ok to do it, here's a patch for eet that removes debian/ from make dist. Aditionnaly, it adds the doc/ dir and the gendoc script to make dist, so that you can use the doc even with dist tarballs. If you guys are ok with that one, I'll do the rest of the libs as well. (raster agreed to both changes, in case you'd be wondering). Cheers Albin > > Michael > > > > -- > > Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <me...@ka...> > > 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 > > enl...@li... > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ra...@ra... > 裸好多 > 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 > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Albin Tonnerre, aka Lutin - Search a little longer, travel a little further |
From: Oliver Burnett-H. <ol...@bu...> - 2008-01-30 20:22:47
|
On Sat, Oct 06, 2007 at 12:43:44AM +0900, Carsten Haitzler (The Rasterman) wrote: > On Fri, 5 Oct 2007 15:39:46 +0200 Albin Tonnerre <alb...@gm...> > babbled: > > 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. I'm coming in a tiny bit late to this discussion, but is there any chance that this decision could be reversed? I just downloaded the latest set of snapshot tarballs, and found that the debian/ directories were missing. I do understand why some people don't like having these around if they want to use their control files, but it's a lot easier to delete an unwanted directory than recreate one that's been removed. - olly |
From: Carsten H. (T. R. <ra...@ra...> - 2008-01-30 22:41:25
|
On Wed, 30 Jan 2008 20:18:39 +0000 Oliver Burnett-Hall <ol...@bu...> babbled: > On Sat, Oct 06, 2007 at 12:43:44AM +0900, Carsten Haitzler (The Rasterman) > wrote: > > On Fri, 5 Oct 2007 15:39:46 +0200 Albin Tonnerre <alb...@gm...> > > babbled: > > > 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. > > I'm coming in a tiny bit late to this discussion, but is there any > chance that this decision could be reversed? I just downloaded the > latest set of snapshot tarballs, and found that the debian/ directories > were missing. > > I do understand why some people don't like having these around if they > want to use their control files, but it's a lot easier to delete an > unwanted directory than recreate one that's been removed. ... now ... it's too late :(. you'll need to use cvs then. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |