Re: Proposal: incremental release process (the package pool)
On Sun, 24 Oct 1999, Lalo Martins wrote:
> This proposal includes erradication of the "experimental" area,
> because very few maintaiers use it, because it's "out of the
> way" for people to download from it, and because it will be
> redundant with the "pool" layer.
Like Gregory said, experimental serves a purpose that is not covered by
your 4 pools - software in there literally does not work..
> 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]
> 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.
> 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]
> delete the "project/experimental" area. Of course the promotion
> automating software must be working and tested by then.
In 2 months? Not likely..
Jason
Reply to: