Andreas Barth <[EMAIL PROTECTED]> writes:
> Hi,
>
> I made a proposal of an updated deb format definition. I based that on
> the manpage deb (part of dpkg-dev), and on reverse engineering of
> dpkg-deb/build.c. I hope I've written the standard in a right and easy
> to understandable way. I did (b
Previously Andreas Barth wrote:
> IMHO this definition should become part of the policy; I propose
> either an new chapter 12, or an addition to chapter 3 Binary packages,
It should be part of the dpkg reference manual (partially online at
www.dpkg.org). Patches against the text as you can find in
On Sun, Dec 07, 2003 at 12:43:52PM -0500, Joey Hess wrote:
> Fabio Massimo Di Nitto wrote:
> > Even if it is not our task I would like to at least suggest users a common
> > schema on where to store vhosts and possibly in a future having a small
> > tool to handle them. It would make life easier fo
Hi,
I made a proposal of an updated deb format definition. I based that on
the manpage deb (part of dpkg-dev), and on reverse engineering of
dpkg-deb/build.c. I hope I've written the standard in a right and easy
to understandable way. I did (by purpose) not add anything about
signatures etc, but I
Joey Hess, 2003-12-06 21:20:19 +0100 :
> Maybe it's time to think about amending section 11.5. of policy (Web
> servers and applications) to address some of the problems with it. Here
> are the problems I know of:
[...]
> - If you use vhosts, you can only have one pointing to /var/www,
>so
Daniel Stone wrote:
> I'm not sure I love the /debian-www/ bit; it's a bit aesthetically
> displeasing, but to each their own. Good idea otherwise, however.
I agree, it is not the prettiest name. I considered just /debian/, but
it seemed more likely that would conflict with something on someone's
Fabio Massimo Di Nitto wrote:
> I am cross posting this answer but I think we should keep the
> discussion on one mailinglist only. I leave up to you which one you think
> is more appropriate.
I'd prefer debian-policy.
> > - Some web servers (eg apache2) can cooexist with other web servers
[half-reposted]
On Sun, Nov 30, 2003 at 04:32:09PM +1100, Herbert Xu wrote:
> However, epochs are designed so that they only need to be shown where
> it is necessary to establish the aboslute order between two arbitrary
> version numbers.
Hiding epochs actually has adverse effects (I've seen sever
On Thu, Dec 04, 2003 at 12:31:11AM +0100, Bill Allombert wrote:
> > Section 3.6.1.0 of policy recommends registering HTML documents with the
> > menu package. AFAIK this practice has been supersceded by doc-base.
> > Although oddly, I see no mentions of doc-base in policy.
>
> Document menu entry
[reposting to proper forum]
On Sat, Nov 29, 2003 at 04:51:47PM +1100, Herbert Xu wrote:
> >> > I would suggest using 0.MMDD to avoid using epoch when upstream
> >> > finally decides to use version 1.0 instead.
> >>
> >> What's wrong with using an epoch?
> >
> > Most people would prefer not us
On Wed, Nov 26, 2003 at 09:49:38PM -0500, Peter S Galbraith wrote:
> : To prevent having to use epochs for every new upstream version, the
> : version number should be changed to the following format in such
> : cases: "19960501", "19961224". It is up to the maintainer whether
> :
On Sun, Dec 07, 2003 at 10:58:17AM +0100, Fabio Massimo Di Nitto wrote:
> On Sat, 6 Dec 2003, Joey Hess wrote:
> > Maybe it's time to think about amending section 11.5. of policy (Web
> > servers and applications) to address some of the problems with it.
>
> indeed it is.
It's long, long, long ov
Hi Joey,
I am cross posting this answer but I think we should keep the
discussion on one mailinglist only. I leave up to you which one you think
is more appropriate.
On Sat, 6 Dec 2003, Joey Hess wrote:
> Maybe it's time to think about amending section 11.5. of policy (Web
> servers and
13 matches
Mail list logo