Re: [E-devel] Selective build of modules for evas/ecore

[Albin T. <alb...@gm...>]

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