[FINETUNING] Learn E17 packaging discussion

[ghostbunny]

further note:

the old spec files in the repo have a number in front of the pclos-enia... for all e17 packages. don't remove this they give the build order.

[sling-shot]

[ghostbunny]
OK. I understand the naming convention then.
I would also use the old .spec as base from here onwards.

Could you please explain this line :
%configure2_5x --disable-cpu-sse --disable-static

Why %configure2_5x
Why --disable-cpu-sse
Why --disable-static
They are not mentioned in the standard .spec file bundled with the source.

[ghostbunny]

Why %configure2_5x

why not if i remember correctly this launches some special things for libraries but take look into the rpm macro files and search what this does exactly maybe a other packager could enlighten us also ^^

Why --disable-cpu-sse

cpu sse was/is a special cpu function don't know for what i think google will help maybe it was broken and so disabled in the older version or so, you can try to remove it.

Why --disable-static

pclos is a distro which uses primarily shared libs for linking so we don't need the static ones which are disabled with this command. But sometimes they are built also. than you can delete them. they end with .a or .la.

[JohnW_57]

Just a warning for packaging "eet".

eet is used as dependency for KDE (also eina).

Removing eet gives this:

eet zal verwijderd worden (gonna be removed)
kde-plasma-addons zal verwijderd worden
kde-smooth-tasks zal verwijderd worden
kde-workspace zal verwijderd worden
kde4-config zal verwijderd worden
kde4-windeco-oxygen-transparent zal verwijderd worden

But lot of succes with packaging E17  

JohnW

[Agent Smith]

Hey Slingshot,

I guess you have already figured this out by now, but doesn't hurt to tell again: If you are building the new E-17, you can't do it in an old E-17 environment, or else, the packages (that must be installed, in the right order) will bork your installation (or give errors, like the ones you are getting).
You should pick other DE (LXDE, Gnome, KDE, what ever) to build the packages. Or build them in a VM.

Ok ?

[sling-shot]

Thanks. I am in it as a learning experiment right now. If things work out well, good for everyone.

It was actually a KDE MiniMe environment to start with (luckily a virtual one right now). The older package came into picture only when I went to build the second one and it wanted the first as a dependency. I had only installed the main package and not the devel one. And hence it was not recognised. It took me sometime to figure out that when the requirement is 'eina', it actually is asking for 'eina-devel'

If you have any other information, please share. I would mostly be all at sea because I have jumped into water in order to learn swimming

I would not be near my computer for another week almost. So further progress would only be seen later.

[Agent Smith]

Oh,
I was considering to package the new E-17, but when I saw the number of packages (and the packaging instructions), they scared me a lot.
Too much work for one man to accomplish. Or, he works only in packaging E-17 and suspends everything else. For a good time.
 

Best regards,

[Agent Smith]

Btw, Sling Shot, if you want, we can pool our efforts and try to make the packaging of this new version of E-17.
One man only will be a heck of a job, if we tag team, perhaps we can do it better and faster.
Ok ?

What do you think ?

Best regards,

[ghostbunny]

i also would help if you wish guys.

[sling-shot]

I would be glad to work with you. Thanks.

- The problem with me is that I tend to lack focus and keep doing multiple things simultaneously. Result ends up being nothing done properly.
- I also am not able to have any guaranteed free time.
- My knowledge is near zero even now and my method of learning (do something, test, modify, test, do something, test, modify test, repeat until correct). I do not read and learn. That will surely irritate you if I join your team [You would clearly understand this as you have seen my posts for help while learning to package under individual package heads starting from FirstEffort]

[Agent Smith]
How could we split the work? Particularly since Enlightenment recommends that each package be built in order and mostly might need the previously built package to be installed before building the next?

Right now all I can do is mechanically build the individual packages but I cannot understand the tuning needed to make them a functional desktop.

Shall I, with guidance, continue to build them one by one until completion, then present them through DropBox for integration by you and ghostbunny?

[ghostbunny]

i also learn by doing mostly

Shall I, with guidance, continue to build them one by one until completion, then present them through DropBox for integration by you and ghostbunny?

like the graphics on http://www.enlightenment.org/ shows we could share some packaging tasks when we have ecore there are at least 6 packages which depends on it.

all other e17 apps which depends on this libraries have to be checked out from the e17 project svn repository. i haven't found a page with tarball releases of this programs e.g. eweather.

[sling-shot]

I will change my own .spec file naming convention to thus:
x-slingshot-packagename-packageversion-specversion.spec
This allows me to have :
1. Have all the Enlightenment .specs in the serial order suggested by Enlightenment.
2. Have side-by-side my .spec and the official PCLinuxOS .spec for comparison.
3. Have multiple versions of my .spec as it evolves and allows me to roll-back to a previous version as needed.

What do you say?

Only catch in this will be that the person who will submit the final working .src.rpm to Neal will have to rename the .spec to official PCLinuxOS naming convention.

[sling-shot]

The third package of Enlightenment series has a mention of a package called HarfBuzz but it is not in our repository. I have made a preliminary build of that package.
What do with those packages which may/may not be absolutely necessary?

[sling-shot]

Why does the official .spec use
./autogen.sh
while the included .spec file of the package does not have this line?

What is its purpose?

[ghostbunny]

Why does the official .spec use
./autogen.sh
while the included .spec file of the package does not have this line?

What is its purpose?

the previous versions are all subversion check outs which do not provide the file structure you find in a tarball release.
e.g. look here http://trac.enlightenment.org/e/browser/trunk/elementary there is no configure file in this svn version just configure.ac

to generate the configure file it is necessary to launch autogen.sh

this line has to be commented probably if you build from the tarball

The third package of Enlightenment series has a mention of a package called HarfBuzz but it is not in our repository. I have made a preliminary build of that package.
What do with those packages which may/may not be absolutely necessary?

harfbuzz (If you want complex text shaping support)

just if you want, do we want/need?

I will change my own .spec file naming convention to thus:
x-slingshot-packagename-packageversion-specversion.spec
This allows me to have :
1. Have all the Enlightenment .specs in the serial order suggested by Enlightenment.
2. Have side-by-side my .spec and the official PCLinuxOS .spec for comparison.
3. Have multiple versions of my .spec as it evolves and allows me to roll-back to a previous version as needed.

What do you say?

Only catch in this will be that the person who will submit the final working .src.rpm to Neal will have to rename the .spec to official PCLinuxOS naming convention.

mh i don't know the exact number of the e17 packages but like you said there will be extra work to rename the specs for the final submission. i would not do this. you also could create local copies for yourself.