Re: Packaging question - replacing directory with possible user file in with a symlink

V Sat, Jun 14, 2025 at 09:18:56AM +1000, Peter Hutterer napsal(a): > On Fri, Jun 13, 2025 at 10:05:32AM +0200, Petr Pisar wrote: > > V Fri, Jun 13, 2025 at 03:27:49PM +1000, Peter Hutterer napsal(a): > > > Hi all, > > > > > > A tricky (for me) packaging q

Re: Packaging question - replacing directory with possible user file in with a symlink

On Sat, Jun 14, 2025 at 1:21 AM Peter Hutterer wrote: > > On Fri, Jun 13, 2025 at 10:05:32AM +0200, Petr Pisar wrote: > > V Fri, Jun 13, 2025 at 03:27:49PM +1000, Peter Hutterer napsal(a): > > > Hi all, > > > > > > A tricky (for me) packaging question: >

Re: Packaging question - replacing directory with possible user file in with a symlink

On Fri, Jun 13, 2025 at 10:05:32AM +0200, Petr Pisar wrote: > V Fri, Jun 13, 2025 at 03:27:49PM +1000, Peter Hutterer napsal(a): > > Hi all, > > > > A tricky (for me) packaging question: > > xkeyboard-config 2.45 upstream changed the installation directory to &g

Re: Packaging question - replacing directory with possible user file in with a symlink

V Fri, Jun 13, 2025 at 03:27:49PM +1000, Peter Hutterer napsal(a): > Hi all, > > A tricky (for me) packaging question: > xkeyboard-config 2.45 upstream changed the installation directory to > make future multi-version installs possible. Traditionally files were > installed in

Packaging question - replacing directory with possible user file in with a symlink

Hi all, A tricky (for me) packaging question: xkeyboard-config 2.45 upstream changed the installation directory to make future multi-version installs possible. Traditionally files were installed in /usr/share/X11/xkb with an xkeyboard-config.pc pointing to those files (though that path is also

Re: ROCm-Device-Libs packaging question

Dne 21. 01. 22 v 23:22 Jeremy Newton napsal(a): In order to update "rocm-runtime" to the latest, it requires a new package "ROCm-Device-Libs" as a build requirement. The issue is that the project installs files into /usr/amdgcn, which seems incorrect to me based on the FHS and Fedora guidelines

Re: ROCm-Device-Libs packaging question

I created a new review request, hopefully that encourages some conversation on the topic :) https://bugzilla.redhat.com/show_bug.cgi?id=2044664 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fed

ROCm-Device-Libs packaging question

In order to update "rocm-runtime" to the latest, it requires a new package "ROCm-Device-Libs" as a build requirement. The issue is that the project installs files into /usr/amdgcn, which seems incorrect to me based on the FHS and Fedora guidelines. Here's the upstream for reference: https://gith

Re: Packaging question: Rebuild initramfs after adding to dracut.conf.d

Eric Edens via devel 于 2021年2月4日周四 上午10:54写道： > I'm working on a package that adds a configuration to dracut.conf.d. [1] > To rebuild initramfs, upstream's spec file calls `dracut --force` in > `%post` . [2] > > Questions: > - Is it recommended that the RPM updates initramfs? - If so, what's the

Packaging question: Rebuild initramfs after adding to dracut.conf.d

I'm working on a package that adds a configuration to dracut.conf.d. [1] To rebuild initramfs, upstream's spec file calls `dracut --force` in `%post` . [2] Questions: - Is it recommended that the RPM updates initramfs? - If so, what's the recommended method? As background, the RPM will be used

Re: python3 entry_points console scripts packaging question

On Wed, Nov 27, 2019 at 05:11:37PM +0100, Dominique Martinet wrote: > Miro Hrončok wrote on Wed, Nov 27, 2019 at 04:32:27PM +0100: ...snip... > > And in Fedora, when you ahve both of those, it also means that > > /usr/bin/python3 is Python 3.8. > > Ok, I thought it was just much less likely but it

Re: python3 entry_points console scripts packaging question

Miro Hrončok wrote on Wed, Nov 27, 2019 at 04:32:27PM +0100: > If I understand this properly, your package requires (in Fedora): > > - /usr/bin/python3 > - python3.8dist(setuptools) Yes, on Fedora 31 the current requires for clustershell (to continue with that example) contain these: $ rpm -q -

Re: python3 entry_points console scripts packaging question

