[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Reproducible, precompiled .o files: what say policy+gpl?

Joel Baker wrote:
> On Tue, Oct 19, 2004 at 04:59:37PM -0700, Josh Triplett wrote:
>>Wesley W. Terpstra wrote:
>>>True enough, but as processors get faster, so does bandwidth.
>>>I expect that ultimately, it will always need to be as fast as possible.
>>Possibly; however, I think bandwidth grows far slower than CPU speed and
>>overall system power.  I do understand your concern, though.
> Others have taken this up, but suffice to say: I wouldn't be so sure,
> unless you have concrete numbers.

It was pure speculation on my part, and I wouldn't be surprised if it
turns out to be wrong. :)

> The main limiting factors on pushing bits these days are the price of
> lines (fiber is dropping that drastically, for various reasons, at least
> for long-haul) and the price of hardware that can push the bits at a high
> enough speed.
> I can't quote you numbers offhand, but having worked for 10+ years as a
> network engineer (up to and including senior engineer for an ISP covering 4
> states), I can tell you what the budget looked like and why.

You certainly have far more information to go on then. :)

To be honest, I was thinking more about end-user Internet bandwidth,
rather than general network bandwidth.

>>>Put the normal gcc version rsgt in main where the i386 deb has:
>>>Recommends: rsgt-icc
>>You cannot put a Recommends from main to non-main; the strongest
>>relationship you can declare is Suggests.
>>>rsgt-icc sits in contrib, completely built by icc (not just some .o s)
>>>Conflicts: rsgt
>>>Provides: rsgt
>>>Replaces: rsgt
>>>If an i386 user (with contrib sourced) runs 'apt-get install rsgt'
>>>will that make apt install rsgt-icc? That's what I hope to accomplish.
>>No, I don't believe it will.  That's why when packages change names, it
>>is common to still produce a binary package with the old name, which
>>does nothing except depend on the new package.  That doesn't help you in
>>this case, of course.  I think all you can do is add the Suggests:
>>rsgt-icc to rsgt, have both packages Conflict/Replace/Provide the other,
>>and provide a brief explanation in the README.Debian of both packages.
> Or have rsgt-icc and rsgt-dfsg, and have a package rsgt with:
> Depends: rsgt-dfsg | rsgt-icc
> Since the dependancy can be met only with items available from main,
> this is allowed (at least, as established in prior discussions), and is
> far more obvious to most people, I think, than a Suggests on the same
> package that one also has a Replaces/Provides/Conflicts.

That is a good idea, and one that actually has some precedent in real
packages, such as the libSDL packages.

- Josh Triplett

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: