There is _no way_ you will get people to comply 100% with policy. In
particular the FHS will be a problem (mostly with packages installing into
/opt).
Another item of note is user/group allocation.
Adrian
email: [EMAIL PROTECTED], http://www.poboxes.com/adrian.bridgett
Windows NT - Unix in bet
On 08-Jan-99 Jules Bean wrote:
> Of course, they might not want to be a debian developer.
>
> Note that, currently, to be a debian developer you have to agree with the
> DFSG. Commercial developers might well not..
>
> Perhaps we could afford them a quasi-developer status. Alternatively,
> the
On Fri, Jan 08, 1999 at 01:24:03PM +, Jules Bean wrote:
> On Fri, 8 Jan 1999, Bill Mitchell wrote:
>
> >
> >
> > There are at least two possible ways in which commercial organizations
> > might release .debs: (1) via non-free on the debian distribution sites,
> > and (2) by putting the .deb
On Fri, 8 Jan 1999, Bill Mitchell wrote:
>
>
> There are at least two possible ways in which commercial organizations
> might release .debs: (1) via non-free on the debian distribution sites,
> and (2) by putting the .debs on their commercial CDs and/or their own
> web sites. Obviously, the de
There are at least two possible ways in which commercial organizations
might release .debs: (1) via non-free on the debian distribution sites,
and (2) by putting the .debs on their commercial CDs and/or their own
web sites. Obviously, the debian project can exercise some control over
the former
Clint Guillot <[EMAIL PROTECTED]> wrote:
> ... abstraction layer to future proof these commercial packages...
> Let's just make sure that we provide all the functionality that such
> a package could possibly need, lest we end up with windows-esque 'os
> workarounds' where packages become broken bec
Previously Marcelo E. Magallon wrote:
> Why not SPI?
Because SPI could be associated with another project which produces
Debian add-on packages. If both Debian and the other project use
SPI the Origin field would suddenly become less usefull since you
still can't see from which project something c
>
Not too ugly at all, in fact, I've been thinking along those lines... This is a
wonderful abstraction layer to future proof these commercial packages... Let's
just
make sure that we provide all the functionality that such a package could
possibly
need, lest we end up with windows-esque 'os w
I wrote:
> Please choose something other than SPI. How about Debian?
Marcelo E. Magallon writes:
> Why not SPI?
Because SPI asserts that is not a Debian specific organization, and because
there is no reason to expect that people not intimately familiar with
Debian will recognize 'SPI' as meaning
On Wed, Nov 25, 1998 at 06:14:23PM -0600, [EMAIL PROTECTED] wrote:
> Arto Astala writes:
> > there was a related discussion about origin field in deb, so Debian
> > produced debs would have origin SPI
>
> Please choose something other than SPI. How about Debian?
Why not SPI?
Oliver Elphick wrote:
> Should we say, for example, that any commercial package should put all
> its files under /opt/ or /usr/local/commercial/ or
> something of the kind?
>
> What other guidance is needed?
They should go under /opt/ -- /usr/local is reserved for the
sysadmin.
There are a varie
Previously Oliver Elphick wrote:
> Should we say, for example, that any commercial package should put all
> its files under /opt/ or /usr/local/commercial/ or
> something of the kind?
Maybe following the FHS would be a good idea? Of course overlapping
with other packages will always be considerd e
Arto Astala writes:
> there was a related discussion about origin field in deb, so Debian
> produced debs would have origin SPI
Please choose something other than SPI. How about Debian?
--
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI
there was a related discussion about origin field in deb,
so Debian produced debs would have origin SPI and others some
other
and how package tools (only apt, I think) would handle multiple
packages with the same name (would this affect also depends etc.
fields)
I think some guide line stuff was t
I just noticed the following planned but non-existent title in the
Debian Documentation Project's list of manuals:
How Software Producers can distribute their products directly in .deb
format
I thought a little about what might go in here, and realised that I
have not seen any guidance
15 matches
Mail list logo
