Re: "Meta" packages

[Ali Abdin <aliabdin aucegypt edu>]

* Julian Missig (julian linuxpower org) wrote at 01:13 on 02/10/00:
> > 
> > > Talking with Telsa and Ankh, we came to the conclusion that it would be
> > > very nice to have meta-packages for gnome 1.4. Smaller libraries could
> > > be grouped together depending upon how essential they are, and this
> > > lessens the number of things which need to be installed. I'd simply like
> > > to bring it up for discussion. Would some kind of script be created to
> > > help those compiling it all, or what? The basic idea is to optimize the
> > > packaging and installation so that the downloads a 28.8 user has to make
> > > aren't too large, and the number of installations a t1 user has to do
> > > are minimal. I feel this will also help spread the new "essential"
> > > libraries when the time comes, and it still allows us to only update
> > > small libraries via helix-update when necessary.
> > > 
> > 
> > I'm not sure I agree that grouping packages together is such a good
> > idea.  The number of packages one has to install really *shouldn't*
> > matter.  I've never understood people's complaints with that.  Having
> > packages split up by functionality is beneficial for several reasons:
> > 
> > * each file is smaller...this is very nice for modem users; they can
> >   grab one file at a time.
> > 
> > * one only needs to install what one wants.  if I don't want  
> >   gnome-print, for example, I don't have to install it.
> > 
> > * i can update or remove a very particular element of my system
> >   without tampering with the rest of it.
> > 
> > A user who has a lot of bandwidth shouldn't find installing more files
> > difficult.  If that user has the Helix Gnome distribution, it's simply
> > a matter of running the updater.  Even if not, just download what you
> > want to update in a directory and do "rpm -Uvh *.rpm"  
> > 
> > Now, one idea that I think *would* be nice is to have an installer
> > file format that arhives RPM's all into one file, or optionally
> > downloads the necessary files.  In other words it would be an
> > executable (or mime type that gnome knows how to handle) that would
> > pop up a wizard and install all the RPMs for you.  I know the Gnome
> > installer and updater that Helix has written does something along
> > those lines, but an installer for Gnome could be useful for other
> > Gnome programs as well.  The user could just download the installer
> > and it would determine what distribution they are using (Redhat,
> > Debian, whatever), and install accordingly.  I'm probably not being
> > very coherent.  
> > 
> 
> Like it or not, the fact is that having too many files to
> download/install, no matter what their size, isn't viewed nicely by a
> lot of people.
> 
> The entire reason for grouping things by how essential they are is that
> modem users can grab the essential meta-packages they want, and then
> pick and choose the specific non-essential libraries (I would imagine
> that the packages would still be available individually, for upgrades
> and all). The most essential meta-package could have like gnome-libs and
> gdk-pixbuf. Chances are, if people are getting gnome, they'll want both
> of those. 
> 
> I fortunately became a high-bandwidth user recently, so it's not fair
> that I argue for something like this. Hopefully Telsa's around to agree
> with me that grouping the packages by how essential they are would help.
> And if the modem users really don't want to, they can download the
> individual packages. I'm just saying that on the GNOME ftp and such we
> should push the meta-packages. With the meta-packages, people have to
> worry much less about dependencies and all.
> 
> As for RPMs and DEBs, they aren't as much of a concern as tarballs for
> people who are compiling GNOME. Yes, I would like meta-package RPMs
> (such a thing already exists for debian, and debian users have it easy
> enough anyway), but I would really like to see meta-packaged tarballs.

I think what happened in the past is that we had one 'sumo' tarball that
included all the packages inside for the 'core' GNOME release. This might be a
good idea to do (you can also do it for RPMS (a tarball of RPMS - so all you
have to do is rpm -Uvh all the files in the directory). 

This time the 'additional packages' will be split off from the 'core' GNOME
release, and it might not make sense to 'bundle' them into packages (i.e.
these apps are usually big enough to stand on their own). What I think would
be a 'good' meta package though is the GNOME Office stuff (unfortunately there
are other more 'political' issues with this)
 
> > * each file is smaller...this is very nice for modem users; they can
> >   grab one file at a time.
> 
> They still have a lot of files to download, and many times it is very
> difficult to judge which files they need and don't need. I remember when
> I first got GNOME over my 56k I downloaded overnight what I thought were
> all I would need, only to find a bunch of dependencies I still had to go
> out and download, and even then I wasn't sure.

I think the GDP crew needs to write a 'Installing GNOME 1.4' document /before/
the release. When I first started using Linux, I was directed by people to KDE
(thats how I found out about GNOME by the way). Anyway, one thing that KDE
excels in is that it has DETAILED instructions on how to install KDE on /many/
systems.

What I would think needs to be covered is: Installing from tarballs,
Installing from RPMS (will there be official GNOME 1.4 RPMS???), and
Installing from Debian (is this section really necessary?). There should be a
section on Installing from scratch and 'Upgrading'

Note: Installing from Helix Code should not be covered in depth really - a)
that is up to Helix Code to do and b) it is already pretty much
straightforward for Helix Code users.
 
> > 
> > * one only needs to install what one wants.  if I don't want  
> >   gnome-print, for example, I don't have to install it.
> 
> gnome-print probably wouldn't be very high up on the essential scale,
> and even so, they could still grab the other pieces of the meta-package
> it's in seperately.

Well that would depend. For example, if RPMS were compiled with gnome-print
support, it may become much higher ranked on the dependency list.

> > 
> > * i can update or remove a very particular element of my system
> >   without tampering with the rest of it.
> 
> I'm not saying actually combine the the libraries or anything, they
> still exist seperately within the meta-package. gnome-libs is gnome-libs
> is gnome-libs. Putting it in the ultra-essential package won't change
> that. It'll just be installed with gdk-pixbuf and other things.

Generally, I agree with a 'meta-package' for the core GNOME libraries (just as
a convenient download). But inside they would each be their own dir (i.e.
gnome-meta/gnome-core-1.4.0 for example). 

For the 'additional' packages, well - each one should stand on its own, unless
there should be a GNOME Office metapackage (I think that will be the only
'meta-pacakge' that would work for the additional packages).

Regards,
Ali