[FINETUNING] Learn E17 packaging discussion

[sling-shot]

A preliminary build is available for testing
SRPMS http://www.pclinuxos.com/forum/index.php/topic,112517.msg970164.html#msg970164

RPMS for installation and testing http://www.pclinuxos.com/forum/index.php/topic,112517.msg971412.html#msg971412
------------------------------------------------------------

Code: [Select]

E: Package eina-1.7.4-1slingshot2013.i586.rpm is a virtual package with no good providers.I am getting this error while trying to install my self-built E17 first package.

I had downloaded the first package of E17 from http://www.enlightenment.org and checked. It showed a file called eina.spec inside and that looked attractive to learn.

I had to add doxygen to BuildRequires. Otherwise the build completed without any errors.

There are many warnings in the log file created.
1. configure: WARNING: you should use --build, --host, --target
2. config.status: WARNING:  'eina.pc.in' seems to ignore the --datarootdir setting
3. WARNING: `aclocal-1.11' is missing on your system.  You should only need it if
         you modified `acinclude.m4' or `configure.ac'.  You might want
         to install the `Automake' and `Perl' packages.  Grab them from
         any GNU archive site.
4. WARNING: `automake-1.11' is missing on your system.  You should only need it if
         you modified `Makefile.am', `acinclude.m4' or `configure.ac'.
         You might want to install the `Automake' and `Perl' packages.
         Grab them from any GNU archive site.
