Hi all,
I took over a package a couple of days ago and have a question according to a provide statement. Consider the following one:
Name: myapp Provides: myapp.pl
If I interpret the naming guidelines right, then a period is not allowed in a package name. But what about a provide statement (guess it's the same)?
In case it is also illegal what would be the best to do. Will yum update the package if a user installed previously "myapp.pl" instead of "myapp" and the new package does not have a provide statement anymore? In the end the question would be should I follow the guidelines or provide backward compatibility in sense of updating.
cheers Stefan
PS: ".pl" should indicate that it is a Perl script, not a locale.
On Tue, 29 Sep 2009 14:32:06 +0200, Stefan wrote:
Hi all,
I took over a package a couple of days ago and have a question according to a provide statement. Consider the following one:
Name: myapp Provides: myapp.pl
If I interpret the naming guidelines right, then a period is not allowed in a package name.
Well, better is, but it's not entirely right. Think "openoffice.org" packages. ;) The period is used as separator/delimiter in RPM package file names, however, so using it elsewhere may cause confusion in software that cannot deal with the extra period characters.
But what about a provide statement (guess it's the same)?
No. See e.g. the automatic library SONAME provides: libfoo.so.0 Or see "rpm -qa --provides".
In case it is also illegal what would be the best to do. Will yum update the package if a user installed previously "myapp.pl" instead of "myapp" and the new package does not have a provide statement anymore?
Yes, because the newer "myapp" package will replace the older one, regardless of its Provides.
In the end the question would be should I follow the guidelines or provide backward compatibility in sense of updating.
cheers Stefan
PS: ".pl" should indicate that it is a Perl script, not a locale.
Try: repoquery --whatrequires myapp.pl
If nothing uses this virtual package name (and it isn't used upstream either), get rid of it.
On Tue, 2009-09-29 at 14:45 +0200, Michael Schwendt wrote: [...]
But what about a provide statement (guess it's the same)?
No. See e.g. the automatic library SONAME provides: libfoo.so.0 Or see "rpm -qa --provides".
Good point.
In case it is also illegal what would be the best to do. Will yum update the package if a user installed previously "myapp.pl" instead of "myapp" and the new package does not have a provide statement anymore?
Yes, because the newer "myapp" package will replace the older one, regardless of its Provides.
That was the behavior of yum I expected/hoped to see.
In the end the question would be should I follow the guidelines or provide backward compatibility in sense of updating.
cheers Stefan
PS: ".pl" should indicate that it is a Perl script, not a locale.
Try: repoquery --whatrequires myapp.pl
If nothing uses this virtual package name (and it isn't used upstream either), get rid of it.
No other package uses this name (also not upstream) so I'm going to remove it.
Thanks for clarification, Stefan
"SSF" == Stefan Schulze Frielinghaus stefan@seekline.net writes:
SSF> If I interpret the naming guidelines right, then a period is not SSF> allowed in a package name.
Could you indicate where in the naming guidelines you see that a period is not valid in a package name?
- J<
On Tue, 2009-09-29 at 09:33 -0500, Jason L Tibbitts III wrote:
"SSF" == Stefan Schulze Frielinghaus stefan@seekline.net writes:
SSF> If I interpret the naming guidelines right, then a period is not SSF> allowed in a package name.
Could you indicate where in the naming guidelines you see that a period is not valid in a package name?
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Separators
"When naming packages for Fedora, the maintainer must use the dash '-' as the delimiter for name parts. The maintainer must NOT use an underscore '_', a plus '+', or a period '.' as a delimiter" unless indicated by the few exceptions underneath.
-Stefan
"SSF" == Stefan Schulze Frielinghaus stefan@seekline.net writes:
SSF> https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Separators SSF> "When naming packages for Fedora, the maintainer must use the dash SSF> '-' as the delimiter for name parts. The maintainer must NOT use an SSF> underscore '_', a plus '+', or a period '.' as a delimiter" unless SSF> indicated by the few exceptions underneath.
"delimiter for name parts". That doesn't say a period is invalid in a package name, because it's explicitly listed as valid at the top of the document. The section you quote indicates why we have "foo-devel" and "perl-Foo-Bar" instead of "foo.devel" and "perl.Foo.Bar".
- J<
On Tue, 2009-09-29 at 10:26 -0500, Jason L Tibbitts III wrote:
"SSF" == Stefan Schulze Frielinghaus stefan@seekline.net writes:
SSF> https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Separators SSF> "When naming packages for Fedora, the maintainer must use the dash SSF> '-' as the delimiter for name parts. The maintainer must NOT use an SSF> underscore '_', a plus '+', or a period '.' as a delimiter" unless SSF> indicated by the few exceptions underneath.
"delimiter for name parts". That doesn't say a period is invalid in a package name, because it's explicitly listed as valid at the top of the document. The section you quote indicates why we have "foo-devel" and "perl-Foo-Bar" instead of "foo.devel" and "perl.Foo.Bar".
Right. I was in doubt if the provide statement was/is really fine, so I wanted to clarify this.
Thanks to point this out and to precise the question.
Le Mar 29 septembre 2009 17:42, Stefan Schulze Frielinghaus a écrit :
Right. I was in doubt if the provide statement was/is really fine, so I wanted to clarify this.
Also package naming guidelines do not apply to provides. FPC has even explicitely used the "just stuff it in provides" argument to refuse changes in package naming conventions
Le Mar 29 septembre 2009 17:26, Jason L Tibbitts III a écrit :
"SSF" == Stefan Schulze Frielinghaus stefan@seekline.net writes:
SSF> https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Separators SSF> "When naming packages for Fedora, the maintainer must use the dash SSF> '-' as the delimiter for name parts. The maintainer must NOT use an SSF> underscore '_', a plus '+', or a period '.' as a delimiter" unless SSF> indicated by the few exceptions underneath.
"delimiter for name parts". That doesn't say a period is invalid in a package name, because it's explicitly listed as valid at the top of the document. The section you quote indicates why we have "foo-devel" and "perl-Foo-Bar" instead of "foo.devel" and "perl.Foo.Bar".
I don't think the list of examples right below this § supports your view (and actually I do believe the list of existing infringing packages is small enough renaming them would have been worth removing any future package confusion)
Le Mar 29 septembre 2009 17:43, Nicolas Mailhot a écrit :
I don't think the list of examples right below this § supports your view (and actually I do believe the list of existing infringing packages is small enough renaming them would have been worth removing any future package confusion)
And BTW could someone remove https://fedoraproject.org/wiki/Packaging/NamingGuidelines#AddonLocale
or find some other example? It's in direct contradiction with the font package naming guidelines.
Regards,
On Tue, 29 Sep 2009 17:43:38 +0200, Nicolas wrote:
Le Mar 29 septembre 2009 17:26, Jason L Tibbitts III a écrit :
> "SSF" == Stefan Schulze Frielinghaus writes:
SSF> https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Separators SSF> "When naming packages for Fedora, the maintainer must use the dash SSF> '-' as the delimiter for name parts. The maintainer must NOT use an SSF> underscore '_', a plus '+', or a period '.' as a delimiter" unless SSF> indicated by the few exceptions underneath.
"delimiter for name parts". That doesn't say a period is invalid in a package name, because it's explicitly listed as valid at the top of the document. The section you quote indicates why we have "foo-devel" and "perl-Foo-Bar" instead of "foo.devel" and "perl.Foo.Bar".
I don't think the list of examples right below this § supports your view (and actually I do believe the list of existing infringing packages is small enough renaming them would have been worth removing any future package confusion)
The delimiter is implicit anyway for an ordinary
%package foo
sub-package definition which results in %{name}-foo without that the packager needs to decide on using '-' or '.' anywhere. As opposed to doing it explicitly %package -n something.foo for a sub-package.
[...]
Why does it need an exception for locale packages? https://fedoraproject.org/wiki/Packaging/NamingGuidelines#AddonLocale
"If a package adds a locale to an existing parent package, then it can use an underscore in the locale."
Examples:
ttfonts-zh_TW (adds zh_TW locale fonts in ttfonts family) ttfonts-zh_CN (adds zh_CN locale fonts in ttfonts family)
That's the typical "parent-child" scheme, with the locale being a "name part". Why does it need an exception for an underscore in the child name? The underscore here is no "name parts" delimiter, but part of an ordinary package name.
-
Jason L Tibbitts III -
Michael Schwendt -
Nicolas Mailhot -
Stefan Schulze Frielinghaus