intainer could have
picked any of them. Considering that two of the three modules start with
WWW::Curl, I think the maintainer made a logical choice.
--
---
#include
Matthew Palmer, Geek In Residence
http://ieee.uow.edu.au/~mjp16
cQPkZqb7ACffwIT
dbkNU5KpDYvaWmO39O7cQxo=
=hLHW
-END PGP SIGNATURE-
--
---
#include
Matthew Palmer, Geek In Residence
http://ieee.uow.edu.au/~mjp16
axis, and
"sharable" and "private" along the other.
(So much for swearing I wouldn't get involved in pissing matches any more)
--
Matthew Palmer, Debian Developer
[EMAIL PROTECTED] http://www.debian.org
but it needs a lot of flesh to it.
I'd prefer to see it move away from being an Apache Policy to being a web
content policy - that is, encompassing web servers, webapps, static content
(where packages should put stuff) and whatever else fits. Restricting it to
apache doesn't feel like the
uldn't have stepped where my expertise can't follow.
Let me ask another question - is this still a policy bug? When policy
mentions something which doesn't exist, I can understand that policy is
likely to be in error. But this is, IMO, a dpkg problem now.
--
Matthe
On Mon, 2 Sep 2002, Wichert Akkerman wrote:
> Previously Matthew Palmer wrote:
> > Since 1.10 is now out and about and (AFAICT) has sane support for Enhances,
> > I would suggest that this bug be considered closed.
>
> No, it doesn't.
Are you contesting 'support
nd apt supports it, policy should not
>mention it.
Since 1.10 is now out and about and (AFAICT) has sane support for Enhances,
I would suggest that this bug be considered closed.
--
Matthew Palmer, Debian Developer
[EMAIL PROTECTED] http://www.debian.org
On Mon, 2 Sep 2002, Manoj Srivastava wrote:
> Matthew> Based on the proposal's use of http://localhost/, or some
> Matthew> other criteria?
>
> Right now, if I arrange for images to be referenced in
> /var/www/, they are accessible elsewhere (I did something like that
> when I used to m
Debian. Not a big stick to beat people with (after all, this
is fun we're dealing with here) but rather something that people can look to
for a definitive answer.
Perhaps you guys are coping fine, but I have noticed a rather... spurtish
(is that the word?) trend in policy lately. Woul
to see the
amendment part of policy, and see no reason why it shouldn't be accepted.
--
Matthew Palmer, Debian Developer
[EMAIL PROTECTED] http://www.debian.org
than with the maintainer getting flamed to death
> for trashing everyone's configuration.
AFAIK Exim doesn't use debconf (although as soon as I can find time to learn
debconf, a bug+patch will be filed - I want Exim non-interactive).
--
-------
#include
Matthew Palmer
[EMAIL PROTECTED]
Maybe we should find out how it's _supposed_
> to be done before we make a final and binding decision, eh?
There is precedent (kind of), g++ uses /usr/include/g++, so why not
/usr/include/{gnat|ada}?
--
-------
#include
Matthew Palmer
[EMAIL PROTECTED]
atribe on the subject is:
http://www.w3.org/2001/03/14/StandardizedPackagingSystem/
which is, in my book, a very nice way of putting it. Unfortunately, it has
gone nowhere fast.
--
---
#include
Matthew Palmer
[EMAIL PROTECTED]
or 100% FHS compliance?
Since not everything in non-free has source anyway, I'd vote for FHS
compliance.
--
-------
#include
Matthew Palmer
[EMAIL PROTECTED]
suddenly you're wondering why it's asking for all
three CDs and listing stuff you've never heard of...
>
Indeed...
--
---
#include
Matthew Palmer
[EMAIL PROTECTED]
#x27;stable' which depends
on the stable version of every package, typing apt-get upgrade stable will
install every single package listed therein. Does anyone else have a
problem with that?
--
---
#include
Matthew Palmer
[EMAIL PROTECTED]
16 matches
Mail list logo