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

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

> > 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.

      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: