Ian Jackson wrote:
Interesting point, yes. However, I think we need to fix the source
skew problem now, and it's relatively easy: fix dinstall not to delete
sources, and run a cron job occasionally to delete obsolete ones.
Richard Braakman [EMAIL PROTECTED] wrote:
It is not quite so easy.
On Mon, 19 Oct 1998, Ian Jackson wrote:
ianJohn Lapeyre writes (Re: Bug#27906: PROPOSED] Binary-only NMU's):
ian I just want to register my vote for allowing this.
ian
ianWe are not voting.
This was an example of colloquial discourse.
ian It is an unstable distribution-- this is meant
In article [EMAIL PROTECTED], Ian Jackson [EMAIL PROTECTED] writes:
Adam P. Harris writes (Bug#27906: SUMMARY of Bug#27906: [PROPOSED]
Binary-only NMU's ):
If this topic under discussion is a proposed correction to the
devel-ref, we should refile the bug accordingly. I would be
delighted
Ian Jackson wrote:
Interesting point, yes. However, I think we need to fix the source
skew problem now, and it's relatively easy: fix dinstall not to delete
sources, and run a cron job occasionally to delete obsolete ones.
It is not quite so easy. Sometimes different revisions of a source
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*.
[...]
i. Simply have them side by side, with some kind of way of making
obsolete
Perhaps we should relax this policy, then.
I tend to agree. The wait seems to be the crux of the problem. Perhaps we
could let porters make NMU's with no wait at all?
This would be helpful in some cases, but doesn't solve the problem
that other archs have to recompile that NMU version,
That's right. This could be done occasionally out of cron, though.
There's no harm in extra old source packages hanging around for a
bit.
Ok.
No, I don't think so. The FTP site and the BTS are definitely not
the `same place' according to the GPL. For this to be true we'd have
to make sure
Hi,
Adam == Adam P Harris [EMAIL PROTECTED] writes:
Adam [ BTW, I don't think this group should be maintaining the
Adam Packaging Manual, but I don't volunteer for that job... ;) ]
Slow as it maybe, I still think this group is the correct
owner of contents of the Packagingn manual.
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
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
writes (Bug#27906: SUMMARY of Bug#27906: [PROPOSED] Binary-only
NMU's ):
...
Let's try to identify the archive states which can occur in which we
might be in trouble right now. Please correct me if I am incorrect.
As I said before, I'm not yet a porter, I'm just trying to understand
so I can
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
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
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
On Sat, Oct 17, 1998 at 08:55:22PM -0700, John Lapeyre wrote:
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.
It is an unstable distribution--
John Lapeyre [EMAIL PROTECTED] writes:
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.
It is an unstable distribution-- this is meant to be a
On Thu 15 Oct 1998, Ian Jackson wrote:
Roman Hodek writes (Bug#27906: PROPOSED] Binary-only NMU's):
Since .nmu files aren't .dsc files, they constitute no real new
source version, thus they don't force other archs to recompile the
package, too. But the patch is publically
This is an interesting idea, which could be investigated further.
Ok, then we could elaborate that idea...
This probably ought to apply to _any_ NMU, not just an arch-specific
one.
Yes, that was my intention (if I understand you right). If an NMU
doesn't upload the complete source, it
This needs to be fixed, then. Unless we can guarantee that the same
version of the same package will always work on all architectures,
we need to be able to have differing source versions simultaneously
while portability issues are sorted out.
I think Paul meant something different: If the
There are a lot of issues floating around here.
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
devel-ref, we should refile the bug
Ian Jackson [EMAIL PROTECTED] writes:
Roman Hodek writes (Re: Bug#27906: [PROPOSED] Binary-only NMU's):
...
It's the consent of many porters (including James Troup, ..., me, ...)
that we don't break the GPL by bin-only NMUs, as the complete source
is still available in an official way
I almost hate to suggest this, as it has the potential for much
evilness, but would it be possible to somehow mark diffs as specific
to some arch only?
[...]
Having slept a night over the issue :-), I had a similar idea.
If Ian says the patch must be available also on the FTP site, not
On Wed 14 Oct 1998, Ian Jackson wrote:
Package: debian-policy
Severity: wishlist
In the bug report 27823, someone reports uploading a binary-only NMU
and sends a corresponding source code change to the bug system.
This is NOT ON, and is NOT ALLOWED according to the GPL, and ought to
be
Roman Hodek writes (Bug#27906: PROPOSED] Binary-only NMU's):
...
Having slept a night over the issue :-), I had a similar idea.
If Ian says the patch must be available also on the FTP site, not
(only) in the BTS, why not it put there in some way? My idea just
wasn't coupled to architectures
Paul == Paul Slootman [EMAIL PROTECTED] writes:
Paul On Wed 14 Oct 1998, Ian Jackson wrote:
Paul file. That file does does state under which license it's
Paul distributed. It's not clear in most cases under what license
Hm, my debian/rules file doesn't actually state it since everyone
If Ian says the patch must be available also on the FTP site, not
(only) in the BTS, why not it put there in some way? My idea just
wasn't coupled to architectures, more to versions. I see several
possibilities:
- For each NMU, there's an additional patch file in the source
directory,
This is NOT ON, and is NOT ALLOWED according to the GPL, and ought
to be prohibited by our policy.
It's the consent of many porters (including James Troup, ..., me, ...)
that we don't break the GPL by bin-only NMUs, as the complete source
is still available in an official way: first the usual
Roman Hodek writes (Re: Bug#27906: [PROPOSED] Binary-only NMU's):
...
It's the consent of many porters (including James Troup, ..., me, ...)
that we don't break the GPL by bin-only NMUs, as the complete source
is still available in an official way: first the usual source
package, plus
GPL v2, s3, last para, emph mine:
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code _from the same place_ counts as
distribution of the source code, even
On Wed, Oct 14, 1998 at 03:00:29PM +0100, Ian Jackson wrote:
GPL v2, s3, last para, emph mine:
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code _from the same place_ counts
I don't understand your objection. All I want you to do is not to
give dpkg-buildpackage the -b flag if you've modified the source, so
that you upload the source along with your binaries. This is exactly
what you're doing atm, except that you're not distributing the source.
Hmmm , this
34 matches
Mail list logo
