On Tue, Oct 26, 1999 at 10:21:21AM -0400, Ben Collins wrote:
> is actually nothing wrong with this policy. Personally, I would hope that
> it always stays this way.
Ditto.
> For the non-i386 archs, it makes for much less
> bug reports, and more stable/consistent builds.
FWIW, stability and cons
Julian Gilbey <[EMAIL PROTECTED]> writes:
> > Why change?
> >
> > Would it be OK for the source of mount to depend on ssh? (just a realy
> > extreme example)
>
> No: ssh is not in main (it's in non-US/non-free at present, although
> it may well end up in non-US/main very soon). See policy 2.1.
Goswin Brederlow wrote:
> Whats complicated about using uncompress.sh instead of gzip and
> fallback to gzip if not present?
Tons of things. What about programs called in uncompress.sh -- are
dependancies supposed to be fullfilled then? What happens when the script
fails? What if you don't trust d
On Tue, Oct 26, 1999 at 07:28:31PM +0200, Goswin Brederlow wrote:
> Source packages should also not depend on other packages with higher
> priority, otherwise there could arise a situation where you can´t
> build a package because you can´t build another.
This is not useful. Priority rating for so
On Tue, Oct 26, 1999 at 03:46:23PM -0400, Ben Collins wrote:
>
> Sbuild calls dpkg-source to unpack, what does it have to do with the
> source format?! All it has to do is call whatever executable is needed for
> the unpacking. It _already_ handles _everything_ else, _and_ the Build
> Dependencies
Joey Hess <[EMAIL PROTECTED]> writes:
> Goswin Brederlow wrote:
> > Why not pipe it through "uncompress.sh" as and if present in the
> > control.tar.gz?
>
> Why not change to using the shar archive format for our packages?
>
> Because it's overly complicated, and unnecessary.
Whats complicated
Chris Pimlott <[EMAIL PROTECTED]> writes:
> On 21 Oct 1999, Goswin Brederlow wrote:
> > Of cause policy should encourage to use bzip2 (or gzip if smaller) and
> > base packages must use tar.gz (or tar.bz2 if bzip2 is in base) so
> > that one can update debian. Any package using a non default
> >
Julian Gilbey <[EMAIL PROTECTED]> writes:
> > On Tue, 26 Oct 1999, Julian Gilbey wrote:
> >
> > > Given that there are now two sorts of depends, I am changing the
> > > paragraph:
> > >
> > >Packages may not depend on packages with lower priority values. If
> > >this should happen, one o
On 21 Oct 1999, Goswin Brederlow wrote:
> Of cause policy should encourage to use bzip2 (or gzip if smaller) and
> base packages must use tar.gz (or tar.bz2 if bzip2 is in base) so
> that one can update debian. Any package using a non default
> compression must predepend on that compressor, but th
> Julian Gilbey <[EMAIL PROTECTED]> writes:
>
> > + However, because '/usr/local' and its contents are for
> > + exclusive use of the local administrator, a package must
> > + not rely on the presence or absence of files of
>
> Why change?
>
> Would it be OK for the source of mount to depend on ssh? (just a realy
> extreme example)
No: ssh is not in main (it's in non-US/non-free at present, although
it may well end up in non-US/main very soon). See policy 2.1.2 for
the definition of the `main' section.
> Source pac
I second this proposal.
[Joey, do you want to change the status of this proposal in the BTS?]
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see
Goswin Brederlow wrote:
> Why not pipe it through "uncompress.sh" as and if present in the
> control.tar.gz?
Why not change to using the shar archive format for our packages?
Because it's overly complicated, and unnecessary.
--
see shy jo
> On Tue, 26 Oct 1999, Julian Gilbey wrote:
>
> > Given that there are now two sorts of depends, I am changing the
> > paragraph:
> >
> >Packages may not depend on packages with lower priority values. If
> >this should happen, one of the priority values will have to be
> >adapted.
> >
Julian Gilbey <[EMAIL PROTECTED]> writes:
> + However, because '/usr/local' and its contents are for
> + exclusive use of the local administrator, a package must
> + not rely on the presence or absence of files of
^
> +
On Tue, Oct 26, 1999 at 09:02:59PM +0200, Wichert Akkerman wrote:
> Previously sparc porters wrote:
> > I still think sbuild is the way to go.
>
> I still think sbuild is not the way to go and would rather see sbuild
> modified to handle the new source format.
>
> Oh, in case someone hasn't notic
Previously sparc porters wrote:
> I still think sbuild is the way to go.
I still think sbuild is not the way to go and would rather see sbuild
modified to handle the new source format.
Oh, in case someone hasn't noticed: this is the rumoured new source
format from Klee Dienes. If you want to test
Julian Gilbey <[EMAIL PROTECTED]> writes:
> Given that there are now two sorts of depends, I am changing the
> paragraph:
>
>Packages may not depend on packages with lower priority values. If
>this should happen, one of the priority values will have to be
>adapted.
>
> to read:
>
>
On Tue, Oct 26, 1999 at 07:13:27PM +0200, Wichert Akkerman wrote:
> The name dpkg-source here is a bit if a misnomer; it is in fact the name
> of a package that includes new versions of dpkg-source,
> dpkg-buildpackage, dpkg-genchangers, etc.
>
> I have the tarball available for anyone who wants t
On Tue, Oct 26, 1999 at 07:13:27PM +0200, Wichert Akkerman wrote:
> Previously sparc porters wrote:
> > Personally I don't think dpkg-source can enforce this.
>
> The name dpkg-source here is a bit if a misnomer; it is in fact the name
> of a package that includes new versions of dpkg-source,
> dp
Previously sparc porters wrote:
> Personally I don't think dpkg-source can enforce this.
The name dpkg-source here is a bit if a misnomer; it is in fact the name
of a package that includes new versions of dpkg-source,
dpkg-buildpackage, dpkg-genchangers, etc.
I have the tarball available for anyo
On Tue, Oct 26, 1999 at 05:32:12PM +0100, Julian Gilbey wrote:
> OK, almost there. But one quickie:
>
> The sentence:
> A package may not modify a conffile of another package.
> was replaced by something better, but I'm not sure what the conclusion
> was. How about:
> The maintainer scripts
> Previously Julian Gilbey wrote:
> > It seems that this proposal was rejected due to dpkg -iGROEB being
> > superceded by apt-cdrom. Is this correct?
>
> I don't think so.. this was that patch that added an option to dpkg
> to use filenames instead of looking inside packages, right?
>
> Wichert
OK, almost there. But one quickie:
The sentence:
A package may not modify a conffile of another package.
was replaced by something better, but I'm not sure what the conclusion
was. How about:
The maintainer scripts of a package may not modify a conffile of
_any_ package, including the one
On Tue, Oct 26, 1999 at 04:51:23PM +0200, Wichert Akkerman wrote:
> Previously Antti-Juhani Kaijanaho wrote:
> > How do you define "complete implementation"?
>
> A dpkg-source that:
> a) supports build-dependencies
> b) supports multiple patches
> c) can setup a buildroot and start building everyt
On Tue, 26 Oct 1999, Julian Gilbey wrote:
> Given that there are now two sorts of depends, I am changing the
> paragraph:
>
>Packages may not depend on packages with lower priority values. If
>this should happen, one of the priority values will have to be
>adapted.
>
> to read:
>
>
Processing commands for [EMAIL PROTECTED]:
> reassign 37254 packaging-manual
Bug#37254: dpkg: update-alternatives madness
Bug reassigned from package `dpkg' to `packaging-manual'.
> stop
Stopping processing here.
Please contact me if you need assistance.
Darren Benham
(administrator, Debian Bug
Processing commands for [EMAIL PROTECTED]:
> reopen 34223
Bug#34223: apt and packaging manual are in contradiction
is already open, cannot reopen.
> severity 34223 normal
Bug#34223: apt and packaging manual are in contradiction
Severity set to `normal'.
> thanks
Stopping processing here.
Pleas
On Tue, Oct 26, 1999 at 09:40:57AM -0600, Erik Andersen wrote:
> On Tue Oct 26, 1999 at 10:21:21AM -0400, Ben Collins wrote:
> >
> > Perhaps the real argument should be, to have something that allows the
> > users to specify their own headers without libc-dev overwriting them.
> >
>
> That was i
reopen 34223
severity 34223 normal
thanks
On Tue, 26 Oct 1999, Julian Gilbey wrote:
> Santiago indicated a contradiction between APT's behaviour and the
> packaging manual. Santiago: could you suggest a rewording of the
> packaging manual which would resolve this issue?
Simple answer: No, this
On Tue Oct 26, 1999 at 10:21:21AM -0400, Ben Collins wrote:
>
> Perhaps the real argument should be, to have something that allows the
> users to specify their own headers without libc-dev overwriting them.
>
That was indeed the problem that caused my concern. When I am hacking
on the kernel an
On Tue, Oct 26, 1999 at 14:46:03 +0100, Julian Gilbey wrote:
> Are there any objections?
This is not an objection, but I wish there were slightly more accurate term
than "binary package", because some binary packages don't contain binaries
(e.g. just data and/or scripts). "binary package" could be
Your message dated Tue, 26 Oct 1999 15:57:20 +0100 (BST)
with message-id <[EMAIL PROTECTED]>
and subject line Bug#29522: diversions
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your respon
Processing commands for [EMAIL PROTECTED]:
> reassign 37254 dpkg
Bug#37254: dpkg: update-alternatives madness
Bug reassigned from package `debian-policy, dpkg' to `dpkg'.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Darren Benham
(administrator, Debian Bugs datab
Has this proposal been effectively rejected?
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
> In /usr/doc/debian-policy/policy.html/ch2.html it says:
>Packages may not depend on packages with lower priority values. If this
>should happen, one of the priority values will have to be adapted.
>
> I think this is unclear. Especially the second sentence. Perhaps this
> phraseology w
> Previously Julian Gilbey wrote:
> > Do we need to then specify this in the policy manual, or will it be
> > sufficient to file bugs against packages which don't have the needed
> > update-alternatives in their prerm?
>
> No need to put this in the policy manual. The policy manual is for
> polici
Santiago indicated a contradiction between APT's behaviour and the
packaging manual. Santiago: could you suggest a rewording of the
packaging manual which would resolve this issue?
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of
> On Tue, Oct 26, 1999 at 04:30:50AM -0700, Joel Klecker wrote:
> > I do have a problem with the text for policy; it does not explain the
> > difference between Build-Indep-{Depends,Conflicts} and
> > Build-{Depends,Conflicts}.
I think you mean the packaging manual, and the diff says quite
clear
Reading bug #31645, it seems clear that the Packaging Manual was
accepted as policy, although Joey had reservations.
Should I go ahead and make the modifications Manoj proposed?
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Mat
Given that there are now two sorts of depends, I am changing the
paragraph:
Packages may not depend on packages with lower priority values. If
this should happen, one of the priority values will have to be
adapted.
to read:
Binary packages may not depend on binary packages with lower
Previously Julian Gilbey wrote:
> It seems that this proposal was rejected due to dpkg -iGROEB being
> superceded by apt-cdrom. Is this correct?
I don't think so.. this was that patch that added an option to dpkg
to use filenames instead of looking inside packages, right?
Wichert.
--
__
Previously Antti-Juhani Kaijanaho wrote:
> How do you define "complete implementation"?
A dpkg-source that:
a) supports build-dependencies
b) supports multiple patches
c) can setup a buildroot and start building everything that is needed to
build a package
Right now c) doesn't seem to work cor
On Tue, Oct 26, 1999 at 11:39:06AM +0100, Julian Gilbey wrote:
> We spent a lot of time on this list thrashing out the /var/spool/mail
> vs. /var/mail issue. It would be a shame if it came to nothing due to
> a lack of seconds. Please check up this final proposal (included
> below) and second it
On Tue, Oct 26, 1999 at 12:45:20PM +0100, Julian Gilbey wrote:
> This should certainly be discussed with the libc maintainers before
> making such a proposal. I am sure that they did not take the decision
> lightly.
>
> > I wish to change Debian policy regarding libc and the kernel sources.
> > T
Previously Alexander Koch wrote:
> The change would have to be in the bootdiscs first, right?
base-files.
Wichert.
--
/ Generally uninteresting signature - ignore at your convenience \
| [EMAIL PROTECTED]h
On Tue, Oct 26, 1999 at 04:18:55AM -0700, Joel Klecker wrote:
> At 06:31 -0400 1999-10-26, Ben Collins wrote:
> >Ok, this is what I have as recognized fields in the current dpkg CVS. The
> >wording in that new proposal for bug #41232 through me for a loop. Anyway,
> >all that is left to be done for
Julian Gilbey <[EMAIL PROTECTED]> wrote:
> What's the current status of this bug report? How will we deal with
> this problem?
How is this a bug in the policy? If upstream insists on new sonames for each
release. We must release packages with new names for each release as well.
There is no other
Your message dated Tue, 26 Oct 1999 15:36:43 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#40742: Your policy proposal
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your re
> I'm annoyed though, that everyone is completely ignoring a *working*
> implementation of source-dependencies simply because nobody is
> willing to clean it up a little and package it. How can that
> happen???
Aehm, what do you mean? For just getting src-deps working, it's only
necessary that th
Proposed addition to 3.1.2:
>Because '/usr/local' and its contents are for exclusive use of the
>local administrator, a package must not rely on the presence or
>absence of files or directories in '/usr/local' for normal
>operation, although files present in there may modify or enha
This should certainly be discussed with the libc maintainers before
making such a proposal. I am sure that they did not take the decision
lightly.
> I wish to change Debian policy regarding libc and the kernel sources.
> The document /usr/share/doc/libc6/FAQ.Debian.gz states:
>
> Occasionall
It seems that this proposal was rejected due to dpkg -iGROEB being
superceded by apt-cdrom. Is this correct?
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux
Any thoughts on this one, or should it be dropped for the time being?
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~j
On Tue, Oct 26, 1999 at 04:30:50AM -0700, Joel Klecker wrote:
> I do have a problem with the text for policy; it does not explain the
> difference between Build-Indep-{Depends,Conflicts} and
> Build-{Depends,Conflicts}.
The difference is clearly defined by the amendment. The
Build-{Depends,Conf
On Tue, Oct 26, 1999 at 01:54:58PM +0200, Wichert Akkerman wrote:
> Yes. And I won't think I want to change dpkg and friends to accept
> the fields until someone comes up with a complete implementation.
How do you define "complete implementation"? The build daemon folks
have had a working impleme
Previously Julian Gilbey wrote:
> Do we need to then specify this in the policy manual, or will it be
> sufficient to file bugs against packages which don't have the needed
> update-alternatives in their prerm?
No need to put this in the policy manual. The policy manual is for
policies, not for gu
Previously Julian Gilbey wrote:
> I'm about to add #41232 (source dependencies) to the next policy
> version. But will this break existing tools?
Yes. And I won't think I want to change dpkg and friends to accept
the fields until someone comes up with a complete implementation.
I'm annoyed thoug
At 06:31 -0400 1999-10-26, Ben Collins wrote:
On Tue, Oct 26, 1999 at 09:52:09AM +0100, Julian Gilbey wrote:
Sorry, I was doing things from memory. The proposal says:
+
+This is done using the Build-Depends,
+Build-Depends-Indep, Build-Conflicts, and
+Build-Conflic
At 00:14 +0100 1999-10-26, Julian Gilbey wrote:
Just a question which I haven't thoroughly investigated yet:
I'm about to add #41232 (source dependencies) to the next policy
version. But will this break existing tools? In particular, will the
dpkg* tools yet be able to build a package using a
On Tue, Oct 26, 1999 at 06:31:14AM -0400, Ben Collins wrote:
> Just so I don't have to go looking all over creation, what was the general
> consensus on how dpkg-* scripts should handle and react to these fields?
IMHO dpkg-source should not check them, or at most warn (they are not
unpack depends
I hereby also second the proposal.
Alexander
--
- Real programmers don't comment their code. If it was hard to write, it
should be hard to understand.
Alexander Koch - <>< - WWJD - aka Efraim - PGP 0xE7694969 - ARGH-RIPE
On Tue, 26 October 1999 11:39:06 +0100, Julian Gilbey wrote:
> We spent a lot of time on this list thrashing out the /var/spool/mail
> vs. /var/mail issue. It would be a shame if it came to nothing due to
> a lack of seconds. Please check up this final proposal (included
> below) and second it if
On Tue, 26 Oct 1999, Masato Taruishi wrote:
>
> At Mon, 25 Oct 1999 23:11:18 +0200 (MET DST),
> Gergely Madarasz <[EMAIL PROTECTED]> wrote:
> > > alsadriver-unstable (0.5pre+cvs19991024+1855-1) unstable; urgency=low
> > > .
> > >* new upstream release.
> > >* Changed section from main t
On Tue, Oct 26, 1999 at 09:52:09AM +0100, Julian Gilbey wrote:
> > At 00:14 +0100 1999-10-26, Julian Gilbey wrote:
> > >Just a question which I haven't thoroughly investigated yet:
> > >
> > >I'm about to add #41232 (source dependencies) to the next policy
> > >version. But will this break existin
Your message dated Tue, 26 Oct 1999 11:21:57 +0100 (BST)
with message-id <[EMAIL PROTECTED]>
and subject line Bug#39831: FSSTND refers to an inaccessible file, namely,
device-list
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt wi
Your message dated Tue, 26 Oct 1999 11:05:49 +0100 (BST)
with message-id <[EMAIL PROTECTED]>
and subject line Bug#26995: fsstnd-1.2.dvi.gz is wrong
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is
We spent a lot of time on this list thrashing out the /var/spool/mail
vs. /var/mail issue. It would be a shame if it came to nothing due to
a lack of seconds. Please check up this final proposal (included
below) and second it if you think it appropriate.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
I am currently sorting through the bugs in debian-policy, and came
across this one by Ian Jackson. Any thoughts?
Julian
> I think most of us will agree that we need some kind of way of
> distributing and automatically using regression test suites. We need
> to do this in a way that allows pe
> I agree that update-alternatives shouldn't put an alternative into
> manual mode because a _target_ disappeared unexpectedly. I'll look
> into this eventually.
>
> But, the problem doesn't happen if you call update-alternatives in the
> prerm, which is where you should. So it would be good if
Any progress on this bug report?
> Summary of the bug report:
>
> If mirror license is not Debian-specific, its license should explicitly
> allow distribution of the program in modified form, by point #4 in
> the DFSG.
>
> The maintainer asked the author about being ok that *Debian*
> distribut
What's the current status of this bug report? How will we deal with
this problem?
Julian
> > > MICO (www.mico.org) doesn't use so versions, but always puts the
> > > full version into the library file name. An example result of ldd
> > > is:
> > >
> > > coolo:~> ldd /usr/bin/idl
> > >
On Tue, Oct 26, 1999 at 12:15:52AM -0700, Joel Klecker wrote:
> wtf? when did the proposal change to "Source-Depends:"? there's no
> evidence of that in the logs.
*My* proposal has never changed that way (#41232). The fields are:
Build-Depends:
Build-Depends-Indep:
Build-Conflicts:
Build-Confli
> At 00:14 +0100 1999-10-26, Julian Gilbey wrote:
> >Just a question which I haven't thoroughly investigated yet:
> >
> >I'm about to add #41232 (source dependencies) to the next policy
> >version. But will this break existing tools? In particular, will the
> >dpkg* tools yet be able to build a p
On Mon, 25 Oct 1999, Julian Gilbey wrote:
> I am about to include this amendment in policy. However, I am stuck
> with the wording, as you say the following.
>
> Questions: What version number should be used in footnote 2?
>What do we do with the reference implementation?
Good questi
At 00:14 +0100 1999-10-26, Julian Gilbey wrote:
Just a question which I haven't thoroughly investigated yet:
I'm about to add #41232 (source dependencies) to the next policy
version. But will this break existing tools? In particular, will the
dpkg* tools yet be able to build a package using a
On Tue, Oct 26, 1999 at 12:14:19AM +0100, Julian Gilbey wrote:
> Just a question which I haven't thoroughly investigated yet:
>
> I'm about to add #41232 (source dependencies) to the next policy
> version. But will this break existing tools? In particular, will the
> dpkg* tools yet be able to b
On Mon, Oct 25, 1999 at 10:12:03PM -0400, Raul Miller wrote:
>
> On Tue, Oct 26, 1999 at 10:11:50AM +1000, Herbert Xu wrote:
> > But do you agree that with your current proposal, you still have to fix all
> > scripts that use -e/escape codes?
>
> Like I said before, I don't think this issue is re
Processing commands for [EMAIL PROTECTED]:
> retitle 46522 [PROPOSED] Simplified definition of Non-free
Bug#46522: [EMAIL PROTECTED]: Re: SSH never free]
Changed Bug title.
> severity 46522 wishlist
Bug#46522: [PROPOSED] Simplified definition of Non-free
Severity set to `wishlist'.
> retitle 482
On Mon, Oct 25, 1999 at 10:06:24PM +1000, Herbert Xu wrote:
> > > Let me state once again, this has no bearing whatsoever over the proposed
> > > change in policy and my question about whether escape codes/-e are to be
> > > mentioned or not. It is for purely pendantic value.
On Mon, Oct 25, 1999
On Tue, Oct 26, 1999 at 12:14:19AM +0100, Julian Gilbey wrote:
> I'm about to add #41232 (source dependencies) to the next policy
> version. But will this break existing tools? In particular, will the
> dpkg* tools yet be able to build a package using a Source-Depends:
> field, or will they die?
Your message dated Tue, 26 Oct 1999 01:12:11 +0100 (BST)
with message-id <[EMAIL PROTECTED]>
and subject line Bug#41729: [PROPOSAL] Modify dpkg-buildpackage to handle FHS
move
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
Processing commands for [EMAIL PROTECTED]:
> close 21969
Bug#21969: [ACCEPTED 1998/05/01] Policy clarification about Standards-Version
Bug closed, ack sent to submitter - they'd better know why !
> close 28747
Bug#28747: [ACCEPTED 1999/04/05] Policy note that GPL moved to
/usr/share/common-licen
Processing commands for [EMAIL PROTECTED]:
> retitle 41729 [REJECTED] Modify dpkg-buildpackage to handle FHS move
Bug#41729: [PROPOSAL] Modify dpkg-buildpackage to handle FHS move
Changed Bug title.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Darren Benham
(admi
I'm not quite clear from the bug logs what the final agreed wording is
for this proposal. Please could you let me know?
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian
I am about to include this amendment in policy. However, I am stuck
with the wording, as you say the following.
Questions: What version number should be used in footnote 2?
What do we do with the reference implementation?
> So I think we should change the above paragraph to something
Just a question which I haven't thoroughly investigated yet:
I'm about to add #41232 (source dependencies) to the next policy
version. But will this break existing tools? In particular, will the
dpkg* tools yet be able to build a package using a Source-Depends:
field, or will they die? If the l
close 21969
close 28747
close 37257
close 37338
close 37342
close 37345
close 37389
close 37713
close 38212
thanks
Now that all bugs are archived, it doesn't seem to make much sense to
keep these accepted amendments in a "Fixed" state.
What to do with all of the old proposals is another matter.
On Mon, Oct 25, 1999 at 08:09:13PM -0400, Raul Miller wrote:
> On Mon, Oct 25, 1999 at 10:06:24PM +1000, Herbert Xu wrote:
> > Let me state once again, this has no bearing whatsoever over the proposed
> > change in policy and my question about whether escape codes/-e are to be
> > mentioned or not.
On Mon, Oct 25, 1999 at 10:06:24PM +1000, Herbert Xu wrote:
> Let me state once again, this has no bearing whatsoever over the proposed
> change in policy and my question about whether escape codes/-e are to be
> mentioned or not. It is for purely pendantic value.
I think it's an important point,
On Mon, Oct 25, 1999 at 11:32:32PM +0200, Goswin Brederlow wrote:
> Ben Collins <[EMAIL PROTECTED]> writes:
> >
> > Normally, one could just look at the extension (.gz, .bz2). I don't see a
> > need to add an extra field to the .dsc.
> >
> > Ben
>
> Then dpkg-source, dpkg-deb, must know all
91 matches
Mail list logo
