> The technical committee has been asked to resolve the issue of what to do
> with /usr/share/doc. I propose we actually adopt their decision. I
> propose further that we don't bother to have discussion--we're past all
> that. The decision has been made and while possibly not the best one,
> it'
Chris Lawrence wrote:
> All packages are compliant with policy if they meet
> the requirements in the version of policy their Standards-Version
> indicates.
Since when? According to the policy manual:
You should specify the most recent version of the packaging standards
with which your
On Sep 23, Joey Hess wrote:
> Chris Lawrence wrote:
> > All packages are compliant with policy if they meet
> > the requirements in the version of policy their Standards-Version
> > indicates.
>
> Since when? According to the policy manual:
>
> You should specify the most recent version of t
Lintian is already ready to do rudimentary checks based on the debhelper
implementation.
On Fri, Sep 24, 1999 at 01:16:18AM +0100, Julian Gilbey wrote:
> > The technical committee has been asked to resolve the issue of what to do
> > with /usr/share/doc. I propose we actually adopt their decision
On Mon, Sep 20, 1999 at 02:30:52AM -0700, Joseph Carter wrote:
> As for the technical implementation of the tech-ctte decision, I propose
> we use joeyh's implementation found in any recently uploaded debhelper
> package.
Please clarify this. Preferably give the diff you want to be applied
to the
In file ch-scope.html is a reference to new versions which is a dead
link:
ftp://ftp.debian.org/debian/doc/manuals/debian-policy.html.tar.gz.
I found the document at
ftp://ftp.debian.org/debian/doc/package-developer/policy.html.tar.gz.
Greetings,
Steffen
> Lintian is already ready to do rudimentary checks based on the debhelper
> implementation.
>
> On Fri, Sep 24, 1999 at 01:16:18AM +0100, Julian Gilbey wrote:
> > > The technical committee has been asked to resolve the issue of what to do
> > > with /usr/share/doc. I propose we actually adopt th
The apparent solution to something like bug#45344 is to have all
the packages providing an identd to conflict with one another.
While reasonable in most cases, this has the horrible side effect
of not letting the administrator have multiple identds on the
system. What if I have a machine with t
>These packages don't conflict; they merely provide the same
> service. There is no reason that these three packages cannot
> coexist on the same system. Any namespace overlap can be
> solved by alternatives or renaming, as such things are normally
> rectified.
>Debian policy should prosc
Clint Adams wrote:
>Perhaps identd isn't an example to be taken seriously. So let's
> say that I have a POP server.
>These packages don't conflict; they merely provide the same
> service. There is no reason that these three packages cannot
> coexist on the same system. Any namespace ov
> Okay, then solve the problem of which one should actually work on the
> standard port? You can't use update-alternatives if the software is
Well, I would prefer that things didn't start listening for connections
without asking first, but I can't imagine that that's a popular suggestion.
> laun
> > Okay, then solve the problem of which one should actually work on the
> > standard port? You can't use update-alternatives if the software is
>
> Well, I would prefer that things didn't start listening for connections
> without asking first, but I can't imagine that that's a popular
suggestion
> Of course. Now if you built them yourself, dpkg wouldn't touch them.
If I wanted to build them myself, I would use Slackware.
If I repackage them I will need to remove the Conflicts line from
the control files every single time I upgrade.
> People who want such "complex" setups should have eno
Hi,
On Fri, 24 Sep 1999, Clint Adams wrote:
> I run apache and roxen on the same machine. That's hardly typical.
> Why on earth would anyone want to run two different web servers?
> These two packages should obviously conflict since they're both
> web servers and want to grab port 80.
I'd say t
> If you want to run two httpd's, popd's or mta's, you'll probably have to
> do more than the usual tweaking to the package setup anyway, so what is
> really the big deal of having to:
>
> 1. `apt-get source foo`
> 2. edit various files, mostly in debian/
> 3. add an epoch to the package versio
15 matches
Mail list logo
