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
---
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
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
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 future.
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 more of
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
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:
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 the
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
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
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.
It
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
embarrassing
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 start
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 be
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
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 version
16 matches
Mail list logo
