On Mon, Oct 25, 1999 at 03:18:47AM -0200, Lalo Martins wrote: > Also, could you people please stop for a moment and really evaluate > the ammount of code needed? Get real: this is _trivial_.
We'd need code to:
* make life easy for the mirrors (either a working package pool,
or the hard links thing). I've tried writing code to create a
package pool, it's not that tricky, but it's a pain. I haven't
looked at dinstall at all ever, so I've no idea how hard it'd
be to modify dinstall to cope with it. Dealing with hard links
sounds much more reasonable, but it gets rid of all the
* do `installability checking'. I've done some code (see my
previous mail) that checks depends/conflicts within main.
It's about 2000 LOC, bits of which are incredibly horrible
and complicated.
* work out how to choose subsets of packages that don't make
hundreds of others uninstallable --- so that you don't
install the new lesstif unless you also update all the other
programs that the new lesstif will make uninstallable. This
alone is non-trivial.
* interface with the BTS. Note that working out which bugs belong
to a package has been something of a hack until today, even.
Really, having the BTS be able to tell you which bugs apply to
which versions of a package would be desirable to implement this
properly.
> Please make a list of the code we would need.
> Please make a list of the added burdens on the ftpmasters.
Erm. As proposer, this is really /your/ job.
> > Third, voting on `this is what these people will spend their time on in
> > future' is completely inappropriate. If it's really a better way, they'll
> > spend their time on it because they want to. If it's a bit ambiguous,
> > you can spend your time on it if you want to.
> No, nobody could just go and implement this radical change in
> the way we work without consulting the other developers.
Of course they could. In exactly the same way Debconf appeared. People
discussed it, someone went off and implemented it, and now that we've
got an implementation, we're ready to start using it, and consider adding
it to policy.
Here, we ought to be discussing what we need (which we've done for over
a year now), implementing it, and /then/ working out whether we want to
actually use it or not.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
pgpOqQqPi1lsW.pgp
Description: PGP signature
