Re: Stop archive bloat: 47MB gmt-coast-full_19991001-1.deb
On Wed, Oct 20, 1999 at 11:17:24PM +0200, Sami Dalouche wrote:
> On Mon, Oct 18, 1999 at 01:43:42AM -0600, Jason Gunthorpe wrote:
> >
> > On 18 Oct 1999, Philippe Troin wrote:
> >
> > > Do we really need a 47MB file that will be useful to maybe 10 people
> > > using Debian (at most) ? We already fill 5+ CDs...
> >
> > On the same subject, the Debian archive is now 10.8G in size, at the
> > current rate of growth a majority of the mirrors will likely stop
> > mirroring non-i386 by the end of next year and if things continue in two
> > release time we will be like 20G big and we won't even be able to mirror
> > it ourselves!
> >
> > We badly need to prune stuff and be more efficient.
>
> I totally agree w/ this and would love to help a such project !
> I think we should keep so many packages because this is one of the elements
> which makes the debian distro better than the other but we shouldn't put all
> the packages in the same place.
> I think we should first make new sections and subsections and sort all of
> the actually present packages into them. But we must really think a lot
> to these sections and make them as most significative as we can.
> for example, we shouldn't put all graphics related packages in the diretory
> graphics but we should do a thing like this :
>
> * media
> - graphics
> - viewer (e.g. electric eyes)
> - editors (e.g. Gimp)
> - libs
> - [...]
> - sound
> - editor
> - mixer
> - libs
> - [...]
>
> We should allow symlinking packages into other sections if they can do many
> things. For example, Imagemagick is an image editor but his concept makes
> from him a great image viewer. So, I think we should put the .deb in
> media/graphics/editors and symlink it to media/graphics/viewer.
I agree with you but find it a bit complicated. Shouldn't be better to
simply add some Keywords field. We already have a lot of tools who can
grep control fields (helas! dselect don't).
>
> So, when we will a proper directory structure, we will be able to go to the
> next step :
> Determining which packages have the same goal as others. We can for example
> see that there are many mixers available in the sound section. We should
> determine the best [ or the prefered ] mixer for X and the best mixer for
> the console. We should do the same for all packages in all sections. I know
> there would be many conflicts, but when it's too deep, we could add both of the
> packages in the main section. I think particulary to Apache vs Roxen. This
> debate would never finish, so it means that both are the best and both of
> them must be added to the main section. In other words, main would mean
> "THE BEST SOFTWARE" and by best, I mean the most powerful, not the
> beginner's software. Inn would fit in main while the others news transport
> system wouldn't.
> I think a lot of clean in the editor section must be done too ! VI and (X)Emacs
> should be the only intheractive editor present in main !
Which vi? Which emacs? What about joe and jed? Lot of people used those
editors and most other distro included them. The priority order help
beginners to find which packages should they install. The task packages
help them further by selecting packages for a given task. The bad
presentation of those options by dselect should be set as a bug against
dselect, not against the policy/ftp-site.
>
> For the rest I've not more ideas on the moment, but I'm sure that we can do
> a largely better distro !
Please, think well. I don't see how removing some packages make Debian a
better distro. This is only good for commercial distro with a small, well-
targetted market, not a distro like Debian, especially not what I would
like Debian to be. Apart from legal and technical reasons, nothing
except the maintainer decision should decided where things should go!
People (both users and developers) can suggest about it to him, but
it has the final decision. IMHO, the maps would never be download in
main if data already existed. ftp-maintainers can always override such
decisions. That's the spirit of the data proposal.
>
> BTW, I think that we should add another distro ! Yes, really ! Stable /
> Unstable is too hard : You have the choice in having stable but very
> out-dated software and in having updated software but which are too much
> updated to be stable !
> I think we should make another distro which would contain the stable version
> of every software, not the cvs version or the version which was released 2
> years ago !
>
Do you follow unstable? Unstable is just the pre-frozen stable. Packages
in it should not necessarely be unstable. In fact, maintainers should have
in mind that the frost can happen anytime soon. Sure, sometime a renaming
of libraries can break something, but it's a necessary thing (although
I would recommend a stage-area for this). The maintainers should always
provided the stable version along with the cvs version (just like you have
both gimp and gimp1.1) when possible. Really bugg/dangerous packages should
go in experimental.
> --
> DDDD EEEEE BBBB II AAAAA NN N LL II NN N U U X X
> DD D E__ B__B II A___A N N N LL II N N N U U XX
> DD D E B B II A A N N N LL II N N N U U XX
> DDDD EEEEE BBBB II A A N NN LLLLL II N NN UUUUU X X
> Content-Description: This is my PGP5i public key
Please, don't included your public key in your mail. 1K key are very big,
especially with numerous signatures. KeyID and fingerprint will suffice
if you upload it to a keyserver or make it available through finger, http,
ftp, email, or any other mean. Ask me if you want some recipe for doing
so.
--
------------------------------------------------------------------------
Fabien Ninoles Chevalier servant de la Dame Catherine des Rosiers
aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer
E-mail: fab@tzone.org
WebPage: http://www.tzone.org/~fabien
RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
------------------------------------------------------------------------
Reply to: