Ok, I'm not on d-devel, but I stumbled across this thread during my
not-infrequent browsing of the archives.
Point the first: menu changes are now handled by the d-policy list,
like virtual packages. (I know because I wrote the final proposal.)
I've cc'd this msg to -policy.
Point the second: wh
Laser Printer Cartridges at discount prices
Our Info and/or Order Line: 1-888-883-2024
Our Fax Line: 1-888-977-1577
*** For All E-mail removal please call: 1-888-248-4930 ***
Order by Fax or Phone
Laser Printer Toner Cartridges, Fax and Copier Cartridges
We accept Government, School & Univers
On Sun, Nov 05, 2000 at 04:07:37PM -0500, Ben Collins wrote:
> Yes it will take some work, but no more than a) the usr/doc ->
> usr/share/doc move is taking, nor the Build-Depends updates, nor any of
> the other major changes we have undertaken.
Or the /var/lib/games->/var/games transition, which
On Sun, Nov 05, 2000 at 03:39:41PM -0600, Manoj Srivastava wrote:
> >>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
> Raul> Uh.. to the best of my knowledge, most packages which use these
> Raul> paths "hard code" them in some file. Maybe you're suggesting
> Really? I find I seldom h
>>"Ben" == Ben Collins <[EMAIL PROTECTED]> writes:
Ben> Oh, and let's not forget that most build scripts hardcode these
Ben> paths anyway, so it's a matter of replacing the hardcoded parts
Ben> with a variable, and adding a line that sources the var file.
Most scripts hard code sbindir
>>"Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
Jason> Support for other OS's is a good reason I think, but then
Jason> again - they are non-free..
And we need to scope the effort invovled -- and whether the
effort has to be so heavy and deep reaching.
manoj
--
.. I
On Sun, 05 Nov 2000, Manoj Srivastava wrote:
> packages buggy''. Indeeed, anything like this should probably be
> introduced as a recommendation; and non-compliance should be deemed a
I will change the proposal to recommend the use of invoke-rc.d, and add a
warning that 'in the future' usage of
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> On Sun, Nov 05, 2000 at 02:48:18PM -0600, Manoj Srivastava wrote:
>> Would this not be easier done by having a mapping done at
>> unpack/install time, and then only scripts/programs with hard coded
>> paths need be changed?
Raul> Uh..
>>"Ben" == Ben Collins <[EMAIL PROTECTED]> writes:
Ben> Disadvantage? It only solves things outside of Debian,
You talk about non FHS systems, and non debian people
installing stuff, I assumed non debian systems were being considered
here.
Ben> since surely it would not be adopted as
On Sun, 5 Nov 2000, Ben Collins wrote:
> 1) Non-FHS ports have problems concering the directories where things
>get installed (they may not match linux directories). Darwin, FreeBSD,
>Hurd and many others fall into this category.
Could someone explain to me how a non-FHS 'Debian Port' is
On Sun, Nov 05, 2000 at 02:48:18PM -0600, Manoj Srivastava wrote:
> Hi,
>
> Would this not be easier done by having a mapping done at
> unpack/install time, and then only scripts/programs with hard coded
> paths need be changed?
>
> So dpkg would map the Linux FS to the local FS'
On Sun, Nov 05, 2000 at 02:48:18PM -0600, Manoj Srivastava wrote:
> Hi,
>
> Would this not be easier done by having a mapping done at
> unpack/install time, and then only scripts/programs with hard coded
> paths need be changed?
>
> So dpkg would map the Linux FS to the local FS'
On Sun, Nov 05, 2000 at 02:48:18PM -0600, Manoj Srivastava wrote:
> Would this not be easier done by having a mapping done at
> unpack/install time, and then only scripts/programs with hard coded
> paths need be changed?
Uh.. to the best of my knowledge, most packages which use these pat
Hi,
Would this not be easier done by having a mapping done at
unpack/install time, and then only scripts/programs with hard coded
paths need be changed?
So dpkg would map the Linux FS to the local FS' and it can
even take into account things like transforming to /opt heirarchy.
On Sun, 5 Nov 2000, Ben Collins wrote:
> Now, here's my solution, and it's very simple. This involves mostly
> policy, and lots of package changes. It doesn't really affect the package
> manager, nor the build-tools.
>
> Packages would be required to read a file, /etc/dpkg-dev/dirs-i386 for
> exa
On Sun, Nov 05, 2000 at 05:38:32PM +0100, Arthur Korn wrote:
> Hi
>
> Ben Collins schrieb:
> > libdir=/usr/lib
> > syslibdir=/lib
> > bindir=/usr/bin
> > sbindir=/usr/sbin
> > sysbindir=/bin
> > syssbindir=/sbin
> > mandir=/usr/share/man
> > x11bindir=/usr/X11R6/bin
> > ()
>
> I had a similar
Hi,
Umm, there is a little matter of transition planning. The
policy diff, as presented in this proposal, makes it an rc bug for
any package not using this current nonexistent mechanism, and as such
fails ``new policy should not immediately make a large number of
packages buggy''. Inde
Hi
Ben Collins schrieb:
> libdir=/usr/lib
> syslibdir=/lib
> bindir=/usr/bin
> sbindir=/usr/sbin
> sysbindir=/bin
> syssbindir=/sbin
> mandir=/usr/share/man
> x11bindir=/usr/X11R6/bin
> ()
I had a similar idea, but one big problem remains: architecture:
all. Every script would have to source
I plan on putting together a proposal for this idea I have been toying
around with for quite some time.
Basically we have several problems/issues I want to resolve.
1) Non-FHS ports have problems concering the directories where things
get installed (they may not match linux directories). Darwi
19 matches
Mail list logo
