How to package a patched older version of libvmime in Fedora best?
by Robert Scheck
Good evening,
I've the situation, that a package unluckily requires an older version of
libvmime and some specific/individual patches as well. The question is now,
how to package that best for Fedora and EPEL?
What I'm requiring is libvmime 0.7.1 + patches, while upstream is at 0.9.1
which is unluckily ABI and API incompatible.
There are now multiple solutions how to deal with this as I can't use 0.9.1
now and in foreseeable future:
a) Build libvmime 0.7.1 + patches in before of the software requiring it
and link statically against it. This would make sense in this case, even
if static linking is discouraged in Fedora, but nothing except that
piece of software requires actually libvmime 0.7.1 + individual patches.
b) Build libvmime 0.7.1 + patches as own package and call it e.g. something
like foobar-libvmime and rename libvmime.so.* to foobar-libvmime.so.* or
similar. That would bring me to -lfoobar-libvmime linking or something
similar, right?
Just providing a compat-libvmime seems not suitable, as compat-* in Fedora
is only providing the library, not -devel stuff which is actually needed to
build the other software requiring the old libvmime 0.7.1 + patches.
As of overlapping *.so filenames, it is not possible to avoid renaming the
patched version. Question is, which is better and which one will go through
the package review or are there better ideas how to solve this?
Yes, some far day, upstream will accept all of the individual patches and
the other software will support latest libvmime version, but this won't be
in the next time as libvmime support is somehow seemingly less interested
in being backward compatible.
Greetings,
Robert
15 years
Re: Agenda for the 2009-03-31 Packaging Committee meeting
by Ralf Corsepius
Jason L Tibbitts III wrote:
> The Packaging Committee will meet Tuesday, 2009-03-31 at 17:00UTC in
> the #fedora-meeting channel on chat.freenode.net.
Due to Europe having shifted to DST, 17:00UTC is once again (as in
previous years) hardly suitable for me.
I'll very likely not be able to attend many upcoming FPC meetings, rsp.
if I can attend, will have to leave early.
Ralf
15 years
First post
by Philippe Makowski
Hi,
I'm new to the Fedora Project.
I'm Philippe Makowski, member of the Firebird AdminTeam (www.firebirdsql.org)
I jump here to help packaging Firebird and it's related tools inside Fedora.
I hope that we will solve this request quick
(https://bugzilla.redhat.com/show_bug.cgi?id=488100) so after, we can
add at least Flamerobin and the Python driver for Firebird packages.
If need, I think I can find time to be co maintainer of Firebird and
related tools package.
Wish you all sucess.
15 years
Advice over mono and rebuilding for silverlight
by Paul F. Johnson
Hi,
I've had a request from rpmfusion to rebuild mono with the
--with-moonlight flag set. This builds in the functionality required to
build Silverlight on rpmfusion.
I am aware that Fedora itself cannot have Silverlight in (the licence is
the MS "shared source" (cough) licence) due to the potential for MS to
do it's usual trick of going back on their word and applying patents to
cause problems.
While adding in the smcs and silverlight code possibly does not break
any of the fedora rules, I am of the thinking that we don't add the flag
for the same reason that we have disabled xmms for mp3; it has the
potential to cause us problems.
This is probably a question for the legal people, but I'm asking it here
as I don't have the legal people's email address and it is also a
packaging problem.
If I get the okay to build mono with the flag, I will.
TTFN
Paul
--
Sie können mich aufreizen und wirklich heiß machen!
15 years
Re: Publican Issues
by Joshua Wulf
Thanks for your response and suggestions Toshio.
I think it's more venting frustration than actually blaming the FPC for
being a roadblock.
*Anything* that we can do to resolve these issues, keeping in mind the
limited resources we are working with and the need to work together and
forge stronger relationships going forward, will be great.
Josh
Toshio Kuratomi wrote:
> Joshua Wulf wrote:
> Thanks Joshua,
>
>
>> I think that Jeff and Chris are referring to this:
>> https://bugzilla.redhat.com/show_bug.cgi?id=476471
>>
>>
> IIUC, this boils down to:
> 1) Publican creates a different documentation package for each Fedora
> Release as it considers them to be separate documents. ie:
> Fedora-10-Security-Guide, Fedora-11-Security-Guide.
>
> 2) This means a new package review for each documentation package each
> release.
>
> If you're willing to go through a new review each release, there's no
> problem.
>
> If you want a single review to cover you for all releases, we need a new
> Guideline. I think if it's a potential goal to be able to install the
> Fedora-10-Security-Guide on Fedora-11, then I'd be against such a
> Guideline as separate packages really are what you want. If it's
> specifically a non-goal to do that, then it's a possibility although
> changing the name to not have the version in it strikes me as the better
> option there. Following onto that, I'm not sure why you wouldn't want
> to use publican to create an initial spec file and then modify it to
> meet the specifics of the situation. This is the workflow for CPAN2RPM,
> rpmdev-newspetemplate, and other tools.
>
> Another option is to look at a streamlined set of review items for
> publican-created doc packages... We've never explicitly done this but in
> practice, people know they don't have to check, for instance, shared
> library guidelines when writing and reviewing a pure python module.
>
>
>> and possibly this as well:
>> https://bugzilla.redhat.com/show_bug.cgi?id=482972
>>
>>
> What's the problem here? That the .desktop is created inline in the
> spec file instead of as a separate file? If that's all it is, I can
> propose to the FPC to amend that. I can't recall a reason that it had
> to be included in the SRPM as a file specifically.
>
> Note that neither of these issues had reached the FPC's radar (they
> still haven't, really, as I'm only one member and this isn't the
> packaging mailing list) so blaming the FPC as the roadblock is a bit
> misplaced.
>
> -Toshio
>
>
--
Joshua J Wulf
Engineering Content Services
Red Hat Asia Pacific
eml: jwulf(a)redhat.com
tel: +61 (0)7 3514 8140
mob: +61 (0)431 929 675
tmz: GMT +10
(0) - omit when dialling internationally
15 years
Re: Publican Issues
by Joshua Wulf
Joshua Wulf wrote:
>>
> I think that Jeff and Chris are referring to this:
> https://bugzilla.redhat.com/show_bug.cgi?id=476471
Comment #58 by Jens Petersen:
I am not veto'ing parallel install per se, but maybe it is worth considerng
what is so special about docs packages that warrants/necessitates parallel
install since we don't really do this for any other packages except
libraries/tools needed occasionally for back-compatibility.
The idea here is that people who are using Fedora in a production
capacity, rather than just as a beta test of RHEL, are able to install
multiple documentation sets.
The use case would be like this:
I'm a system administrator with a number of different servers on my
network running different versions of Fedora. Some are internal servers
and running the ancient Fedora 10. There is one running Fedora 15 that
I'm intending to upgrade later. The ones on the firewall I run at
latest-1, and are currently on Fedora 19. I'm running Fedora 20 on my
personal workstation, and I have a virtual machine running Fedora Rawhide.
On my Fedora 20 workstation I have the documentation for all of these
different versions installed (F10, F15, F19, F20, Rawhide), so that I
can refer to the relevant docs in my graphical user environment as I
administer them remotely via ssh.
That's the idea. It doesn't make much sense if you envision Fedora as a
RHEL beta test that you scrap each time a new version comes out, but if
it's a viable OS that can be deployed and used in a production capacity
like that described above, parallel documentation installation will be
useful.
What are your thoughts on this?
Josh
--
Joshua J Wulf
Engineering Content Services
Red Hat Asia Pacific
eml: jwulf(a)redhat.com
tel: +61 (0)7 3514 8140
mob: +61 (0)431 929 675
tmz: GMT +10
(0) - omit when dialling internationally
15 years
Binary FreeDOS image
by Lubomir Rintel
Hi,
I'm just reviewing a DOSEmu package, where the package author includes a
tarball of FreeDOS installation (binary images of a couple of basic DOS
utilities, shell and the kernel). I believe that it's probably illegal
(provided it's GPL code, I have not checked) to do this unless we
distribute sources as well.
Would anyone mind if I told the maintainer just to include the source
tarball in SRPM for now? Building the whole thing from source, while
cleanly being possible, would add a huge amount of work at this point.
Thanks,
--
Lubomir Rintel <lkundrak(a)v3.sk>
15 years
Directory ownership guidelines
by Mattias Ellert
Hi!
It was suggested to me to bring this issue to this list.
The packaging guidelines says that a package should not own a directory
that is owned by a package on which it depends.
The packaging guidelines also says that packages should own all
directories needed in order not to leave orphaned directories after a
package de-installation.
The way rpm/yum currently works these guidelines are contradicting and
you must choose which one to implement in your packaging.
My question is - is this a bug in yum/rpm, or a flaw in the packaging
guidelines?
Here is an example that implements the first guideline - and violates
the second - spec file attached.
The spec builds a main package, 8 packages (A-H) that depend on the main
package and 8 devel packages that each depends on one of the packages
(A-H).
If I install all 17 packages and then do "yum remove mytest", all
packages should be removed cleanly if the Requires are influencing the
order the packages are uninstalled, which it must do if both guidelines
is supposed to be implementable simultaneously.
This is not what happens:
[root@localhost ~]# rpm -ivh /home/ellert/rpmbuild/RPMS/i386/mytest-*
Förbereder... ########################################### [100%]
1:mytest ########################################### [ 6%]
2:mytest-A ########################################### [ 12%]
3:mytest-B ########################################### [ 18%]
4:mytest-C ########################################### [ 24%]
5:mytest-D ########################################### [ 29%]
6:mytest-E ########################################### [ 35%]
7:mytest-F ########################################### [ 41%]
8:mytest-G ########################################### [ 47%]
9:mytest-H ########################################### [ 53%]
10:mytest-A-devel ########################################### [ 59%]
11:mytest-B-devel ########################################### [ 65%]
12:mytest-C-devel ########################################### [ 71%]
13:mytest-D-devel ########################################### [ 76%]
14:mytest-E-devel ########################################### [ 82%]
15:mytest-F-devel ########################################### [ 88%]
16:mytest-G-devel ########################################### [ 94%]
17:mytest-H-devel ########################################### [100%]
[root@localhost ~]# yum remove mytest
Loaded plugins: refresh-packagekit
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package mytest.i386 0:1.0-1.fc10 set to be erased
--> Processing Dependency: mytest for package: mytest-A
--> Processing Dependency: mytest for package: mytest-E
--> Processing Dependency: mytest for package: mytest-G
--> Processing Dependency: mytest for package: mytest-B
--> Processing Dependency: mytest for package: mytest-F
--> Processing Dependency: mytest for package: mytest-C
--> Processing Dependency: mytest for package: mytest-D
--> Processing Dependency: mytest for package: mytest-H
--> Running transaction check
---> Package mytest-A.i386 0:1.0-1.fc10 set to be erased
--> Processing Dependency: mytest-A = 1.0-1.fc10 for package: mytest-A-devel
---> Package mytest-B.i386 0:1.0-1.fc10 set to be erased
--> Processing Dependency: mytest-B = 1.0-1.fc10 for package: mytest-B-devel
---> Package mytest-C.i386 0:1.0-1.fc10 set to be erased
--> Processing Dependency: mytest-C = 1.0-1.fc10 for package: mytest-C-devel
---> Package mytest-D.i386 0:1.0-1.fc10 set to be erased
--> Processing Dependency: mytest-D = 1.0-1.fc10 for package: mytest-D-devel
---> Package mytest-E.i386 0:1.0-1.fc10 set to be erased
--> Processing Dependency: mytest-E = 1.0-1.fc10 for package: mytest-E-devel
---> Package mytest-F.i386 0:1.0-1.fc10 set to be erased
--> Processing Dependency: mytest-F = 1.0-1.fc10 for package: mytest-F-devel
---> Package mytest-G.i386 0:1.0-1.fc10 set to be erased
--> Processing Dependency: mytest-G = 1.0-1.fc10 for package: mytest-G-devel
---> Package mytest-H.i386 0:1.0-1.fc10 set to be erased
--> Processing Dependency: mytest-H = 1.0-1.fc10 for package: mytest-H-devel
--> Running transaction check
---> Package mytest-A-devel.i386 0:1.0-1.fc10 set to be erased
---> Package mytest-B-devel.i386 0:1.0-1.fc10 set to be erased
---> Package mytest-C-devel.i386 0:1.0-1.fc10 set to be erased
---> Package mytest-D-devel.i386 0:1.0-1.fc10 set to be erased
---> Package mytest-E-devel.i386 0:1.0-1.fc10 set to be erased
---> Package mytest-F-devel.i386 0:1.0-1.fc10 set to be erased
---> Package mytest-G-devel.i386 0:1.0-1.fc10 set to be erased
---> Package mytest-H-devel.i386 0:1.0-1.fc10 set to be erased
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Removing:
mytest i386 1.0-1.fc10 installed 0.0
Removing for dependencies:
mytest-A i386 1.0-1.fc10 installed 6.0
mytest-A-devel i386 1.0-1.fc10 installed 7.0
mytest-B i386 1.0-1.fc10 installed 6.0
mytest-B-devel i386 1.0-1.fc10 installed 7.0
mytest-C i386 1.0-1.fc10 installed 6.0
mytest-C-devel i386 1.0-1.fc10 installed 7.0
mytest-D i386 1.0-1.fc10 installed 6.0
mytest-D-devel i386 1.0-1.fc10 installed 7.0
mytest-E i386 1.0-1.fc10 installed 6.0
mytest-E-devel i386 1.0-1.fc10 installed 7.0
mytest-F i386 1.0-1.fc10 installed 6.0
mytest-F-devel i386 1.0-1.fc10 installed 7.0
mytest-G i386 1.0-1.fc10 installed 6.0
mytest-G-devel i386 1.0-1.fc10 installed 7.0
mytest-H i386 1.0-1.fc10 installed 6.0
mytest-H-devel i386 1.0-1.fc10 installed 7.0
Transaction Summary
================================================================================
Install 0 Package(s)
Update 0 Package(s)
Remove 17 Package(s)
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
Erasing : mytest-E-devel 1/17
Erasing : mytest-H-devel 2/17
Erasing : mytest-A 3/17
Erasing : mytest-C 4/17
Erasing : mytest-D 5/17
Erasing : mytest-E 6/17
Erasing : mytest-G 7/17
Erasing : mytest-H 8/17
Erasing : mytest-C-devel 9/17
Erasing : mytest-F-devel 10/17
Erasing : mytest-F 11/17
Erasing : mytest-A-devel 12/17
Erasing : mytest-D-devel 13/17
Erasing : mytest 14/17
Erasing : mytest-G-devel 15/17
Erasing : mytest-B 16/17
Erasing : mytest-B-devel 17/17
Removed:
mytest.i386 0:1.0-1.fc10
Dependency Removed:
mytest-A.i386 0:1.0-1.fc10 mytest-A-devel.i386 0:1.0-1.fc10
mytest-B.i386 0:1.0-1.fc10 mytest-B-devel.i386 0:1.0-1.fc10
mytest-C.i386 0:1.0-1.fc10 mytest-C-devel.i386 0:1.0-1.fc10
mytest-D.i386 0:1.0-1.fc10 mytest-D-devel.i386 0:1.0-1.fc10
mytest-E.i386 0:1.0-1.fc10 mytest-E-devel.i386 0:1.0-1.fc10
mytest-F.i386 0:1.0-1.fc10 mytest-F-devel.i386 0:1.0-1.fc10
mytest-G.i386 0:1.0-1.fc10 mytest-G-devel.i386 0:1.0-1.fc10
mytest-H.i386 0:1.0-1.fc10 mytest-H-devel.i386 0:1.0-1.fc10
Complete!
After the removal there are orphaned directories:
[root@localhost ~]# find /usr/share/mytest
/usr/share/mytest
/usr/share/mytest/C
/usr/share/mytest/G
/usr/share/mytest/B
/usr/share/mytest/D
/usr/share/mytest/A
[root@localhost ~]# rpm -q --whatprovides `find /usr/share/mytest`
filen /usr/share/mytest tillhör inget paket
filen /usr/share/mytest/C tillhör inget paket
filen /usr/share/mytest/G tillhör inget paket
filen /usr/share/mytest/B tillhör inget paket
filen /usr/share/mytest/D tillhör inget paket
filen /usr/share/mytest/A tillhör inget paket
15 years
Perl Question
by Conner Finlay
Hello list,
I have searched Google high and low, but I have not found an answer. I have
a spec file that requires some perl modules, ie Net::IP, XML::Simple, etc.
For all but one there is an RPM available for it. In the SPEC file I have
them as Requires: perl(Net::IP) and the spec file builds fine(rpmbuild -ba
-v) but when I go to install the RPM it complains about the missing perl
modules. If I do a `yum install perl-xyz` and rebuild the SPEC file, it will
not complain about the missing perl modules. How can I have the SPEC file
download/install the perl modules/packages? If it is easier, I can also post
the SPEC file itself.
Thanks,
Conner
--
Conner Finlay
15 years
