Re: Proposal: incremental release process (the package pool)
On Mon, Oct 25, 1999 at 12:12:39AM -0600, Jason Gunthorpe wrote:
>
> On Mon, 25 Oct 1999, Lalo Martins wrote:
>
> > Yes, but pool can have multiple versions of a same package.
>
> But how on earth is anyone supposed to know which version is the one they
> want?
Please elaborate. What are you talking about? Promotion? Apt?
Or just manual downloading?
> > Hmm. I actually meant to use apt's install-time dependency
> > check. It's smart enought to know when something is
> > "installable".
>
> To apply that individually to each and every package [there are 4000 of
> them!] is too slow. It would be better to solve the conflicts problem
> which is at least a weeks work, maybe more.
Yes, slow. I thought of that. I'll trust you here, IIRC you
know more about apt internals than I do.
> > Yes, but this means we would require the apt people to fix their
> > front-ends by the time of the change. I didn't want to add this
> > extra requirement. If it's ready by then, so much better.
>
> If you emit all available versions then APT select automatically the
> highest, but internally all are available for any future use. It is not a
> good idea to put selecting the highest of many in dpkg-scanpackages.
I said it would require modifying the _front-ends_. Not that
this is hard to do, just that I don't want to pressure anyone
into doing that. But then again, if you feel like this could be
done I'll trust you.
> > > In 2 months? Not likely..
>
> > Why not? An email responding bot (borrow from BTS), an
> > archive-handling script (borrow from dinstall) and a
> > dependency-checker (borrow from apt)? Looks like work for a
> > week. 2 months give time enought for testing and debugging.
>
> The depenency anaylsis and consideration code alone from APT is nearly
> 5kloc, code able to effectively replace dinstall (~1kloc of perl) using
> this new scheme may weigh in at least 2kloc of C, and the new code
> required to ensure consistency I would estimate at around another 3kloc.
Hmm no. Let's think again.
For getting packages into pool, we would still use dinstall.
For promoting packages, we don't need dinstall's features; just
check if the package is fine, and if it is, update the
(sym?)link. So forget ``2kloc''; more like 20loc of a shell
script or 50loc C.
What new code?
> Given that the long term average code generation of most people is about
> 100-200 lines/day that would take you about one month to write, and at
> least 3 months to sufficiently test. That is assuming you fully understood
> all of the subjects at hand and did not have to learn anything substantial
> new.
>
> Then you would have to tack on another month at least to convert and train
> the FTP masters, and begin preparing to convert the archive.
We have to seriously evaluate this. The only way is trying. If
it's really as hard as you think, then we (I) need to find some
other way of migrating to the incremental release system.
Incrementally ;-)
[]s,
|alo
+----
--
I am Lalo of deB-org. You will be freed.
Resistance is futile.
http://www.webcom.com/lalo mailto:lalo@webcom.com
pgp key in the web page
Debian GNU/Linux --- http://www.debian.org
Brazil of Darkness - http://www.webcom.com/lalo/BroDar
Reply to: