Re: Stop archive bloat: 47MB gmt-coast-full_19991001-1.deb
> > > > 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).
>
This is a great idea too. I had forgotten that this idea was said and I
think it's good, so let's apply it !
> >
> > 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?
All Vi and all Emacs that many people use.
> What about joe and jed? Lot of people used those
Joe and Jed too. But By saying this, I only wanted to say that the package
that are present in main should be chosen. If lots of users use x or y
editor, it's OK to put it in main, but in the whole bunch of editor, I'm
sure most should be moved to another directory, less important than Main.
> editors and most other distro included them. The priority order help
> beginners to find which packages should they install.
yes, but elvis-tiny, for example, is a good editor for floppy disks but
unusable for a complete installed distro ! I have never understood how to
use this VI (. I already thought all VI were the same...) while VIM is
really cool and easy, compared to this weird VI.
You will say that it's my fault because I don't know how to use this editor,
but I'm sure lots of people are like me and hate this editor, so WHY giving
a such editor a BASE or something like that permission ?
So, the priority isn't always well made.
>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.
>
But I think we should be able to go through the directories to see the
packages taskes, not opening a software that is sometimes a shit (excuse me
for the term, but when, for example, you ignore dselect, install your first
packages with apt-get install <pkg> and a day, you want to use dselect,
you will see that it begins to install a lot of unwanted packages. Maybe
there is a way to tell it to forget pre-defined to-install packages, but I
don't know this way.
> >
> > 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.
Not removing, but only moving the packages to another directory to ease the
distribution by lighting main.
But even I wrote this, I think you're maybe right. By thinking and
re-thinking to this, I now think that it can be a bad idea.
But we must do something like clarify the structure, add keywords or something
like this to have a nicer distro. For the moment, it's a bunch of software
that are [un]sorted (:-)) into too general directories.
>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.
>
Yes, you're right but we must do something else to reduce the size of main.
> >
> > 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.
Yes, I totally agree with YOU ! the maintainer SHOULD provide the cvs AND
the stable version, but it seems that usually, they provide the CVS version
only ! And this is the problem.
>
> > --
> > 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.
>
OK, sorry.
Bye,
sami
--
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
Reply to: