Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On 18 July 2011 22:37, Luc Menut lme...@free.fr wrote:
Le 13/07/2011 12:41, Ahmad Samir a écrit :
On 13 July 2011 12:34, nicolas vigierbo...@mars-attacks.org wrote:
On Wed, 13 Jul 2011, Ahmad Samir wrote:
...
Using pkgconfig provides looks like an optimal option, we could start
now, whenever we touch a spec we change to the pkgconfig provides, and
gradually all the specs will be adapted.
And for the packages that don't have .pc files we add:
Provides: %{name}-devel = %{version}-release
Provides: lib%{name}-devel = %{version}-release
or we could add them to all packages whether they have .pc files or
not, but still always use pkgconfig() provides as BR in our specs.
I think it's better to use %{name}-devel for packages which don't have
pkgconfig files. And keep pkgconfig() provides for packages with .pc
files.
As spturtle said, conformity/consistency is good, i.e. all our
packages should have the same Provides, that's better in the long run,
and less confusing for new (and old too) packagers.
Couldn't we have a macro for this? It would help in consistency, and will
avoid typo.
We could use it like this:
%mkdevelprov %{name} %{version}
regards,
Luc
Good point. There'll be corner cases, but it should work for the
majority of packages.
--
Ahmad Samir
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
Le 13/07/2011 12:41, Ahmad Samir a écrit :
On 13 July 2011 12:34, nicolas vigierbo...@mars-attacks.org wrote:
On Wed, 13 Jul 2011, Ahmad Samir wrote:
...
Using pkgconfig provides looks like an optimal option, we could start
now, whenever we touch a spec we change to the pkgconfig provides, and
gradually all the specs will be adapted.
And for the packages that don't have .pc files we add:
Provides: %{name}-devel = %{version}-release
Provides: lib%{name}-devel = %{version}-release
or we could add them to all packages whether they have .pc files or
not, but still always use pkgconfig() provides as BR in our specs.
I think it's better to use %{name}-devel for packages which don't have
pkgconfig files. And keep pkgconfig() provides for packages with .pc
files.
As spturtle said, conformity/consistency is good, i.e. all our
packages should have the same Provides, that's better in the long run,
and less confusing for new (and old too) packagers.
Couldn't we have a macro for this? It would help in consistency, and
will avoid typo.
We could use it like this:
%mkdevelprov %{name} %{version}
regards,
Luc
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
13.07.2011 13:02, Ahmad Samir kirjutas:
Using pkgconfig provides looks like an optimal option, we could start
now, whenever we touch a spec we change to the pkgconfig provides, and
gradually all the specs will be adapted.
And for the packages that don't have .pc files we add:
Provides: %{name}-devel = %{version}-release
Provides: lib%{name}-devel = %{version}-release
or we could add them to all packages whether they have .pc files or
not, but still always use pkgconfig() provides as BR in our specs.
WDYT?
+1
IMHO provides should be added anyway.
Who's gonna update policy? :)
--
Sander
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On Wed, 13 Jul 2011, Ahmad Samir wrote:
https://bugs.mageia.org/show_bug.cgi?id=2065
Using pkgconfig provides looks like an optimal option, we could start
now, whenever we touch a spec we change to the pkgconfig provides, and
gradually all the specs will be adapted.
And for the packages that don't have .pc files we add:
Provides: %{name}-devel = %{version}-release
Provides: lib%{name}-devel = %{version}-release
or we could add them to all packages whether they have .pc files or
not, but still always use pkgconfig() provides as BR in our specs.
Always adding the same provides regardless of what gets added
automatically is probably better and easier. I'd like to modify or clarify
your proposal a bit. When name starts with lib, use %{oname}-devel and
lib%{oname}-devel as provides. oname must be defined in the specfile as
the name without the lib prefix. That is usually already the case and this
macro is used as argument for mklibname.
Christiaan
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On 13 July 2011 12:15, Christiaan Welvaart c...@daneel.dyndns.org wrote:
On Wed, 13 Jul 2011, Ahmad Samir wrote:
https://bugs.mageia.org/show_bug.cgi?id=2065
Using pkgconfig provides looks like an optimal option, we could start
now, whenever we touch a spec we change to the pkgconfig provides, and
gradually all the specs will be adapted.
And for the packages that don't have .pc files we add:
Provides: %{name}-devel = %{version}-release
Provides: lib%{name}-devel = %{version}-release
or we could add them to all packages whether they have .pc files or
not, but still always use pkgconfig() provides as BR in our specs.
Always adding the same provides regardless of what gets added automatically
is probably better and easier. I'd like to modify or clarify your proposal a
bit. When name starts with lib, use %{oname}-devel and lib%{oname}-devel
as provides. oname must be defined in the specfile as the name without the
lib prefix. That is usually already the case and this macro is used as
argument for mklibname.
Christiaan
Agreed, liblib* shouldn't exist.
--
Ahmad Samir
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On Wed, 13 Jul 2011, Ahmad Samir wrote:
On 10 July 2011 10:03, Ahmad Samir ahmadsamir3...@gmail.com wrote:
On 8 July 2011 06:37, Ahmad Samir ahmadsamir3...@gmail.com wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
either both of them in _all_ packages, or one of them in _all_
packages, so that we don't have to check urpmq --provides all the
time. Personally, I am more inclined on having them both, so as not to
break already working specs.
For example:
$ urpmq --provides lib64gudev1.0-devel-166-5.mga1.x86_64
libgudev-devel[== 166-5.mga1]
pkgconfig(gudev-1.0)[== 166]
devel(libgudev-1.0(64bit))
lib64gudev1.0-devel[== 166-5.mga1]
lib64gudev1.0-devel(x86-64)[== 166-5.mga1]
only libgudev-devel, so if I put BR gudev-devel in a spec it won't
work, whereas I'd expect it to work since some other packages have
such similar provides:
$ urpmq --provides lib64dbus-1-devel
libdbus-1-devel[== 1.4.1-3.mga1]
libdbus-devel[== 1.4.1-3.mga1]
dbus-devel[== 1.4.1-3.mga1]
[...]
WDYT?
(If we agree to go one way or the other, will just fix them gradually
over time).
--
Ahmad Samir
Adding to the above, spturtle has suggested using pkgconfig()
provides: https://bugs.mageia.org/show_bug.cgi?id=2065
--
Ahmad Samir
Using pkgconfig provides looks like an optimal option, we could start
now, whenever we touch a spec we change to the pkgconfig provides, and
gradually all the specs will be adapted.
And for the packages that don't have .pc files we add:
Provides: %{name}-devel = %{version}-release
Provides: lib%{name}-devel = %{version}-release
or we could add them to all packages whether they have .pc files or
not, but still always use pkgconfig() provides as BR in our specs.
I think it's better to use %{name}-devel for packages which don't have
pkgconfig files. And keep pkgconfig() provides for packages with .pc
files.
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On 8 July 2011 06:37, Ahmad Samir ahmadsamir3...@gmail.com wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
either both of them in _all_ packages, or one of them in _all_
packages, so that we don't have to check urpmq --provides all the
time. Personally, I am more inclined on having them both, so as not to
break already working specs.
For example:
$ urpmq --provides lib64gudev1.0-devel-166-5.mga1.x86_64
libgudev-devel[== 166-5.mga1]
pkgconfig(gudev-1.0)[== 166]
devel(libgudev-1.0(64bit))
lib64gudev1.0-devel[== 166-5.mga1]
lib64gudev1.0-devel(x86-64)[== 166-5.mga1]
only libgudev-devel, so if I put BR gudev-devel in a spec it won't
work, whereas I'd expect it to work since some other packages have
such similar provides:
$ urpmq --provides lib64dbus-1-devel
libdbus-1-devel[== 1.4.1-3.mga1]
libdbus-devel[== 1.4.1-3.mga1]
dbus-devel[== 1.4.1-3.mga1]
[...]
WDYT?
(If we agree to go one way or the other, will just fix them gradually
over time).
--
Ahmad Samir
Adding to the above, spturtle has suggested using pkgconfig()
provides: https://bugs.mageia.org/show_bug.cgi?id=2065
--
Ahmad Samir
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On 8 July 2011 17:31, nicolas vigier bo...@mars-attacks.org wrote:
On Fri, 08 Jul 2011, Ahmad Samir wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
Good idea.
With version and release included :
Provides: %{name}-devel = %{version}-%{release}
Provides: lib%{name}-devel = %{version}-%{release}
Yes, of course.
--
Ahmad Samir
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On Fri, Jul 8, 2011 at 6:37 AM, Ahmad Samir ahmadsamir3...@gmail.com wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
either both of them in _all_ packages, or one of them in _all_
packages, so that we don't have to check urpmq --provides all the
time. Personally, I am more inclined on having them both, so as not to
break already working specs.
For example:
$ urpmq --provides lib64gudev1.0-devel-166-5.mga1.x86_64
libgudev-devel[== 166-5.mga1]
pkgconfig(gudev-1.0)[== 166]
devel(libgudev-1.0(64bit))
lib64gudev1.0-devel[== 166-5.mga1]
lib64gudev1.0-devel(x86-64)[== 166-5.mga1]
only libgudev-devel, so if I put BR gudev-devel in a spec it won't
work, whereas I'd expect it to work since some other packages have
such similar provides:
$ urpmq --provides lib64dbus-1-devel
libdbus-1-devel[== 1.4.1-3.mga1]
libdbus-devel[== 1.4.1-3.mga1]
dbus-devel[== 1.4.1-3.mga1]
[...]
WDYT?
(If we agree to go one way or the other, will just fix them gradually
over time).
--
Ahmad Samir
for me this is a +1 w/o hesitation
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On 08/07/11 06:37, Ahmad Samir wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
either both of them in _all_ packages, or one of them in _all_
packages, so that we don't have to check urpmq --provides all the
time. Personally, I am more inclined on having them both, so as not to
break already working specs.
WDYT?
Hi! YES!!!
As a Padawan, this was one of my first troubles, to find the correct
-devel package name. Some packages have even different --provides
according to the arch :-/
Both Provides are certainly the best, but we may recommend the usage
of only one of type in Requires: lib%{name}-devel?
Cheers,
Chris.
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On 8 July 2011 13:44, EatDirt dirt...@gmail.com wrote:
On 08/07/11 06:37, Ahmad Samir wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
either both of them in _all_ packages, or one of them in _all_
packages, so that we don't have to check urpmq --provides all the
time. Personally, I am more inclined on having them both, so as not to
break already working specs.
WDYT?
Hi! YES!!!
As a Padawan, this was one of my first troubles, to find the correct -devel
package name. Some packages have even different --provides according to the
arch :-/
[..]
Both Provides are certainly the best, but we may recommend the usage of
only one of type in Requires: lib%{name}-devel?
Cheers,
Chris.
For new specs maybe, but for old ones, that would break compatibility
with other specs that already have BR: %{name}-devel. So since we
can't easily get rid of one or the other, better have both...
--
Ahmad Samir
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On 08.07.2011 07:37, Ahmad Samir wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
either both of them in _all_ packages, or one of them in _all_
packages, so that we don't have to check urpmq --provides all the
time. Personally, I am more inclined on having them both, so as not to
break already working specs.
For example:
$ urpmq --provides lib64gudev1.0-devel-166-5.mga1.x86_64
libgudev-devel[== 166-5.mga1]
pkgconfig(gudev-1.0)[== 166]
devel(libgudev-1.0(64bit))
lib64gudev1.0-devel[== 166-5.mga1]
lib64gudev1.0-devel(x86-64)[== 166-5.mga1]
only libgudev-devel, so if I put BR gudev-devel in a spec it won't
work, whereas I'd expect it to work since some other packages have
such similar provides:
$ urpmq --provides lib64dbus-1-devel
libdbus-1-devel[== 1.4.1-3.mga1]
libdbus-devel[== 1.4.1-3.mga1]
dbus-devel[== 1.4.1-3.mga1]
[...]
WDYT?
(If we agree to go one way or the other, will just fix them gradually
over time).
I remember having this discussion in Mandriva when we dropped %major
from devel name. As a result the library policy (which we have on Mageia
as well) was altered so that all packages should have
- name-devel
- tarballname-devel
as provides, i.e. without lib%name-devel (except for existing pkgs).
This is what I've been using for any new packages I've packaged.
However, as usual, I'm fine with any consistent scheme (one or the other
or both).
--
Anssi Hannula
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On Fri, 08 Jul 2011, Ahmad Samir wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
Good idea.
With version and release included :
Provides: %{name}-devel = %{version}-%{release}
Provides: lib%{name}-devel = %{version}-%{release}
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
Am 08.07.2011 17:31, schrieb nicolas vigier:
On Fri, 08 Jul 2011, Ahmad Samir wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
Good idea.
With version and release included :
Provides: %{name}-devel = %{version}-%{release}
Provides: lib%{name}-devel = %{version}-%{release}
/me fully supporting this proposal.
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
Le vendredi 08 juillet 2011 à 17:27 +0300, Anssi Hannula a écrit :
On 08.07.2011 07:37, Ahmad Samir wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
either both of them in _all_ packages, or one of them in _all_
packages, so that we don't have to check urpmq --provides all the
time. Personally, I am more inclined on having them both, so as not to
break already working specs.
For example:
$ urpmq --provides lib64gudev1.0-devel-166-5.mga1.x86_64
libgudev-devel[== 166-5.mga1]
pkgconfig(gudev-1.0)[== 166]
devel(libgudev-1.0(64bit))
lib64gudev1.0-devel[== 166-5.mga1]
lib64gudev1.0-devel(x86-64)[== 166-5.mga1]
only libgudev-devel, so if I put BR gudev-devel in a spec it won't
work, whereas I'd expect it to work since some other packages have
such similar provides:
$ urpmq --provides lib64dbus-1-devel
libdbus-1-devel[== 1.4.1-3.mga1]
libdbus-devel[== 1.4.1-3.mga1]
dbus-devel[== 1.4.1-3.mga1]
[...]
WDYT?
(If we agree to go one way or the other, will just fix them gradually
over time).
I remember having this discussion in Mandriva when we dropped %major
from devel name. As a result the library policy (which we have on Mageia
as well) was altered so that all packages should have
- name-devel
- tarballname-devel
as provides, i.e. without lib%name-devel (except for existing pkgs).
This is what I've been using for any new packages I've packaged.
However, as usual, I'm fine with any consistent scheme (one or the other
or both).
I would be in favor of keeping the compatibility with existing
practice.
--
Michael Scherer
