Re: Proposal: incremental release process (the package pool)
On Sun, Oct 24, 1999 at 08:48:21PM -0600, Jason Gunthorpe wrote:
>
> Like Gregory said, experimental serves a purpose that is not covered by
> your 4 pools - software in there literally does not work..
Yes, but pool can have multiple versions of a same package.
> > dependencies resolvable withing "working". This may be checked
> > automatically, the necessary code is already in apt-get. If this
>
> Actually it isn't.. APT has algorithms to check a subset of the possible
> conditions, but does not check certain conditions involving conflicts,
> which prove to be extremely difficult. [Note this only applies to the
> distribution as a whole, ie the apt-cache unmet command]
Hmm. I actually meant to use apt's install-time dependency
check. It's smart enought to know when something is
"installable".
> > 3: To be nicer on mirrors, Working should at all times be simply
> > a forest of symlinks into Pool, because mirrors can't handle the
> > movement of a file (they just delete it from the old location
> > and download it again for the new one).
>
> Actually our mirror network is being upgraded to handle hard links which
> obviosly solve the migration problem.
You mean, use something similar to inodes to know the real
"identity" of a file? That would be great.
> > 4: dpkg-scanpackages, or whatever is used to generate Packages
> > files for apt, must be fixed so that when multiple versions are
> > found, the newest one is used (currently it uses the first one
> > found, which will give filesystem-dependent results).
>
> dpkg-scanpackages should just include all available versions, the APT
> GUI's people are writing can make use of that. [dselect can get upset if
> not used through apt, but it could be patched]
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.
> > delete the "project/experimental" area. Of course the promotion
> > automating software must be working and tested by then.
>
> 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.
[]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: