* Matt Brubeck <[EMAIL PROTECTED]> wrote [040409 12:42]:
> I think in most cases it is best if you simply install the files as part
> of package A, regardless of whether B is installed.
>
> For example, look at the packages "msql-server" and "ntpdate". Both of
> these contain support files for t
* Matt Brubeck <[EMAIL PROTECTED]> wrote [040409 12:42]:
> I think in most cases it is best if you simply install the files as part
> of package A, regardless of whether B is installed.
>
> For example, look at the packages "msql-server" and "ntpdate". Both of
> these contain support files for t
* Erik Bourget <[EMAIL PROTECTED]> wrote [040409 12:30]:
> I think that this final option is the only sane way. See the following
> scenarios that happen if beamer does install-time detection:
This sounds reasonable for me.
Now I need some starting point how to setup such a "multiple binary
pac
* Erik Bourget <[EMAIL PROTECTED]> wrote [040409 12:30]:
> I think that this final option is the only sane way. See the following
> scenarios that happen if beamer does install-time detection:
This sounds reasonable for me.
Now I need some starting point how to setup such a "multiple binary
pac
What is the best way to handle the following situation:
package A (unofficial "beamer" in my case) contains some support
files for an official package B ("lyx-common"). These support files have
to be copied into the directory tree of package B.
How can I determine at installation time whether pac
What is the best way to handle the following situation:
package A (unofficial "beamer" in my case) contains some support
files for an official package B ("lyx-common"). These support files have
to be copied into the directory tree of package B.
How can I determine at installation time whether pac
Tollef Fog Heen wrote on 010716 12:47 +0200:
> | > | - install the files into "/var/www/openwebschool"
> | >
> | > reasonable
> |
> | What is our policy regarding /var/www? I sort of thought this was a place
> | where local sys admins could install their sites without worrying about
> | bumping
Tollef Fog Heen wrote on 010716 12:47 +0200:
> | > | - install the files into "/var/www/openwebschool"
> | >
> | > reasonable
> |
> | What is our policy regarding /var/www? I sort of thought this was a place
> | where local sys admins could install their sites without worrying about
> | bumpin
I plan to - unofficially - package a set of HTML-Pages, CGI-scripts,
JavaScript-Code, etc. for the openwebschool project
(see http://www.openwebschool.de, german only!).
Here my intentions/questions:
- make the package dependend on "httpd"
- install the files into "/var/www/openwebschool"
- shou
I plan to - unofficially - package a set of HTML-Pages, CGI-scripts,
JavaScript-Code, etc. for the openwebschool project
(see http://www.openwebschool.de, german only!).
Here my intentions/questions:
- make the package dependend on "httpd"
- install the files into "/var/www/openwebschool"
- sho
What is the proposed handling of a package whose name has changed?
(e.g.: the author of foo-0.1.tar.gz, Debian package foo_0.1-1_i386.deb,
changes the name of the package to bar-0.2.tar.gz)
The only thing which comes to my mind is treating the old package
as 'conflict' for the new one, but there
What is the proposed handling of a package whose name has changed?
(e.g.: the author of foo-0.1.tar.gz, Debian package foo_0.1-1_i386.deb,
changes the name of the package to bar-0.2.tar.gz)
The only thing which comes to my mind is treating the old package
as 'conflict' for the new one, but there
Questions which arise for me in creating an unofficial Debian
package for a Python based script:
- the upstream Python script is called 'script.py'. Should I keep
the .py extension or drop it?
- should this script be installed in /usr/bin like any other
regular program?
- the upstream tarba
Questions which arise for me in creating an unofficial Debian
package for a Python based script:
- the upstream Python script is called 'script.py'. Should I keep
the .py extension or drop it?
- should this script be installed in /usr/bin like any other
regular program?
- the upstream tarb
How do I setup my environment for making a new - unofficial - Debian
package for some latex style files?
Michael
--
office: [EMAIL PROTECTED]
private: [EMAIL PROTECTED] http://www.miwie.org/
[EMAIL PROTECTED] http://wap.miwie.org/
How do I setup my environment for making a new - unofficial - Debian
package for some latex style files?
Michael
--
office: [EMAIL PROTECTED]
private: [EMAIL PROTECTED] http://www.miwie.org/
[EMAIL PROTECTED] http://wap.miwie.org/
--
To UNS
In creating an unofficial Debian Package on a Potato system I get the
following lintian info message, which I don't know how to get rid of:
$ lintian -iIv PACKAGE.dsc
...
I: PACKAGE source: unknown-field-in-dsc format
...
Checking the deb-file alone produces no info message so I supsect the
follo
In creating an unofficial Debian Package on a Potato system I get the
following lintian info message, which I don't know how to get rid of:
$ lintian -iIv PACKAGE.dsc
...
I: PACKAGE source: unknown-field-in-dsc format
...
Checking the deb-file alone produces no info message so I supsect the
foll
Decklin Foster wrote:
> $ apt-cache show rxvt | grep '^Provides: '
> Provides: x-terminal-emulator
Thanks!
But why is this not documented in 'virtual-package-names-list.text'?
Michael
-----
ent to have a 'virtual package name'
for this, since I really *don't* know any possible values for X11
terminal emulations.
Michael
----
Michael Wiedmann |
Cordless Technology A/S | Free yo
a
'suggestion'?
Michael
----
Michael Wiedmann |
Cordless Technology A/S | Free your computer,
Köpenicker Str. 180 | install Linux
D-10997 Berlin|
21 matches
Mail list logo
