Re: Stop archive bloat: 47MB gmt-coast-full_19991001-1.deb

[Fabien Ninoles <fabien@Nightbird.TZoNE.ORG>]

On Tue, Oct 26, 1999 at 09:45:29PM +0200, Sami Dalouche wrote:
> > 
> > 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 !

Use the XBS-Keywords: user-defined field in the control file. This
add a field Keywords: in both the source control file (.desc) and
the binary file (.deb). Then make some software to parse it and used
it (included the Section field in your analysis). If it's useful,
it would be used and can even became part of the Policy (if needed).

Look at the menu package for some way of handling this (The not-used-but-
should-be indices feature).

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

It's already chosen by the maintainers of each packages. However,
until lately, the maintainers only have two choices: either it goes in
main, either it doesn't go in Debian at all! With data (and any other
new sections create), they can put them elsewhere and still have it
being part of Debian. However, I don't think we should mandate it. The
maintainer is the one responsible to put it at the right place. Anything
else we'll lead to flamewars. It's not just about changing the priority,
it's about modifying the AVAILABILITY of the package!).

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

elvis-tiny is a more pure vi. VIM is a boosted vi (with lot of options and
visual feedback absent from vi).

About priorities, the required and essential propriorities is based mostly
on necessity, space and Unix standards. We need a standard tiny editor on
the base disks: so we take the smaller working vi-compatible editor we have.
A package also get a higher priority if it's simpler to install (exim vs
sendmail), but also got lower weight in alternatives so when package with
lower priority is install, they are automatically select by
update-alternatives.

As you can see, is not really the same thing as making the thing as making
the package unavailable on the Debian Official CD (which only contains main
and contrib).

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

use it as a regular user. It should then let you browse your package
list in peace. However, I suggest you to make your update using
/usr/lib/dpkg/methods/apt/update instead of apt-get update. This will
also update the dselect listing.

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

Agree with you. The idea of a flat pool directory with well organized
{sym|hard}links farms for distribution also please me a lot.

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

data should reduce the size main, as well as all its possible brothers
(astro, bio, geo, themes, icons, etc.) It's just a matter of time and some
guidance policy.

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

Please then, feel a bug against the package and, when possible, offers the
maintainer that you want to maintain the stable package if he's too busy.
Sometimes, the cvs version is simply more usable then the unstable one.
Packages in unstable should be seen as the further candidate for the
next stable. Forcing an upgrade to a truly unstable version is just making
it candidate for a removal for RCB when the freeze arrive.

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

Thanks :) My 14.4k modem will be more happy ;)

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

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