5. aclocal.m4:17: warning: this file was generated for autoconf 2.68.
6. sh: svnversion: command not found
7. libtool: install: warning: remember to run `libtool --finish /usr/lib'

NOTES:
- Automake 1.12.4, automake1.7 are installed while automake1.4 is available in the repo.
- Aclocal may be available in libguile-devel

<snip>outdated links removed</snip>

[pinoc]

is a virtual package with no good providers.

this message may appear if you try to install something which is already installed but the installed version was built differently. In the sense that the version you want to install has the same package name and version number like the existing one in the system but your version was built with different libraries.  Make sure your version properly upgrades the existing installed version of the conflicting application.

[sling-shot]

The existing eina is versioned 20110530-1pclos while the one I compiled is versioned 1.7.5.
Previous one is from our repo of E16 release while this is from the newer E17 release.

Also trying to uninstall the previous versions took out kde-smooth-tasks and kde-plasma-addons and kde-config-legacy

Will adding Obsoletes:   eina <= 20110530 to the spec work?

[sling-shot]

Other than this, does my .SPEC file appear OK?

[pinoc]

Hi sling-shot,

sorry I can not look at this now because I have my head overfull with KDE things. Maybe someone else can help out here?
good luck anyway. 
-p.

[daniel]

How you define the new version, and how called the last version?

[sling-shot]

My current .SPEC top section :

Code: [Select]

Name: eina
Version: 1.7.4
Release: %mkrel 1
Summary: Eina is a library providing data structure utilities for EFL
License: LGPL 2.1
Group: System Environment/Libraries
Source: %{name}-%{version}.tar.xz
URL: http://enlightenment.org/
BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot
BuildRequires: doxygen

Older version in the repository :

Code: [Select]

%define major 1
%define libname %mklibname %{name} %major
%define libnamedev %mklibname %{name} -d

Summary: Data Type Library
Name: eina
Version: 20110530
Release: %mkrel 1
License: BSD
Group: Graphical desktop/Enlightenment
Source: %{name}-%{version}.tar.xz
URL: http://www.enlightenment.org/
BuildRoot:     %{_tmppath}/%{name}-buildroot
# Common
BuildRequires: jpeg-devel
BuildRequires: zlib-devel
BuildRequires: gnutls-devel
BuildRequires: openssl-devel
BuildRequires: doxygen
Obsoletes: libeina0

I wonder if the very high version number given to the previous package is causing this?
Or is my package actually broken in some way?

I am really thinking about those WARNINGS.

[daniel]

which version will be higher ?

I thinking the older, but may i mess here.
The same question get i by update mplayer...
Break the system, or define a fake version...

Code: [Select]

%define realversion 1.1
%define version 4.5.2
Only an solution....

[sling-shot]

How should I modify other parts of the .SPEC? Keep them the same?

Code: [Select]

%define realversion 1.7.4
%define version 20130120
Name: eina
Version: 1.7.4
Release: %mkrel 1
Summary: Eina is a library providing data structure utilities for EFL
License: LGPL 2.1
Group: System Environment/Libraries
Source: %{name}-%{version}.tar.xz
URL: http://enlightenment.org/
BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot
BuildRequires: doxygen


[daniel]

How should I modify other parts of the .SPEC? Keep them the same?

Code: [Select]

%define realversion 1.7.4
%define version 20130120
Name: eina
Version: 1.7.4
Release: %mkrel 1
Summary: Eina is a library providing data structure utilities for EFL
License: LGPL 2.1
Group: System Environment/Libraries
Source: %{name}-%{version}.tar.xz
URL: http://enlightenment.org/
BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot
BuildRequires: doxygen


Type for Version: 1.7.4
Version: %{version}
And by Source: %{name}-%{version}.tar.xz
Source: %{name}-%{realversion}.tar.xz

The same by
%prep section
%setup -q -n %{name}-%{realversion}

[ghostbunny]

How should I modify other parts of the .SPEC? Keep them the same?

Code: [Select]

%define realversion 1.7.4
%define version 20130120
Name: eina
Version: 1.7.4
Release: %mkrel 1
Summary: Eina is a library providing data structure utilities for EFL
License: LGPL 2.1
Group: System Environment/Libraries
Source: %{name}-%{version}.tar.xz
URL: http://enlightenment.org/
BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot
BuildRequires: doxygen


Type for Version: 1.7.4
Version: %{version}
And by Source: %{name}-%{version}.tar.xz
Source: %{name}-%{realversion}.tar.xz

The same by
%prep section
%setup -q -n %{name}-%{realversion}

Hi,
i gave e17 a shot some time ago. you always have to take the release date as version because of all previous packages.

the version 1.7.4 will never be installed over e.g. 20100901 because 20100901 is really bigger than 1.7.4. so your version have to be 20130120.

try the following

Code: [Select]

%define realversion 1.7.4
%define version 20130120
Name: eina
Version: %{version}
Release: %mkrel 1
Summary: Eina is a library providing data structure utilities for EFL
License: LGPL 2.1
Group: System Environment/Libraries
Source: %{name}-%{version}.tar.xz
URL: http://enlightenment.org/
BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot
BuildRequires: doxygen

%prep and %setup like daniel described.

btw. i wouldn't take the date you downloaded the tarball if you take the tarball version. use the release date of the tarball.

the other option is to check out the source code from the e17 git or subversion repo, i can't remember what it was.
than you have to create your own tarball which gets the date of the day you checked it out as version number.

Will adding Obsoletes:   eina <= 20110530 to the spec work?

this wouldn't work because your version (1.7.4) won't be recognized as an update.

[sling-shot]

Thank you Daniel & ghostbunny . I could install the new eina this way.

Wonder, how to break this cycle?

[ghostbunny]
Why did you not pursue E17?

[ghostbunny]

[ghostbunny]
Why did you not pursue E17?

after packaging nearly everything of e17 i've done a test and i got an x error for the core library and i didn't get it solved.

Wonder, how to break this cycle?

that's nearly impossible. there is just one way i know and i can't recommend it. it is also not recommended by the rpm devs.

there is a rpm macro called %serial or so, check the rpm documentation for further information, it gets a number e.g.

Code: [Select]

%serial 1

which will tell the package management that's the first version of the package. the disadvantage is you have to increase this on every update and this means every update including rebuilds against new library versions or so. if you forget to increase it your package won't be recognized as update.

so please don't use it

[sling-shot]

Will it not be better to remove the old packages from the repo, then introduce the new packages with the proper version numbers and then tell those who want to upgrade from older versions to go for a re-install?

[ghostbunny]

that will mean you have to tell all users which currently have an installed e17 to uninstall e17 because you can't reinstall you deleted the package from the repo like you said.

so you have to uninstall it completely and than install it again. i think the user won't like that. what's the problem to use the old date format?

btw. please use the old spec file as base. you can edit this file and write the changes in the %changelog