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
Ian Jackson <[EMAIL PROTECTED]> writes:
> As far as I'm concerned this leaves undecided only the following
> question: how can we best organise this and what should the result
> look like ? So far we have seen two proposals:
> i. Simply have them side by side, with some kind of way of making
>
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 m
> 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
> > 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,
> 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
> obso
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
On Mon 19 Oct 1998, Ian Jackson wrote:
> 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 slig
On Mon 19 Oct 1998, Ian Jackson wrote:
> 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 w
Ian Jackson wrote:
> > Current policy is to ask the maintainer first and wait some time with
> > the NMU, except if it's really urgent (security stuff or so). But this
> > is often too long, which is one reason why we make bin-only NMUs.
>
> Perhaps we should relax this policy, then.
I tend to ag
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 s
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>> 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
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 fo
Adam P. Harris 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 y
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
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 u
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
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
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
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 distributio
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 temporary
situation; putting the patch
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 according
> 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 th
> 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 sho
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 recompil
> 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
>dire
"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
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 id
Daniel Martin writes ("Bug#27906: PROPOSED] Binary-only NMU's"):
...
> 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?
You're right, it's totally evil.
Paul Slootman writes ("Bug#27906: PROPOSED] Binary-only NMU's"):
...
> Firstly, as soon as an i386 maintainer uploads a newer version of some
> package which is _already_ ported to e.g. Alpha, the source for the
> Alpha version is _gone_. So, NMU uploads regardless, we&#
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 t
> 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
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
> 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 m
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_ cou
> 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,
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"
> 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 usu
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 prohibited by our policy.
I hereby propose an am
43 matches
Mail list logo