On 27. 11. 19 16:20, Dominique Martinet wrote: Hi, Some context first, skip to the end if you want. We have a few python packages at $work with setuptools entry_points console scripts - basically setuptools creates a small python script for you loading a module and calling the function you spe

python3 entry_points console scripts packaging question

Hi, Some context first, skip to the end if you want. We have a few python packages at $work with setuptools entry_points console scripts - basically setuptools creates a small python script for you loading a module and calling the function you specified. For example, clustershell here defines f

Re: Packaging Question - Open Liberty

Hi,I have another packaging question about symlinks.We read in the guidelines that all jars and class files should go under %{_javadir} (/usr/share/java by default). We were initially thinking of symlinking all the jars and class files but due to our installation dir structure, it will be

Re: Packaging Question - Open Liberty

Cc:Subject: Re: Packaging Question - Open LibertyDate: Thu, Mar 21, 2019 3:05 PM    On Thu, 21 Mar 2019, 18:50 Adam Williamson, <adamw...@fedoraproject.org> wrote: On Thu, 2019-03-21 at 17:25 +, Michael Zhang wrote:> Hi>> From the previous email, it was stated that it's manda

Re: Packaging Question - Open Liberty

On Thu, 21 Mar 2019, 18:50 Adam Williamson, wrote: > On Thu, 2019-03-21 at 17:25 +, Michael Zhang wrote: > > Hi > > > > From the previous email, it was stated that it's mandatory to include > > the building of the Open Liberty binaries into the rpmbuild. We are > > planning on doing that and

Re: Packaging Question - Open Liberty

On Thu, 2019-03-21 at 17:25 +, Michael Zhang wrote: > Hi > > From the previous email, it was stated that it's mandatory to include > the building of the Open Liberty binaries into the rpmbuild. We are > planning on doing that and making it publicly available through > Github. So does that mean

Packaging Question - Open Liberty

HiFrom the previous email, it was stated that it's mandatory to include the building of the Open Liberty binaries into the rpmbuild. We are planning on doing that and making it publicly available through Github. So does that mean that you guys at Fedora are going to rebuild from source to publish,

Re: Packaging Question - Building the Binaries of my package

On Thu, Mar 07, 2019 at 06:49:12PM +, Michael Zhang wrote: > So after tinkering around, I can incorporate the building of the > openliberty.zip into the Travis CI build but I cannot directly add it > into the %install phase of the rpm spec file. Would that be fine? It should be in the %build s

Re: Packaging Question - Building the Binaries of my package

Michael Zhang wrote: > Recently, someone advised me that I have to build the binaries from the > source code in the %install phase. That is to say that I have to make it > transparent how the binaries (ex. jar) are built. See https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-

Re: Packaging Question - Building the Binaries of my package

On Thu, 2019-03-07 at 18:49 +, Michael Zhang wrote: > Recently, someone advised me that I have to build the binaries from > the source code in the %install phase. The building should happein the %build phase. The %install phase is where the resulting artifacts are copied into the buildroot.

Re: Packaging Question - Building the Binaries of my package

On Thu, Mar 07, 2019 at 06:49:12PM +, Michael Zhang wrote: > Recently, someone advised me that I have to build the binaries from the > source code in the %install phase. That is to say that I have to make it > transparent how the binaries (ex. jar) are built.  As I understand it, in Debian, de

Re: Packaging Question - Building the Binaries of my package

Am 07.03.19 um 19:49 schrieb Michael Zhang: > So after tinkering around, I can incorporate the building of the > openliberty.zip into the Travis CI build but I cannot directly add it into the > %install phase of the rpm spec file. Would that be fine? To the best of my knowledge all building from

Packaging Question - Building the Binaries of my package

I’m a new maintainer and I’ve been trying to get my package, Open Liberty, into the Fedora repositories.   I currently build my rpms in a public Travis CI build. I do so by using wget to pull a zipped up pre-built openliberty package from “https://public.dhe.ibm.com/ibmdl/export/pub/software/openli

Re: Packaging Question

