On Mon, Nov 06, 2000 at 09:16:38AM -0500, Itai Zukerman wrote:
>
> The proposal makes perfect sense, I just have one concern: I see that
> dpkg-buildpackage takes an architecture flag, but I don't think
> there's a way to specify a "system type" (i386-hurd, for example). If
> I want to put stuff
On Mon, Nov 06, 2000 at 11:14:12AM -0700, Jason Gunthorpe wrote:
> A *port* however should not be going around changing things willy nilly. A
> Debian GNU/HURD system should be very close to a Debian GNU/Linux which
> would be even closer to a Debian GNU/BSD (due to their more similar
> kernel desi
On Mon, Nov 06, 2000 at 04:23:18PM -0800, Joey Hess wrote:
> Ben Collins wrote:
> > Still, nothing says the FHS will never change, and change is very
> > difficult with everything doing their own thing. So my argument is still
> > that a central place describing these locations that the packages qu
>
> That's not what I want, and if I've implied so, I didn't mean to. I'm
> not asking that you design to avoid helping others. I'm asking that
> the design not be overly onerous on our developers solely to aid those
> who are outside the Debian Project's scope. We can't be all things
> to all peo
Ben Collins wrote:
> Still, nothing says the FHS will never change, and change is very
> difficult with everything doing their own thing. So my argument is still
> that a central place describing these locations that the packages query,
> is a better thing. This, in addition to my other reasons for
On 06-Nov-00, 16:18 (CST), Ben Collins <[EMAIL PROTECTED]> wrote:
> Did we forget that these program are not created for Debian, and the
> majority of them are not even created soley for Linux? I wonder if that
> has been lost in this self-centered view that Debian/Linux(or FHS if you
> want) is t
On Mon, Nov 06, 2000 at 02:57:28PM -0800, Joey Hess wrote:
> Ben Collins wrote:
> > I did not know Debian was strictly an FHS project. When did this happen?
>
> Debian policy, section 3.3.1:
>
> The location of all installed files and directories must comply with
> the Linux File system
Ben Collins wrote:
> I did not know Debian was strictly an FHS project. When did this happen?
Debian policy, section 3.3.1:
The location of all installed files and directories must comply with
the Linux File system Hierarchy Standard (FHS).
I have to wonder where you've been if you arn
On Mon, Nov 06, 2000 at 03:19:40PM -0600, Steve Greenland wrote:
> On 06-Nov-00, 13:35 (CST), Ben Collins <[EMAIL PROTECTED]> wrote:
> > On Mon, Nov 06, 2000 at 10:58:30AM -0600, Steve Greenland wrote:
> > >
> > > 1. "Non-FHS ports". This seems to me a contradiction in terms. Marcus
> > > has wei
On 06-Nov-00, 13:35 (CST), Ben Collins <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 06, 2000 at 10:58:30AM -0600, Steve Greenland wrote:
> >
> > 1. "Non-FHS ports". This seems to me a contradiction in terms. Marcus
> > has weighed in with "but HURD *is* FHS", and I don't see why other ports
> > can't
On Mon, Nov 06, 2000 at 10:58:30AM -0600, Steve Greenland wrote:
> On 06-Nov-00, 10:22 (CST), Ben Collins <[EMAIL PROTECTED]> wrote:
> > >
> > > Ben, I don't really see the point of all of us spending time to support
> > > non-Debian systems. I don't have much interest in seeing dpkg take over
>
On Mon, 6 Nov 2000, Steve Greenland wrote:
> > Please reread my original post. Two of the three cases involve actual Debian
> > ports (either present or future).
Persumably this means some BSD thing that has been speculated about..
> 1. "Non-FHS ports". This seems to me a contradiction in terms
On Mon, 6 Nov 2000, Marcus Brinkmann 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
On 06-Nov-00, 10:22 (CST), Ben Collins <[EMAIL PROTECTED]> wrote:
> >
> > Ben, I don't really see the point of all of us spending time to support
> > non-Debian systems. I don't have much interest in seeing dpkg take over
> > the universe. The point of having standards such as the FHS is to avoid
>
> Ben, I don't really see the point of all of us spending time to support
> non-Debian systems. I don't have much interest in seeing dpkg take over
> the universe. The point of having standards such as the FHS is to avoid
> this kind of kludgery.
>
Please reread my original post. Two of the th
On 06-Nov-00, 09:10 (CST), Ben Collins <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 06, 2000 at 03:26:56PM +0100, Nils Lohner wrote:
> > So I guess the system needs to support functionality that I can use
> > the .orig.tgz files (no debianization) because then I can just apt-get
> > source and build a
On Mon, Nov 06, 2000 at 11:03:50AM -0500, Itai Zukerman wrote:
> > > dpkg-buildpackage --system-type i386-linuxlocal
> > >
> > > (or something). And, if that's the case, probably the system type
> > > should be part of the deb (the Architecture field)?
> >
> > Maybe create an env var that this
Manoj, plain and simple, relocation is a hack used for non-native systems.
Most of the issues I am talking about are for native Debian systems that
do not all follow the same dir format. The build cases for third-party is
a plus. See, my solution works in all cases. Relocation does not help
32/64 p
> > dpkg-buildpackage --system-type i386-linuxlocal
> >
> > (or something). And, if that's the case, probably the system type
> > should be part of the deb (the Architecture field)?
>
> Maybe create an env var that this dpkg-dirs script will use to override
> the default file?
>
> DEBIAN_DIR_
On Mon, Nov 06, 2000 at 09:16:38AM -0500, Itai Zukerman wrote:
> > +include /etc/dpkg-dev/dirs.$(DEBIAN_GNU_HOST_TYPE)
> >
> > - ./configure
> > + ./configure --sbindir=$(sbindir) --bindir=$(bindir) --etcdir=$(etcdir)
>
> The proposal makes perfect sense, I just have one concern: I see that
>
>>"Ben" == Ben Collins <[EMAIL PROTECTED]> writes:
>> And we need to scope the effort invovled -- and whether the
>> effort has to be so heavy and deep reaching.
Ben> SO you would reather break this down into 3 or four solutions to
Ben> handle each type of case, thus making it more complex an
On Mon, Nov 06, 2000 at 03:26:56PM +0100, Nils Lohner wrote:
>
> Ben-
> There's only one thing that I would like to see, and that's to facilitate
> compiling and installing native packages on other systems.
>
> I currently work on solaris and since I use a lot of GNU tools I currently
> down
>>"Ben" == Ben Collins <[EMAIL PROTECTED]> writes:
Ben> Your solution does not help true debian systems that are non-linux, such
Ben> as freebsd, and hurd. Why take the time to implement something that
Ben> doesn't solve all the problems.
My solution involves extending dpkg, so that ev
Ben-
There's only one thing that I would like to see, and that's to facilitate
compiling and installing native packages on other systems.
I currently work on solaris and since I use a lot of GNU tools I currently
download all packages that can handle
./configure --prefix=/sup;make;make insta
> +include /etc/dpkg-dev/dirs.$(DEBIAN_GNU_HOST_TYPE)
>
> - ./configure
> + ./configure --sbindir=$(sbindir) --bindir=$(bindir) --etcdir=$(etcdir)
The proposal makes perfect sense, I just have one concern: I see that
dpkg-buildpackage takes an architecture flag, but I don't think
there's
>
> By analogy with dpkg-architecture, I'd like to see the following idiom
> in debian/rules, which has the extra advantage of avoiding the "include
> this in both sh and make" thing and of only setting the make variables
> that need to be set:
>
> BINDIR=$(shell dpkg-paths -qBINDIR)
>
> con
Manoj Srivastava <[EMAIL PROTECTED]> 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
> Raul> that, if we adopt this convention, programs could st
>
> That's because Ben is not strictly correct, we are not breaking
> FHS compliance at will. Indeed, the Hurd author and designer
> Thomas Bushnell, BSG, was (is?) one of the early contributors
> to the FHS to ensure that the Hurd *can* be compliant.
>
Sorry Marcus, I didn't mean to imply that
On Sun, Nov 05, 2000 at 02:24:35PM -0700, Jason Gunthorpe wrote:
>
> 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 in
On Sun, Nov 05, 2000 at 03:43:56PM -0600, Manoj Srivastava wrote:
> >>"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
On Sun, Nov 05, 2000 at 03:52:28PM -0600, Manoj Srivastava wrote:
> >>"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 whethe
Am Son, 05 Nov 2000 22:24:35 schrieb Jason Gunthorpe:
>
> 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 cat
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
>>"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
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
47 matches
Mail list logo
