On Thu, Sep 28, 2000 at 10:33:25PM +0200, Stefan Alfredsson wrote:
> 1. Developer lives on the edge and usually has the latest libs installed
> 2. Package becomes dependant upon bleedingedge version of libs
>-- BUT it is not really needed, for example gtk1.2.1 might
>do just aswell as gtk1.
On Thu, Sep 28, 2000 at 10:33:25PM +0200, Stefan Alfredsson wrote:
> 1. Developer lives on the edge and usually has the latest libs installed
> 2. Package becomes dependant upon bleedingedge version of libs
>-- BUT it is not really needed, for example gtk1.2.1 might
>do just aswell as gtk1
On 2928T120641+0100, Colin Watson wrote:
> Does "consistent" mean "internally consistent" or
> "consistent among all builds of that package"?
In this case: the latter. It was an explicit goal when the policy
amendment was being drafted.
Maybe somebody would like to rewrite it for clarity? :-
On 2928T120641+0100, Colin Watson wrote:
> Does "consistent" mean "internally consistent" or
> "consistent among all builds of that package"?
In this case: the latter. It was an explicit goal when the policy
amendment was being drafted.
Maybe somebody would like to rewrite it for clarity? :
A similar issue that bothered me when I had a dialup connection was
the constant upgrade of libraries;
1. Developer lives on the edge and usually has the latest libs installed
2. Package becomes dependant upon bleedingedge version of libs
-- BUT it is not really needed, for example gtk1.2.1 mig
A similar issue that bothered me when I had a dialup connection was
the constant upgrade of libraries;
1. Developer lives on the edge and usually has the latest libs installed
2. Package becomes dependant upon bleedingedge version of libs
-- BUT it is not really needed, for example gtk1.2.1 mi
On Thu, Sep 28, 2000 at 12:52:30PM +0200, Bernhard R. Link wrote:
> On 27 Sep 2000, Itai Zukerman wrote:
>
> > > For this situation, I would suggest that we start to be really strict, and
> > > use chroot jails for *all* builds.
>
>
> It may resolve the situation, but I would much more elgeant,
Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote:
>On 2928T012303+0100, Colin Watson wrote:
>> I couldn't see it in policy, which was why I weakened my original
>> statement.
>
> If build-time dependencies are specified, it must be possible to build
> the package and produce working bin
On 27 Sep 2000, Itai Zukerman wrote:
> > For this situation, I would suggest that we start to be really strict, and
> > use chroot jails for *all* builds.
It may resolve the situation, but I would much more elgeant, if it would
not necessary, wouldn't it?
> I support the chroot jail concept, bu
On Thu, Sep 28, 2000 at 12:52:30PM +0200, Bernhard R. Link wrote:
> On 27 Sep 2000, Itai Zukerman wrote:
>
> > > For this situation, I would suggest that we start to be really strict, and
> > > use chroot jails for *all* builds.
>
>
> It may resolve the situation, but I would much more elgeant,
Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote:
>On 2928T012303+0100, Colin Watson wrote:
>> I couldn't see it in policy, which was why I weakened my original
>> statement.
>
> If build-time dependencies are specified, it must be possible to build
> the package and produce working bi
On Thu, Sep 28, 2000 at 12:59:30AM +0300, Antti-Juhani Kaijanaho wrote:
> On 2928T092438+1200, Michael Beattie wrote:
> > But, if the user has something *extra* installed, that the configure script
> > picks up and uses, because it is optional for the package build... you do
> > the math.
>
>
On 27 Sep 2000, Itai Zukerman wrote:
> > For this situation, I would suggest that we start to be really strict, and
> > use chroot jails for *all* builds.
It may resolve the situation, but I would much more elgeant, if it would
not necessary, wouldn't it?
> I support the chroot jail concept, b
On 2928T012303+0100, Colin Watson wrote:
> I couldn't see it in policy, which was why I weakened my original
> statement.
If build-time dependencies are specified, it must be possible to build
the package and produce working binaries on a system with the
build-essential packages
On Thu, Sep 28, 2000 at 12:59:30AM +0300, Antti-Juhani Kaijanaho wrote:
> On 2928T092438+1200, Michael Beattie wrote:
> > But, if the user has something *extra* installed, that the configure script
> > picks up and uses, because it is optional for the package build... you do
> > the math.
>
>
On 2928T012303+0100, Colin Watson wrote:
> I couldn't see it in policy, which was why I weakened my original
> statement.
If build-time dependencies are specified, it must be possible to build
the package and produce working binaries on a system with the
build-essential package
Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote:
>On 2927T182035+0100, Colin Watson wrote:
>> configuration system should probably be patched so that you can. Anybody
>> should be able to install all the build-dependencies, build the package,
>> and get the same result as before (assuming they
Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote:
>On 2927T182035+0100, Colin Watson wrote:
>> configuration system should probably be patched so that you can. Anybody
>> should be able to install all the build-dependencies, build the package,
>> and get the same result as before (assuming the
> > Anybody should be able to build a package when its build-time dependencies
> > are satisfied and end up with the same result as anyone else. This is
> > a policy recommendation.
>
> But, if the user has something *extra* installed, that the configure script
> picks up and uses, because it is o
On 2928T092438+1200, Michael Beattie wrote:
> But, if the user has something *extra* installed, that the configure script
> picks up and uses, because it is optional for the package build... you do
> the math.
That's what Build-Conflicts is for. Or one can hack the configure script.
--
%%%
On Wed, Sep 27, 2000 at 09:09:50PM +0300, Antti-Juhani Kaijanaho wrote:
> On 2927T182035+0100, Colin Watson wrote:
> > configuration system should probably be patched so that you can. Anybody
> > should be able to install all the build-dependencies, build the package,
> > and get the same resul
> > Anybody should be able to build a package when its build-time dependencies
> > are satisfied and end up with the same result as anyone else. This is
> > a policy recommendation.
>
> But, if the user has something *extra* installed, that the configure script
> picks up and uses, because it is
On 2928T092438+1200, Michael Beattie wrote:
> But, if the user has something *extra* installed, that the configure script
> picks up and uses, because it is optional for the package build... you do
> the math.
That's what Build-Conflicts is for. Or one can hack the configure script.
--
%%%
On Wed, Sep 27, 2000 at 09:09:50PM +0300, Antti-Juhani Kaijanaho wrote:
> On 2927T182035+0100, Colin Watson wrote:
> > configuration system should probably be patched so that you can. Anybody
> > should be able to install all the build-dependencies, build the package,
> > and get the same resu
On 2927T182035+0100, Colin Watson wrote:
> configuration system should probably be patched so that you can. Anybody
> should be able to install all the build-dependencies, build the package,
> and get the same result as before (assuming they have the same version
> of all the build-dependencies
Itai Zukerman <[EMAIL PROTECTED]> wrote:
>A few days ago I had to rebuild gimp1.1 from source to fix a little
>bug that was stalling my work. I noticed that since I have LPRng
>installed on my system, ./configure came up with different settings
>than the gimp binary in the archive was compiled wit
A few days ago I had to rebuild gimp1.1 from source to fix a little
bug that was stalling my work. I noticed that since I have LPRng
installed on my system, ./configure came up with different settings
than the gimp binary in the archive was compiled with (specifically,
lpstat support was enabled i
On 2927T182035+0100, Colin Watson wrote:
> configuration system should probably be patched so that you can. Anybody
> should be able to install all the build-dependencies, build the package,
> and get the same result as before (assuming they have the same version
> of all the build-dependencie
Itai Zukerman <[EMAIL PROTECTED]> wrote:
>A few days ago I had to rebuild gimp1.1 from source to fix a little
>bug that was stalling my work. I noticed that since I have LPRng
>installed on my system, ./configure came up with different settings
>than the gimp binary in the archive was compiled wi
A few days ago I had to rebuild gimp1.1 from source to fix a little
bug that was stalling my work. I noticed that since I have LPRng
installed on my system, ./configure came up with different settings
than the gimp binary in the archive was compiled with (specifically,
lpstat support was enabled
30 matches
Mail list logo
