On Mon, 19 Oct 1998, Ian Jackson wrote:
ian>John Lapeyre writes ("Re: Bug#27906: PROPOSED] Binary-only NMU's"):
ian>> I just want to register my vote for allowing this.
ian>
ian>We are not voting.
This was an example of colloquial discourse.
ian>> It is an unstable distribution-- this i
Ian,
before you propose a complete reorganization of our FTP archive to
"comply" with the GPL, please take a look at the "SOURCES" file in the GNU
operating system, version 0.2.
Some excerpts:
*---
Sources for binaries in GNU versio
Hi,
>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> *we MUST be able to have more than one source version in our archive*.
Ian> For me, this follows from
Ian> (a) both our own commitment to distribute source code and the GPL
Ian> when combined with
Ian> (b) the fact of our loosely
> Since we cannot rebuild for all architectures simultaneously and do
> not want to withdraw binaries or wait with porting,
> *we MUST be able to have more than one source version in our archive*.
>
> As far as I'm concerned this leaves undecided only the following
> question: how can we best or
Buddha Buck writes ("Re: Bug#27906: PROPOSED] Binary-only NMU's "):
...
> It was my understanding that one of the benefits of the "package pool"
> reorganization of the archive was exactly that -- we would keep
> multiple versions of packages (source and binary) around. Older
> versions would b
Hi,
>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> Biased summary:
Biased is right.
Ian> My scheme:
Ian> * keep the user's filesystem consistently laid out during transition.
Ian> * allows the transition to be controlled explicitly by a single script.
Ian> * allows us to
Hi,
>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> Manoj Srivastava writes ("Re: FHS - transition"):
Ian> ...
>> I would much rather have a slow
>> transition with information browsers able to handle the transition
>> seamlessly to being confronted with the choice of a flag day or an
John Lapeyre writes ("Re: Bug#27906: PROPOSED] Binary-only NMU's"):
> Sorry, I missed most of this. I get a lot of binary only NMU's
> >from Paul and Roman with an accompanying diff that also goes in the BTS.
>
> I just want to register my vote for allowing this.
We are not voting.
>
I agree with Adam's analysis below, except that IMO the debian/* files
are just as much part of the source code, and there's no exception for
them. See the quote from the GPL that I posted yesterday, about
`scripts which control compilation and installation of the
executable'.
Adam P. Harris writ
Roman Hodek writes ("Bug#27906: PROPOSED] Binary-only NMU's"):
...
> If you want to fix this by keeping several source versions available,
> dinstall would have to check first all binary-* directories which
> source versions are still needed on any installation...
That's right. This could be done
Adam P. Harris writes ("Bug#27906: SUMMARY of Bug#27906: [PROPOSED] Binary-only
NMU's "):
> First, administrivia. Ian originally said:
> | I hereby propose an amendment to the Debian Developers' Reference,
> | s5.5 `Interim Releases'
>
> If this topic under discussion is a proposed correction to
Paul Slootman writes ("Bug#27906: PROPOSED] Binary-only NMU's"):
...
> If you're saying that each and every binary version should be accompanied
> with corresponding source only when a release is made, then the whole
> problem could be circumvented by making the bug report with the diffs
> severity
I wrote:
> [...] there's no harm in a small amount of version skew at release time.
Several people have misunderstood this; my apologies for being
unclear.
I meant that there is no harm if the binary versions for (say) m68k
and i386 are slightly out of step. So, there's no need to rebuild
i386 b
Santiago Vila writes ("Re: /etc/adjtime, /etc/timezone, etc."):
> On Mon, 5 Oct 1998, Ian Jackson wrote:
> > Why can't you just handle this in the postinst, without involving dpkg
> > ?
>
> Of course I can, I've already done this (in base-files_2.0.1), but I still
> think policy needs a little bit
Manoj Srivastava writes ("Re: FHS - transition"):
...
>I would much rather have a slow
> transition with information browsers able to handle the transition
> seamlessly to being confronted with the choice of a flag day or an
> embarrassing kludge at some time in the futur
Biased summary:
My scheme:
* keep the user's filesystem consistently laid out during transition.
* allows the transition to be controlled explicitly by a single script.
* allows us to start moving packages to /usr/share nearly straight
away.
* can preserve backward compatibility indefinitel
At 22:06 +0200 1998-10-15, Santiago Vila wrote:
On 10 Oct 1998, Adam P. Harris wrote:
2. info browsers, manual pagers, terminfo libraries, etc., are
Yes, but where is the info program that looks in both directories?
In the 'info' package. Start info and hit C-h, and in the help is:
The cur
Hi,
We are nearing the end of the discussion period for this
proposal. So far, there have been no objections.
manoj
PROPOSAL: Policy manual contradicts itself about including docs
---
Man
In article <[EMAIL PROTECTED]>, Manoj Srivastava <[EMAIL PROTECTED]> writes:
>>> "Darren" == Darren Benham <[EMAIL PROTECTED]> writes:
Darren> I was talking with one such human in IRC today and he basicly
Darren> said he'd get chewed out since there is no policy to reject
Darren> packages because t
19 matches
Mail list logo