On 10/27/2017 01:17 PM, Stephen Gallagher wrote: > > > Question: Update time... I'm assuming that I should just > go ahead update both packages whether they are needed or > not... (assuming the update system will figure that out). > > Or should I keep separate '%{version}-%{rel

Re: Packaging Question

> > Question: Update time... I'm assuming that I should just > go ahead update both packages whether they are needed or > not... (assuming the update system will figure that out). > > Or should I keep separate '%{version}-%{release}' > for each package?? > > Again... Thank you very much for all the

Re: Packaging Question

On 10/27/2017 12:17 PM, Mattias Ellert wrote: > fre 2017-10-27 klockan 11:47 -0400 skrev Steve Dickson: >> >> This makes sense but the reason the libnfsidmap-devel package is not >> be upgraded (or installed) is because: >> >> dnf install /tmp/libnfsidmap-devel* >> Last metadata expiration check:

Re: Packaging Question

On Fri, Oct 27, 2017 at 12:25 PM Steve Dickson wrote: > > > On 10/27/2017 11:47 AM, Steve Dickson wrote: > > Hello, > > > > On 10/27/2017 11:11 AM, Stephen Gallagher wrote: > >> > >> > >> On Fri, Oct 27, 2017 at 10:55 AM Steve Dickson > wrote: > >> > >> Hello all, >

Re: Packaging Question

On 10/27/2017 11:47 AM, Steve Dickson wrote: > Hello, > > On 10/27/2017 11:11 AM, Stephen Gallagher wrote: >> >> >> On Fri, Oct 27, 2017 at 10:55 AM Steve Dickson > > wrote: >> >> Hello all, >> >> Again thanks for the help!!! >> >> On 10/26/2017 09:09 PM, Ke

Re: Packaging Question

fre 2017-10-27 klockan 11:47 -0400 skrev Steve Dickson: > > This makes sense but the reason the libnfsidmap-devel package is not > be upgraded (or installed) is because: > > dnf install /tmp/libnfsidmap-devel* > Last metadata expiration check: 0:10:48 ago on Fri 27 Oct 2017 11:19:35 AM > EDT. >

Re: Packaging Question

Steve Dickson wrote: > This makes sense but the reason the libnfsidmap-devel package is not > be upgraded (or installed) is because: > > dnf install /tmp/libnfsidmap-devel* > Last metadata expiration check: 0:10:48 ago on Fri 27 Oct 2017 11:19:35 AM > EDT. Error: > Problem: conflicting requests >

Re: Packaging Question

Hello, On 10/27/2017 11:11 AM, Stephen Gallagher wrote: > > > On Fri, Oct 27, 2017 at 10:55 AM Steve Dickson > wrote: > > Hello all, > > Again thanks for the help!!! > > On 10/26/2017 09:09 PM, Kevin Kofler wrote: > > William Moreno wrote: > >> P

Re: Packaging Question

On Fri, Oct 27, 2017 at 10:55 AM Steve Dickson wrote: > Hello all, > > Again thanks for the help!!! > > On 10/26/2017 09:09 PM, Kevin Kofler wrote: > > William Moreno wrote: > >> Provides: libnfsidmap-devel%{_isa} = %{epoch}:%{version}-%{release} > >> > >> Move this line under > >> > >> %package

Re: Packaging Question

Hello all, Again thanks for the help!!! On 10/26/2017 09:09 PM, Kevin Kofler wrote: > William Moreno wrote: >> Provides: libnfsidmap-devel%{_isa} = %{epoch}:%{version}-%{release} >> >> Move this line under >> >> %package -n libnfsidmap-devel >> >> And you should get a clean update path > > As H

Re: Packaging Question

On 10/26/2017 09:40 PM, Stephen Gallagher wrote: > > > On Thu, Oct 26, 2017 at 9:12 PM Kevin Kofler > wrote: > > William Moreno wrote: > > Provides: libnfsidmap-devel%{_isa} = %{epoch}:%{version}-%{release} > > > > Move this line under > > >

Re: Packaging Question

On Thu, Oct 26, 2017 at 9:12 PM Kevin Kofler wrote: > William Moreno wrote: > > Provides: libnfsidmap-devel%{_isa} = %{epoch}:%{version}-%{release} > > > > Move this line under > > > > %package -n libnfsidmap-devel > > > > And you should get a clean update path > > As Hedayat Vatankhah pointed ou

Re: Packaging Question

William Moreno wrote: > Provides: libnfsidmap-devel%{_isa} = %{epoch}:%{version}-%{release} > > Move this line under > > %package -n libnfsidmap-devel > > And you should get a clean update path As Hedayat Vatankhah pointed out, if the package is called libnfsidmap- devel, it does not actually n

Re: Packaging Question

*William Moreno Reyes* Colaborador Proyecto Fedora | Nicaragua IRC: williamjmorenor Canales: #fedora-latam ; #fedora-ni https://fedoraproject.org/wiki/User:Williamjmorenor 2017-10-26 12:10 GMT-06:00 Steve Dickson : > Hello, > > On 10/26/2017 09:57 AM, Steve Dickson wrote: > > Hello, > > > > In a

Re: Packaging Question

Hi, That's probably due to the Provides: libnfsidmap%{_isa} = %{epoch}:%{version}-%{release} Provides: libnfsidmap-devel%{_isa} = %{epoch}:%{version}-%{release} (not the energy to actually check) From: https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages (did I

Re: Packaging Question

Hi, /*Steve Dickson*/ wrote on Thu, 26 Oct 2017 14:10:49 -0400: Hello, On 10/26/2017 09:57 AM, Steve Dickson wrote: Hello, In an upcoming release the libnfsdimap library will be rolled into the nfs-utils package. Meaning nfs-utils will be install libnfsidmap instead of the libnfsidmap package

Re: Packaging Question

Hello, On 10/26/2017 09:57 AM, Steve Dickson wrote: > Hello, > > In an upcoming release the libnfsdimap library > will be rolled into the nfs-utils package. > Meaning nfs-utils will be install libnfsidmap > instead of the libnfsidmap package. > > The libnfsidmap name will stay the same > so I'

Re: Packaging Question

On Thu, Oct 26, 2017 at 10:00 AM Steve Dickson wrote: > Hello, > > In an upcoming release the libnfsdimap library > will be rolled into the nfs-utils package. > Meaning nfs-utils will be install libnfsidmap > instead of the libnfsidmap package. > > The libnfsidmap name will stay the same > so I'm

Re: Packaging Question

On Thu, Oct 26, 2017 at 08:09:00AM -0600, William Moreno wrote: > *William Moreno Reyes* > Colaborador Proyecto Fedora | Nicaragua > IRC: williamjmorenor Canales: #fedora-latam ; #fedora-ni > https://fedoraproject.org/wiki/User:Williamjmorenor > > 2017-10-26 7:57 GMT-06:00 Steve Dickson : > > >

Re: Packaging Question

*William Moreno Reyes* Colaborador Proyecto Fedora | Nicaragua IRC: williamjmorenor Canales: #fedora-latam ; #fedora-ni https://fedoraproject.org/wiki/User:Williamjmorenor 2017-10-26 7:57 GMT-06:00 Steve Dickson : > Hello, > > In an upcoming release the libnfsdimap library > will be rolled into

Packaging Question

Hello, In an upcoming release the libnfsdimap library will be rolled into the nfs-utils package. Meaning nfs-utils will be install libnfsidmap instead of the libnfsidmap package. The libnfsidmap name will stay the same so I'm hoping there will not be any problems. Just the owner of the library

Re: per-product packaging question

On 02/01/2017 10:48 AM, Daniel J Walsh wrote: > > > On 02/01/2017 09:58 AM, Stephen Gallagher wrote: >> On 01/30/2017 05:03 PM, Vivek Goyal wrote: >>> On Mon, Jan 30, 2017 at 05:00:34PM -0500, Lokesh Mandvekar wrote: Hi, I'm looking at the per-product packaging doc at https://

Re: per-product packaging question

On 02/01/2017 09:58 AM, Stephen Gallagher wrote: > On 01/30/2017 05:03 PM, Vivek Goyal wrote: >> On Mon, Jan 30, 2017 at 05:00:34PM -0500, Lokesh Mandvekar wrote: >>> Hi, >>> >>> I'm looking at the per-product packaging doc at >>> https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration

Re: per-product packaging question

On 01/31/2017 09:15 AM, Daniel J Walsh wrote: > We should just install one default in the default location, We don't > want to document to users the difference > > During post install the content can be modified based on the package. > > Please do not do this. It will react badly to future pac

Re: per-product packaging question

On 02/01/2017 09:58 AM, Stephen Gallagher wrote: > Given that this is never going to happen (we decided that changing the config > implicitly is a bad idea), I should update the policy to recommend using > copies > rather than symlinks and keeping the variant configs in /usr/share instead of > in

Re: per-product packaging question

On 01/30/2017 05:03 PM, Vivek Goyal wrote: > On Mon, Jan 30, 2017 at 05:00:34PM -0500, Lokesh Mandvekar wrote: >> Hi, >> >> I'm looking at the per-product packaging doc at >> https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration >> and I see that variants for all products are installed

Re: per-product packaging question

We should just install one default in the default location, We don't want to document to users the difference During post install the content can be modified based on the package. On 01/30/2017 05:03 PM, Vivek Goyal wrote: > On Mon, Jan 30, 2017 at 05:00:34PM -0500, Lokesh Mandvekar wrote: >> H

Re: per-product packaging question

On Mon, Jan 30, 2017 at 05:00:34PM -0500, Lokesh Mandvekar wrote: > Hi, > > I'm looking at the per-product packaging doc at > https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration > and I see that variants for all products are installed at package install > time, with > the ghost fil

per-product packaging question

Hi, I'm looking at the per-product packaging doc at https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration and I see that variants for all products are installed at package install time, with the ghost file pointing to the appropriate product variant. Just wondering if there's a reas

Re: Packaging question on MPI requires

Sandro Mani writes: >> I think that depends on whether you want to enable anything other than >> C(++), Python, and Fortran MPI packages (generally, not specifically in >> relation to the dependency stuff). I know I should have raised this >> before and probably somewhere else... > I suppose one

Re: Packaging question on MPI requires

On 27.10.2015 17:50, Dave Love wrote: Zbigniew Jędrzejewski-Szmek writes: I think this thread is getting too speculative: after all, we're talking mostly about agreeing on a few directories. Is there something broken that we should fix? Zbyszek I think that depends on whether you want to e

Re: Packaging question on MPI requires

Zbigniew Jędrzejewski-Szmek writes: > I think this thread is getting too speculative: after all, we're > talking mostly about agreeing on a few directories. > Is there something broken that we should fix? > > Zbyszek I think that depends on whether you want to enable anything other than C(++), P

Re: Packaging question on MPI requires

On Mon, Oct 26, 2015 at 10:34:17PM +, Dave Love wrote: > Zbigniew Jędrzejewski-Szmek writes: > > >> Surely this isn't scalable. What would happen with a common API for N > >> different Scheme implementations, for instance? I'm also interested in > >> Haskell; others might want the bindings

Re: Packaging question on MPI requires

Zbigniew Jędrzejewski-Szmek writes: >> Surely this isn't scalable. What would happen with a common API for N >> different Scheme implementations, for instance? I'm also interested in >> Haskell; others might want the bindings to Common Lisp, ruby, Tcl... >> Currently CLASSPATH isn't set for the

Re: Packaging question on MPI requires

On Fri, Oct 23, 2015 at 11:48:09AM +0100, Dave Love wrote: > At least I'd have > thought there needs to be some sort of hook for extensibility. This is be good idea. If it would be enough to add directories to the scan list in the dependency generator script. > Zbigniew Jędrzejewski-Szmek writes

Re: Packaging question on MPI requires

Zbigniew Jędrzejewski-Szmek writes: >> What are you supposed to do with MPI packaging for another language such >> as R? By the sound of it >> >> and friends will fail now. > As a short-term solution, it is always possible

Re: Packaging question on MPI requires

On Thu, Oct 22, 2015 at 10:38:53PM +0100, Dave Love wrote: > Sandro Mani writes: > > > On 22.10.2015 16:54, Sandro Mani wrote: > > > So the package is installing pynestkernel.so in > > /usr/lib64/python2.7/site-packages/nest/pynestkernel.so. However, the > > dependency generator expects MPI-enab

Re: Packaging question on MPI requires

Sandro Mani writes: > On 22.10.2015 16:54, Sandro Mani wrote: > So the package is installing pynestkernel.so in > /usr/lib64/python2.7/site-packages/nest/pynestkernel.so. However, the > dependency generator expects MPI-enabled binaries to be in one of > several known MPI directories, which are >

Re: Packaging question on MPI requires

On Thu, 2015-10-22 at 17:27 +0200, Sandro Mani wrote: > So the package is installing pynestkernel.so in > /usr/lib64/python2.7/site-packages/nest/pynestkernel.so. However, the > dependency generator expects MPI-enabled binaries to be in one of > several known MPI directories, which are > > $MPI_

Re: Packaging question on MPI requires

On 22.10.2015 16:54, Sandro Mani wrote: On 22.10.2015 16:49, Ankur Sinha wrote: Hiya, I recently packaged up nest[0] which is widely used in the computational neuroscience research community. The review ticket is here[1], and the copr builds are here[2]. Even though the rpm builds perfectly

Re: Packaging question on MPI requires

On 22.10.2015 16:49, Ankur Sinha wrote: Hiya, I recently packaged up nest[0] which is widely used in the computational neuroscience research community. The review ticket is here[1], and the copr builds are here[2]. Even though the rpm builds perfectly, dnf won't install them from the copr. Thi

Packaging question on MPI requires

Hiya, I recently packaged up nest[0] which is widely used in the computational neuroscience research community. The review ticket is here[1], and the copr builds are here[2]. Even though the rpm builds perfectly, dnf won't install them from the copr. This is what I get: > [asinha@cs-as14aho-2-he

Re: Packaging question about -Wformat-security on Rawhide

On 02/04/2014 05:31 AM, Dan Mashal wrote: On Mon, Feb 3, 2014 at 8:16 PM, Michael Catanzaro wrote: On Mon, 2014-02-03 at 19:42 -0700, Orion Poplawski wrote: I'm not sure why the default -Wall is being dropped from that line (it is on other tests). It's explicitly dropped on configure.ac:1265

Re: Packaging question about -Wformat-security on Rawhide

On Mon, Feb 3, 2014 at 8:16 PM, Michael Catanzaro wrote: > On Mon, 2014-02-03 at 19:42 -0700, Orion Poplawski wrote: >> I'm not sure why the default -Wall is being >> dropped from that line (it is on other tests). > > It's explicitly dropped on configure.ac:1265 > > dnl We enable -Wall lat

Re: Packaging question about -Wformat-security on Rawhide

On Mon, 2014-02-03 at 19:42 -0700, Orion Poplawski wrote: > I'm not sure why the default -Wall is being > dropped from that line (it is on other tests). It's explicitly dropped on configure.ac:1265 dnl We enable -Wall later. dnl If it's set after the warning CFLAGS in the compiler

Re: Packaging question about -Wformat-security on Rawhide

On Mon, Feb 3, 2014 at 6:42 PM, Orion Poplawski wrote: > The crux is that you need with -Wall or -Wformat as well on the compile > line test for perl.h. I'm not sure why the default -Wall is being > dropped from that line (it is on other tests). You might work around it > by explicitly adding -W

Re: Packaging question about -Wformat-security on Rawhide

On 02/03/2014 06:52 PM, Dan Mashal wrote: > Hi, > > So when rebuilding pidgin today I had issues building it for rawhide > and on my local machine (F20). > > Basically this flag is causing the configure script to not be able to > locate perl.h > > Looked at https://fedoraproject.org/wiki/Format-

Packaging question about -Wformat-security on Rawhide

Hi, So when rebuilding pidgin today I had issues building it for rawhide and on my local machine (F20). Basically this flag is causing the configure script to not be able to locate perl.h Looked at https://fedoraproject.org/wiki/Format-Security-FAQ but it is very vague and doesn't provide many e

Re: PHP packaging question: pear or not pear ?

On Wed, 2011-02-02 at 19:20 +0100, Remi Collet wrote: > Le 02/02/2011 14:09, Patrick MONNERAT a écrit : > > > > There is a project I would like to package: this is > > http://php-yubico.googlecode.com/. This project is using PEAR support > > and assumes a PEAR installation (in the Auth subdirecto

Re: PHP packaging question: pear or not pear ?

Le 02/02/2011 14:09, Patrick MONNERAT a écrit : > > There is a project I would like to package: this is > http://php-yubico.googlecode.com/. This project is using PEAR support > and assumes a PEAR installation (in the Auth subdirectory), but it is > NOT available from the PEAR repository at http:/

PHP packaging question: pear or not pear ?

There is a project I would like to package: this is http://php-yubico.googlecode.com/. This project is using PEAR support and assumes a PEAR installation (in the Auth subdirectory), but it is NOT available from the PEAR repository at http://pear.php.net/. Should I package it as pear package (i.e.

Re: font dependency packaging question

Le mardi 31 août 2010 à 20:58 -0700, Carl Byington a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I have a package (ghemical) which requires a courier 12 font for use in > its xwindow gui. I clearly need some dependency that will drag in > > xorg-x11-fonts-ISO8859-1-100dpi > or >

Re: font dependency packaging question

On Tue, 2010-08-31 at 20:58 -0700, Carl Byington wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I have a package (ghemical) which requires a courier 12 font for use in > its xwindow gui. I clearly need some dependency that will drag in > > xorg-x11-fonts-ISO8859-1-100dpi > or > xorg

font dependency packaging question

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a package (ghemical) which requires a courier 12 font for use in its xwindow gui. I clearly need some dependency that will drag in xorg-x11-fonts-ISO8859-1-100dpi or xorg-x11-fonts-ISO8859-1-75dpi but those probably depend on the actual user's