On Tue, Feb 26, 2019 at 06:54:22PM +0100, Birger Schacht wrote:
> I also tried to override PCDIR in d/rules, but when i do
> > dh_auto_install --
> PCDIR=${DESTDIR}/usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig
> the DESTDIR variable is empty.
Of course it's empty, just use the real
hi,
scdoc in its newest release installs a scdoc.pc file into
/usr/lib/pkgconfig. It does this by using
> install -Dm644 scdoc.pc $(PCDIR)/scdoc.pc
in the Makefile [0], where
> PCDIR?=$(_INSTDIR)/lib/pkgconfig
and
> _INSTDIR=$(DESTDIR)$(PREFIX)
I've tried several attempts to ma
!/bin/sh
set -e
# Automatically added by dh_installdeb/11.3.5
dpkg-maintscript-helper symlink_to_dir
/usr/lib/R/site-library/rmarkdown/rmd/h/bootstrap-3.3.5
../../../../../../share/javascript/bootstrap 1.10\+dfsg-2 -- "$@"
# End automatically added section
My question to debian-mentors
On 12/06/2016 11:45 PM, James Cowgill wrote:
> Hi,
>
> On 06/12/16 22:34, Christian Seiler wrote:
>> On 12/06/2016 11:22 PM, James Cowgill wrote:
>>> The version number should be the version number immediately before the
>>> one where the dpkg-maintscript stuff is added, not when the symlink was
>
Hi,
On 06/12/16 22:34, Christian Seiler wrote:
> On 12/06/2016 11:22 PM, James Cowgill wrote:
>> The version number should be the version number immediately before the
>> one where the dpkg-maintscript stuff is added, not when the symlink was
>> converted to a directory.
>>
>> In this case you pro
: debian...@lists.debian.org
>>> Usertags: piuparts
>>>
>>> ...
>>> >From the attached log (usually somewhere in the middle...):
>>>
>>> 2m19.9s INFO: dirname part contains a symlink:
>>> /usr/lib/R/site-library/RCurl/examples/C
t;> >From the attached log (usually somewhere in the middle...):
>>
>> 2m19.9s INFO: dirname part contains a symlink:
>> /usr/lib/R/site-library/RCurl/examples/CIS (r-cran-rcurl) !=
>> /usr/share/doc/r-cran-rcurl/examples/CIS (?)
>> /usr/lib/R/site-libra
> 2m19.9s INFO: dirname part contains a symlink:
> /usr/lib/R/site-library/RCurl/examples/CIS (r-cran-rcurl) !=
> /usr/share/doc/r-cran-rcurl/examples/CIS (?)
> /usr/lib/R/site-library/RCurl/examples ->
> ../../../../share/doc/r-cran-rcurl/examples
> /usr/lib/R/
Giulio,
On 18 May 2016 at 07:15, Giulio Paci wrote:
> One approach that usually fits my needs is the one proposed by Thibaut
> Paumard [1], that I am reproposing here with minimal changes:
Thanks for sharing this pretty detailed case. As my issue with
"pythonpy" was way more simpler, I ended up
on the state of upstream.
I agree with Ben, that it depends on the package.
One approach that usually fits my needs is the one proposed by Thibaut Paumard
[1], that I am reproposing here with minimal changes:
1) install the binaries with the original names into /usr/lib//bin
2) install a small
ian
> Policy Manual and it states that the need to put object files,
> internal binaries and libraries under "/lib{,32}" and "/usr/lib{,32}"
> is a requirement - however, it doesn't says how this should be done.
Right. Debian Policy states how things should be; it
e for other
packages? I was looking at § 9.1.1 File System Structure[1] from the
Debian Policy Manual and it states that the need to put object files,
internal binaries and libraries under "/lib{,32}" and "/usr/lib{,32}"
is a requirement - however, it doesn't says how this s
itself, then why keep it in /usr/bin?
>
> As "/usr/lib/" is not part of $PATH, how should we deal with this?
> Patch every process call to the internal binaries in the upstream
> source? Or is there an easier way to work around this?
How many process calls are there? The id
Hi Mattia,
(Moving the discussion from BTS to "debian-mentors" mailing list.)
On 15 May 2016 at 20:25, Mattia Rizzolo wrote:
> In this case the binary should go into /usr/lib instead. That place
> exist exactly for this reason:
> "/usr/lib includes object files,
On Mon, Mar 10, 2014 at 10:50:07AM +, Wookey wrote:
> +++ Thibaut Paumard [2014-03-10 10:59 +0100]:
> > Actually one way to go would be to upload the package without making the
> > split, downloading all the binaries, and comparing the files. This is
> > easier than manually building on porterb
On Mon, Mar 10, 2014 at 1:44 PM, Russ Allbery wrote:
> Jakub Wilk writes:
>> * Andrey Rahmatullin , 2014-03-10, 20:24:
>
>>> I also wonder if finding an arch-indep file in /usr/lib should result
>>> in an RC bug.
>
>> No. We should relax the policy to m
Jakub Wilk writes:
> * Andrey Rahmatullin , 2014-03-10, 20:24:
>> I also wonder if finding an arch-indep file in /usr/lib should result
>> in an RC bug.
> No. We should relax the policy to match the current practice.
I concur -- I really doubt this is important enough t
On Mon, Mar 10, 2014 at 03:51:01PM +0100, Jakub Wilk wrote:
> >I also wonder if finding an arch-indep file in /usr/lib should
> >result in an RC bug.
> No. We should relax the policy to match the current practice.
On Mon, Mar 10, 2014 at 03:40:33PM +0100, Оlе Ѕtrеісhеr wrote:
>
To some extent:
http://lintian.debian.org/tags/image-file-in-usr-lib.html
I also wonder if finding an arch-indep file in /usr/lib should result
in an RC bug.
No. We should relax the policy to match the current practice.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.o
Andrey Rahmatullin writes:
> On Mon, Mar 10, 2014 at 11:39:22AM +0100, Оlе Ѕtrеісhеr wrote:
>> >> >> I am packaging some older software (eso-midas, [1]) that installs
>> >> >> everything into a common directory (f.e. /usr/lib/eso-midas/). However,
>&g
On Mon, Mar 10, 2014 at 11:39:22AM +0100, Оlе Ѕtrеісhеr wrote:
> >> >> I am packaging some older software (eso-midas, [1]) that installs
> >> >> everything into a common directory (f.e. /usr/lib/eso-midas/). However,
> >> >> the FHS requires that
+++ Оlе Ѕtrеісhеr [2014-03-10 11:39 +0100]:
> Andrey Rahmatullin writes:
>
> > On Mon, Mar 10, 2014 at 10:54:44AM +0100, Оlе Ѕtrеісhеr wrote:
> >> >> I am packaging some older software (eso-midas, [1]) that installs
> >> >> everything into a common dir
+++ Thibaut Paumard [2014-03-10 10:59 +0100]:
> Hi,
>
> Le 10/03/2014 10:45, Andrey Rahmatullin a écrit :
> > On Mon, Mar 10, 2014 at 10:19:29AM +0100, Thibaut Paumard wrote:
> >> What I would try is to compile the package on two distinct architectures
> >> (or more) and compare the result. That w
Andrey Rahmatullin writes:
> On Mon, Mar 10, 2014 at 10:54:44AM +0100, Оlе Ѕtrеісhеr wrote:
>> >> I am packaging some older software (eso-midas, [1]) that installs
>> >> everything into a common directory (f.e. /usr/lib/eso-midas/). However,
>> >> the
if it is big)
- midas-doc (if it is big, else with -common)
If MIDAS supports plug-ins (that, I don't know), then you could put the
files that are needed only for compiling extensions in midas-dev.
> I was looking for an automated way. I would just do the following:
>
> * put al
On Mon, Mar 10, 2014 at 10:54:44AM +0100, Оlе Ѕtrеісhеr wrote:
> >> I am packaging some older software (eso-midas, [1]) that installs
> >> everything into a common directory (f.e. /usr/lib/eso-midas/). However,
> >> the FHS requires that this should be split between /u
Hi,
Le 10/03/2014 10:45, Andrey Rahmatullin a écrit :
> On Mon, Mar 10, 2014 at 10:19:29AM +0100, Thibaut Paumard wrote:
>> What I would try is to compile the package on two distinct architectures
>> (or more) and compare the result. That would work unless the build for
>> these files is non-deter
Andrey Rahmatullin writes:
> On Sat, Mar 08, 2014 at 02:02:48PM +0100, Оlе Ѕtrеісhеr wrote:
>> I am packaging some older software (eso-midas, [1]) that installs
>> everything into a common directory (f.e. /usr/lib/eso-midas/). However,
>> the FHS requires that this should
Thibaut Paumard writes:
> Le 08/03/2014 14:02, Оlе Ѕtrеісhеr a écrit :
>> Hi,
>>
>> I am packaging some older software (eso-midas, [1]) that installs
>> everything into a common directory (f.e. /usr/lib/eso-midas/). However,
>> the FHS requires that this should
On Sat, Mar 08, 2014 at 02:02:48PM +0100, Оlе Ѕtrеісhеr wrote:
> I am packaging some older software (eso-midas, [1]) that installs
> everything into a common directory (f.e. /usr/lib/eso-midas/). However,
> the FHS requires that this should be split between /usr/share/ and
> /usr/lib
On Mon, Mar 10, 2014 at 10:19:29AM +0100, Thibaut Paumard wrote:
> What I would try is to compile the package on two distinct architectures
> (or more) and compare the result. That would work unless the build for
> these files is non-deterministic or includes timestamps or information
> on the buil
Le 08/03/2014 14:02, Оlе Ѕtrеісhеr a écrit :
> Hi,
>
> I am packaging some older software (eso-midas, [1]) that installs
> everything into a common directory (f.e. /usr/lib/eso-midas/). However,
> the FHS requires that this should be split between /usr/share/ and
> /usr/lib//.
]) that installs
>>>>>> everything into a common directory (f.e. /usr/lib/eso-midas/). However,
>>>>>> the FHS requires that this should be split between /usr/share/ and
>>>>>> /usr/lib//. In the majority of cases, this could be done
>>>&
W dniu 09.03.2014 16:55, Оlе Ѕtrеісhеr pisze:
> Osamu Aoki writes:
>> On Sat, Mar 08, 2014 at 08:47:41PM +0100, Оlе Ѕtrеісhеr wrote:
>>> Bartosz Feński writes:
>>>>> I am packaging some older software (eso-midas, [1]) that installs
>>>>> every
Osamu Aoki writes:
> On Sat, Mar 08, 2014 at 08:47:41PM +0100, Оlе Ѕtrеісhеr wrote:
>> Bartosz Feński writes:
>> >> I am packaging some older software (eso-midas, [1]) that installs
>> >> everything into a common directory (f.e. /usr/lib/eso-midas/). However,
On Sat, Mar 08, 2014 at 08:47:41PM +0100, Оlе Ѕtrеісhеr wrote:
> Bartosz Feński writes:
> >> I am packaging some older software (eso-midas, [1]) that installs
> >> everything into a common directory (f.e. /usr/lib/eso-midas/). However,
> >> the FHS requires that thi
Bartosz Feński writes:
>> I am packaging some older software (eso-midas, [1]) that installs
>> everything into a common directory (f.e. /usr/lib/eso-midas/). However,
>> the FHS requires that this should be split between /usr/share/ and
>> /usr/lib//. In the majority of c
W dniu 08.03.2014 14:02, Оlе Ѕtrеісhеr pisze:
> Hi,
>
> I am packaging some older software (eso-midas, [1]) that installs
> everything into a common directory (f.e. /usr/lib/eso-midas/). However,
> the FHS requires that this should be split between /usr/share/ and
> /usr/lib//.
Hi,
I am packaging some older software (eso-midas, [1]) that installs
everything into a common directory (f.e. /usr/lib/eso-midas/). However,
the FHS requires that this should be split between /usr/share/ and
/usr/lib//. In the majority of cases, this could be done
automatically by recognizing
On 08/27/2012 11:35 PM, Alex Korobkin wrote:
> On 27 August 2012 15:03, Paul Gevers wrote:
>>> `/usr/lib/x86_64-linux-gnu/libcupsfilters.so.1.0.0': Permission denied
>>
>> You don't have permissions, obviously. This is because pbuilder runs
>> under the pbu
On 27 August 2012 15:03, Paul Gevers wrote:
>> `/usr/lib/x86_64-linux-gnu/libcupsfilters.so.1.0.0': Permission denied
>
> You don't have permissions, obviously. This is because pbuilder runs
> under the pbuilder user, not under root.
>
>> drwxr-xr-x 37 roo
> `/usr/lib/x86_64-linux-gnu/libcupsfilters.so.1.0.0': Permission denied
You don't have permissions, obviously. This is because pbuilder runs
under the pbuilder user, not under root.
> drwxr-xr-x 37 root root 4096 Aug 27 18:30 /usr/lib
> drwxr-xr-x 14 root root 24576 Au
Hi all,
I'm building cups-filters 1.0.23 package with help of pbuilder, and it
gets stuck on libtool trying to install
/usr/lib/x86_64-linux-gnu/libcupsfilters.so.1.0.0
Here is the relevant part of log:
make[1]: Entering directory `/tmp/buildd/cups-filters-1.0.23'
make[2]: Entering
close 630167 2.8.4+dfsg.1-5
thanks
Hello,
On ketvirtadienis 23 Birželis 2011 14:20:59 Andreas Tille wrote:
> I tried to rebuild gofigure2 (which is affected by #629815) now I do
> not get the
>
>No rule to make target `/usr/lib/libdl.so', needed by
> `lib/libvtkRe
> released Ubuntu 11.04 (natty) already has this multiarch enabled so
> upstream cmake up to and including 2.8.4 is basically unusable on
> those systems. That's because libc6 package is multiarch enabled and
> e.g. vanilla cmake 2.8.4 is not even able to set CMAKE_DL_LIBS
> pr
kage with a symlink.
>>>
>>> Er no, this is not how dpkg behaves. It never converts symlinks to
>>> directories or vice versa, so the actual outcome is¹ that your file gets
>>> actually installed into /usr/lib through the symlink. This means that
>>> if
Russ Allbery writes:
> Sven Joachim writes:
>
>> Er no, this is not how dpkg behaves. It never converts symlinks to
>> directories or vice versa, so the actual outcome is¹ that your file gets
>> actually installed into /usr/lib through the symlink. This means th
ehaves. It never converts symlinks to
>> directories or vice versa, so the actual outcome is¹ that your file gets
>> actually installed into /usr/lib through the symlink. This means that
>> if another package starts shipping a file with the same name in
>> /usr/lib, dpkg
your file gets
> actually installed into /usr/lib through the symlink. This means that
> if another package starts shipping a file with the same name in
> /usr/lib, dpkg will not notice the file conflict which is bad.
Please read again. Nothing gets converted. dpkg just fails with a file
Sven Joachim writes:
> Er no, this is not how dpkg behaves. It never converts symlinks to
> directories or vice versa, so the actual outcome is¹ that your file gets
> actually installed into /usr/lib through the symlink. This means that
> if another package starts shipping a file w
e /usr/lib64 symlink and fail because you can not replace a directory
> of another package with a symlink.
Er no, this is not how dpkg behaves. It never converts symlinks to
directories or vice versa, so the actual outcome is¹ that your file gets
actually installed into /usr/lib through the symli
ng the
> requirement is not the same as forbidding.
Due to implementation issues (below) you MUST NOT ship any files in
/lib64 or /usr/lib64/ in the package.
>> Also note that /usr/lib64 is just a symlink to /usr/lib on Debian systems.
>>
>
> So that makes it a bit academic, a
On Thu, Jun 9, 2011 at 11:27 PM, Andreas Tille wrote:
> On Thu, Jun 09, 2011 at 01:02:56PM +0200, Sven Joachim wrote:
>> >> The problem is that libdl.so has been moved to the multiarch paths in
>> >> libc6-dev 2.13-5. You must upgrade cmake to 2.8.4+dfsg.1-3, have you
>> >> done that already?
>>
; Also note that /usr/lib64 is just a symlink to /usr/lib on Debian systems.
>
So that makes it a bit academic, at the moment.
cheers,
d
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.or
Le vendredi 10 juin 2011 00:38:12, David Bremner a écrit :
> On Thu, 09 Jun 2011 13:40:54 -0700, Russ Allbery wrote:
> > On Debian, you should always install into lib and never use lib64.
> > (Eventually, you may want to use the multiarch directory, but it will
> > still not be lib64.)
>
> That w
removed.
Also note that /usr/lib64 is just a symlink to /usr/lib on Debian systems.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe".
On Thu, 09 Jun 2011 13:40:54 -0700, Russ Allbery wrote:
>
> On Debian, you should always install into lib and never use lib64.
> (Eventually, you may want to use the multiarch directory, but it will
> still not be lib64.)
>
That was my first thought, but I couldn't find a straightforward
justif
On Thu, Jun 09, 2011 at 01:02:56PM +0200, Sven Joachim wrote:
> >> The problem is that libdl.so has been moved to the multiarch paths in
> >> libc6-dev 2.13-5. You must upgrade cmake to 2.8.4+dfsg.1-3, have you
> >> done that already?
> >
> > I'm building an unstable pbuilder chroot. It is using
Richard Ulrich writes:
> I want to package a library which hast the following lines in
> CMakeLists.txt
> IF(CMAKE_SIZEOF_VOID_P EQUAL 8)
> SET(LIBDIR lib64)
> ELSE (CMAKE_SIZEOF_VOID_P EQUAL 8)
> SET(LIBDIR lib)
> ENDIF(CMAKE_SIZEOF_VOID_P EQUAL 8)
> now, how do I have to handle this i
Hi Mentors,
I want to package a library which hast the following lines in
CMakeLists.txt
IF(CMAKE_SIZEOF_VOID_P EQUAL 8)
SET(LIBDIR lib64)
ELSE (CMAKE_SIZEOF_VOID_P EQUAL 8)
SET(LIBDIR lib)
ENDIF(CMAKE_SIZEOF_VOID_P EQUAL 8)
now, how do I have to handle this in debian/libxyz.install?
Rg
Hi,
in case people might wonder about strange FTBFS like #629815 (which does
not seem to be the only bug of this type): There is a fair chance that this
will solve with some (future?) cmake package version. Just to let you know
before everybody needs to do the same investigation ...
On Thu, Jun
On 2011-06-09 11:19 +0200, Andreas Tille wrote:
> On Thu, Jun 09, 2011 at 10:00:40AM +0200, Sven Joachim wrote:
>>
>> The problem is that libdl.so has been moved to the multiarch paths in
>> libc6-dev 2.13-5. You must upgrade cmake to 2.8.4+dfsg.1-3, have you
>> done that already?
>
> I'm buildi
Thank you for the additional information you have supplied regarding
this Bug report.
This is an automatically generated reply to let you know your message
has been received.
Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will rep
On Thu, Jun 09, 2011 at 10:00:40AM +0200, Sven Joachim wrote:
> > However, the problem I was facing in the not yet released package
> > ginkocadx[1] seems to be quite common currently. It is in #629815 and
> > some similar case happens in #618094 and thus I'm suspecting a general
> > problem someh
On 2011-06-09 08:11 +0200, Andreas Tille wrote:
> On Wed, Jun 08, 2011 at 11:28:52PM +0200, Andreas Tille wrote:
>> On Wed, Jun 08, 2011 at 11:26:22AM +0200, Andreas Tille wrote:
>> > make[3]: *** No rule to make target `/usr/lib/libdl.so', needed by
>> > `src
On Wed, Jun 08, 2011 at 11:28:52PM +0200, Andreas Tille wrote:
> On Wed, Jun 08, 2011 at 11:26:22AM +0200, Andreas Tille wrote:
> > make[3]: *** No rule to make target `/usr/lib/libdl.so', needed by
> > `src/cadxcore/libCADxCore.so.2.4.1.1'. Stop.
>
> I sus
May 06, 2006, Miriam Ruiz wrote:
> > > /bin/sed: can't read /usr/lib/libXcursor.la: No such file or directory
> > > libtool: link: `/usr/lib/libXcursor.la' is not a valid libtool archive
> >
> > grep -l Xcursor.la /usr/lib/*.la
> > will list the
Hi
Loïc Minier wrote (Sunday 07 May 2006 6:48 am):
> On Sat, May 06, 2006, Miriam Ruiz wrote:
> > /bin/sed: can't read /usr/lib/libXcursor.la: No such file or directory
> > libtool: link: `/usr/lib/libXcursor.la' is not a valid libtool archive
>
> grep -l Xcurso
Hi,
On Sat, May 06, 2006, Miriam Ruiz wrote:
> /bin/sed: can't read /usr/lib/libXcursor.la: No such file or directory
> libtool: link: `/usr/lib/libXcursor.la' is not a valid libtool archive
grep -l Xcursor.la /usr/lib/*.la
will list the libtool archives which stil
Hi,
I'm getting some errors building gnash when reaching the linking step:
ranlib .libs/libgnashbackend.a
creating libgnashbackend.la
/bin/sed: can't read /usr/lib/libXcursor.la: No such file or directory
libtool: link: `/usr/lib/libXcursor.la' is not a valid libtool archive
Talk
I'm packaging polipo, the web proxy.
To help with starting, stopping etc. I wrote a helper script
"polipo-control" that I put in /usr/lib/polipo/. It is called by
/etc/init.d/polipo.
How can I make this script executable? Can I get dh_install or another
debhelper script to d
I'm packaging polipo, the web proxy.
To help with starting, stopping etc. I wrote a helper script
"polipo-control" that I put in /usr/lib/polipo/. It is called by
/etc/init.d/polipo.
How can I make this script executable? Can I get dh_install or another
debhelper script to d
Matt Zimmerman <[EMAIL PROTECTED]> wrote:
>> This should probably be a bug on packaging-manual if the bug is still
>> present in the most recent document.
>
> Er, packaging-manual doesn't exist anymore, of course. mime-policy is part
> of the policy manual, yes?
Not quite, but you are close. It
Matt Zimmerman <[EMAIL PROTECTED]> wrote:
>> This should probably be a bug on packaging-manual if the bug is still
>> present in the most recent document.
>
> Er, packaging-manual doesn't exist anymore, of course. mime-policy is part
> of the policy manual, yes?
Not quite, but you are close. It
On Mon, Sep 22, 2003 at 02:39:45PM -0400, Matt Zimmerman wrote:
> On Mon, Sep 22, 2003 at 11:50:43AM +0200, Florent Rougon wrote:
> > BTW: the file
> > ftp://ftp.debian.org/debian/doc/package-developer/mime_policy.txt.gz
> > referenced on
> > http://www.debian.org/doc/packaging-manu
.
>
> linda complains because my package is "Architecture: all" and puts
> things in /usr/lib.
>
> I think it is not impossible, although unlikely, to have packages
> register arch-specific MIME entries (think of a viewer written in
> assembly for $ARCH...). Therefore,
On Mon, Sep 22, 2003 at 02:39:45PM -0400, Matt Zimmerman wrote:
> On Mon, Sep 22, 2003 at 11:50:43AM +0200, Florent Rougon wrote:
> > BTW: the file
> > ftp://ftp.debian.org/debian/doc/package-developer/mime_policy.txt.gz
> > referenced on
> > http://www.debian.org/doc/packaging-manu
.
>
> linda complains because my package is "Architecture: all" and puts
> things in /usr/lib.
>
> I think it is not impossible, although unlikely, to have packages
> register arch-specific MIME entries (think of a viewer written in
> assembly for $ARCH...). Therefore,
Hello,
I have a package that uses dh_installmime to put a file in
/usr/lib/mime/packages/ so as to register itself for some MIME types.
>From the man pages (update-mime(8) and dh_installmime(1)) and the Debian
MIME support sub-policy at
http://www.debian.org/doc/packaging-manuals/mime-policy/
Hello,
I have a package that uses dh_installmime to put a file in
/usr/lib/mime/packages/ so as to register itself for some MIME types.
>From the man pages (update-mime(8) and dh_installmime(1)) and the Debian
MIME support sub-policy at
http://www.debian.org/doc/packaging-manuals/mime-policy/
In message <[EMAIL PROTECTED]> yo
u write:
> On Tue, 20 May 2003, [iso-8859-1] Jörgen Hägg wrote:
>
> Have you considered /usr/share//cgi-bin and
> /usr/share//html and adding the necessary bits for Apache (and
> derivatives), and possibly any other webserver which users mention? There's
> pretty
On Tue, 20 May 2003, [iso-8859-1] J?rgen H?gg wrote:
> In message <[EMAIL PROTECTED]> yo
> u write:
>
> > What I am wondering is, apart from a webapp (which can afford the overhead
> > of scripting required to support inserting bits and bobs into webservers),
> > what sort of packages need to put
In message <[EMAIL PROTECTED]> yo
u write:
> What I am wondering is, apart from a webapp (which can afford the overhead
> of scripting required to support inserting bits and bobs into webservers),
> what sort of packages need to put webserver-accessible pages up?
That's exactly what it is, a web
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jörgen,
On Tue, May 20, 2003 at 08:40:58AM +0200, Jörgen Hägg wrote:
> But if there are several programs with short names that may
> collide with other packages, is it ok to
> put them in /usr/lib/cgi-bin/package-name/?
Yes. Be sure t
On Tue, 20 May 2003, [iso-8859-1] J?rgen H?gg wrote:
> > Nooo. /usr/share/doc must be removable without any untoward
> > effects on the operation of the system. /usr/share/ is the
> > place to be, with an appropriate alias linking (probably)
> > http://localhost// to /usr/share/.
>
In message <[EMAIL PROTECTED]>
you write:
>
> Nooo. /usr/share/doc must be removable without any untoward
> effects on the operation of the system. /usr/share/ is the
> place to be, with an appropriate alias linking (probably)
> http://localhost// to /usr/share/.
Is there a standar
On Tue, 20 May 2003, [iso-8859-1] J?rgen H?gg wrote:
> Another question is where to put html-pages that the package uses.
> (Not documentation)
>
> /var/www seems to be a bad place, the only reasonable
> is /usr/share/doc/package-name/xyz.html or
> /usr/share/doc/package-name/html/xyz.html and re
I've been searching the policy for guidance about cgi-scripts.
The only thing I find is that they should be placed in /usr/lib/cgi-bin.
But if there are several programs with short names that may
collide with other packages, is it ok to
put them in /usr/lib/cgi-bin/package-name/?
Or would
* Matt Zimmerman <[EMAIL PROTECTED]> wrote:
>> /usr/lib/eclipse and then set symlinks to the 'expected' places in
>> /usr/share/eclipse subdirs.
> That sounds fine. It would be even better if eclipse would look in FHSish
> locations for these things, b
On Wed, May 14, 2003 at 01:13:42AM +0200, Jan Schulz wrote:
> My current thinking is, that I will change the base directory from
> /usr/lib/eclipse to /usr/share/eclipse, but will put all 'arch
> dependet' code (about 10 files from various places) directly into
> /usr/li
Hello,
I'm the new maintainer of eclipse, a IDE written in java.
Eclipse is currently put into /usr/lib/eclipse directory, as eclipse
contains some JNI code, which is arch dependent. JNI nativ libs
(*so) are put into /usr/lib/jni (reusable parts: SWT) and subdirs
of /usr/lib/eclipse
Le Thu, Apr 24, 2003 at 09:47:38AM +0200, Jörgen Hägg écrivait:
> But if the perl-module has both binary and nonbinary files?
Then it's ok to leave the .pm where they have been installed in the
first place that's why it's only a warning and not an error.
> Should all files for a perl module r
Lintian complains about .pm-files in /usr/lib/perl5, it wants
to have them in /usr/share/perl5, which normally is correct.
But if the perl-module has both binary and nonbinary files?
(I'm trying to remove any warnings for libio-pty-perl. :-)
Should all files for a perl module reside i
On Mon, Nov 18, 2002 at 11:40:20AM +0100, Sven Luther wrote:
DB>> Sure, but it is not mandated in any kind of policy that they
DB>> should be. And it can't be mandated, or such policy would soon
DB>> become a mess with all the per-case clauses. I think "anything
DB>> that gets executed goes to
meone really doing this ?
> SL> Does dpkg/apt even allow this to work without breaking all kind of
> SL> things ?
>
> AFAIK yes, but I'm too lazy to prove this :)
Well, but it would be dependant of the package containing exactly the
same stuff on all arches.
I think the
On Mon, Nov 18, 2002 at 10:14:26AM +0100, Sven Luther wrote:
AS>>> "Ruby sucks". Ignore it. Arch-indep to share, arch-dep to lib,
AS>>> screw everything else.
DB>> That didn't convince me, neither in "Ruby sucks" part (all my packages
DB>> in Debian except Alicq are Ruby libraries :), nor in "a
On Mon, Nov 18, 2002 at 11:40:20AM +0100, Sven Luther wrote:
DB>> Sure, but it is not mandated in any kind of policy that they
DB>> should be. And it can't be mandated, or such policy would soon
DB>> become a mess with all the per-case clauses. I think "anything
DB>> that gets executed goes to
On Mon, Nov 18, 2002 at 11:00:21AM +0200, Dmitry Borodaenko wrote:
> On Sun, Nov 17, 2002 at 05:10:13AM +, Andrew Suffield wrote:
> SL>>> I imagine python stores everything in /usr/lib, again as a
> SL>>> practical concession to the fact that upstream installation
On Sun, Nov 17, 2002 at 05:10:13AM +, Andrew Suffield wrote:
SL>>> I imagine python stores everything in /usr/lib, again as a
SL>>> practical concession to the fact that upstream installation
SL>>> directories don't make it easy to use separate paths for
meone really doing this ?
> SL> Does dpkg/apt even allow this to work without breaking all kind of
> SL> things ?
>
> AFAIK yes, but I'm too lazy to prove this :)
Well, but it would be dependant of the package containing exactly the
same stuff on all arches.
I think the
1 - 100 of 161 matches
Mail list logo
