* ralf.prengel@comline.de <ralf.prengel@comline.de> [Jan 18. 2007 09:52]:

A good idea,

I think it would be enough to have a login and a !!small!! yast for installing more packages.

If we are talking about a _really_ small base system, it should include RPM at most but not YaST. YaST is a convenience application for systems management and should be optional.

In my opinion it is not neccessary to have a working network for a really small system.

I agree. Thinking of virtualized systems, sharing filesystems is sufficient. Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

* Wolfgang Rosenauer <wolfgang@rosenauer.org> [Jan 18. 2007 10:27]:

Klaus Kaempf wrote:

...

I agree. Thinking of virtualized systems, sharing filesystems is sufficient.

Really. For what to have a virtualized system if you can't really connect to it?

To do data processing for example, i.e. reporting and data analysis. Such an application could read from one (mounted) database and write its output to a file.

IMHO a system w/o network is not of use nowadays.

I agree that networking is highly useful. The question is, do we want to make networking mandatory (!) for the 'base' system. I do not think so. Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Klaus Kaempf wrote:

* ralf.prengel@comline.de <ralf.prengel@comline.de> [Jan 18. 2007 09:52]:

...

I think it would be enough to have a login and a !!small!! yast for installing more packages.

If we are talking about a _really_ small base system, it should include RPM at most but not YaST. YaST is a convenience application for systems management and should be optional.

Well, since yast asks for the root password in 2nd stage a system without yast would be somewhat useless as you couldn't even log in after installation. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Am Do 18.01.2007 10:27 schrieb Ludwig Nussel <ludwig.nussel@suse.de>:

Well, since yast asks for the root password in 2nd stage a system without yast would be somewhat useless as you couldn't even log in after installation.

Thats why I wrote: "deinstall after installation". So we can walk trough the complete second stage of installation and afterwards we've perhaps no YaST at all. So perhaps we need: - smaller dependencies between the YaST modules - a new "YaST2-installation" which contains all relevant parts (impossible imho) - a new step for deinstallation unneeded modules/rpms after installation is finished New items for AJs list: - Look for packages with more than x MB (lets start with 10MB) size and see if we can downsize them by repackaging. - Let the "base" pattern become very small and minimalistic. I agree with Klaus that we perhaps need something like a bash - but if you say that, there will probably be someone saying "I need that f****ing 20MB editor named vi - or this is no minimal system to live with". So why not put only stuff like kernel, glibc and ... in the base pattern a system can not start with. Extend these base pattern with additional patterns like "System administration (YaST)", usefull system tools (vi, joe, ifconfig, ...). => This should result in a very small base pattern (target 1) => We can discuss about the additional (system) patterns for the base system in seperate threats. Lars --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

T24gMS8xOC8wNywgQW5kcmVhcyBKYWVnZXIgPGFqQHN1c2UuZGU+IHdyb3RlOgo+ICJDbGFlcyBCw6Rja3N0csO2bSIgPGNsYWVzLmJhY2tzdHJvbUBnbWFpbC5jb20+IHdyaXRlczoKPgo+ID4gU29tZXRoaW5nIEkgd291bGQgbGlrZSB0byBzZWUgaW4gdGhlICJiYXNlIiBwYXR0ZXJuIGlzIHRvb2xzIHRvCj4gPiBpbnN0YWxsIG5ldyBzb2Z0d2FyZSBhbmQgd2l0aCB0aGF0IEkgZG9uJ3Qgb25seSBtZWFuIHJwbSBidXQgYSB3YXkgdG8KPiA+IHVzZSBhIG5ldHdvcmsgc291cmNlIGZvciBpbnN0YWxsYXRpb24gYW5kIHVwZGF0ZSBwZXJoYXBzIHp5cHBlcj8gQW5kIEkKPiA+IHBlcnNvbmFsbHkgbmV2ZXIgaW5zdGFsbCBhIG1hY2hpbmUgbm93ZGF5cyB3aXRob3V0IGx2bTIgc28gZm9yIG1lIHRoYXQKPiA+IGlzIGEgZXNzZW50aWFsIHRvb2wgKG90aGVycyBtaWdodCBkaXNhZ3JlZSkuIEJ1dCB0aGUgdXBkYXRlL2luc3RhbGwKPiA+IHBhcnRzIGlzIHRoZSBtb3N0IGltcG9ydGFudC4KPgo+IFlvdSBjYW4gYWx3YXlzIGFkZCBvdGhlciBwYWNrYWdlcyBpZiBuZWVkZWQgZm9yIGluc3RhbGxhdGlvbi4gIFNvLCBpZgo+IHRoZXJlJ3MgYWdyZWVtZW50IHRoYXQgbHZtIGlzIG5vdCBwYXJ0IG9mIHRoZSBiYXJlIGJhc2UsIHlvdSB3b3VsZAo+IGhhdmUgdG8gYWRkIGl0IG1hbnVhbGx5Li4uCj4KPiBBbmRyZWFzCgpZZXMgc28gSSBkb24ndCB0aGluayB0aGF0IGlzIHNvIHZlcnkgaW1wb3J0YW50LiBFdmVuIGJldHRlciB3b3VsZCBiZQppZiB0aGUgaW5zdGFsbGF0aW9uIHdvdWxkIGRldGVjdCB0aGF0IEkgaGF2ZSBjb25maWd1cmVkIGx2bSBvciBldm1zIHNvCml0IHdvdWxkIGF1dG9hZGQgdGhlIHRvb2xzIGZvciBpdCwgYW5kIGlmIHdlIGRvIGl0IGxpa2UgdGhhdCBpcyBzaG91bGQKTk9UIGJlIGluIHRoZSBwYXR0ZXJuLgoKV2FybSBSZWdhcmRzLApDbGFlcyBCYWNrc3Ryb20K---------------------------------------------------------------------To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.orgFor additional commands, e-mail: opensuse-factory+help@opensuse.org

Hans Witvliet <hwit@a-domani.nl> writes:

Hi Andreas,

Well, LVM would be the wrong example. It should not be a black-or-white situation:

Very early on, a hardware detection should be done. And, for instance, only if tv-harware is found, only then the yast modules for confifuring tv should be installed.

If you want to configure your basic system with lvm, you'll need lvm right away, but only in that case!

Yes, I agree. That's where we should go. But for that you first need to define the absolute base.

I have a feeling that the dependency (for yast-modules) is too rigid: you get it, wether you need (or want) it or not. Refining the threads?

The "minimal" system for 10.1 had a "rather large foot print" to put it mildly, and got worse on 10.2.

So, let's work together to get it smaller again - I'm down right now to 400 MB. Still far too much but now it gets more tricky...

If (and only if) i decide to install any resource-pig, disk-space and mem will be claimed. Not for: "perhaps they want it perhaps later on or so." If I want or need it, i'll selected & install it.

I agree that should be the philosophy behind the minimal system.

I know, that systems tend to grow larger and larger (tnx to M$), but please, try to have a minimal system realy minimal.

Please help me with it ;-) Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

"Claes Bäckström" <claes.backstrom@gmail.com> writes:

Could we perhaps see a list of what you so far put in the "base" or do you need more time to tinker with it?

Here's my current list - but it depends on the definition that we have. Since I'm not sure whether we have consensus I didn't want to share it with you. The list does not contain YaST modules, they are in a different list - and that one needs further time to clean up. The next factory sync will contain my current lists as well. Note that in most cases I omitted dependencies, so e.g. glibc in the list below could be removed since it's required by others. grep is not in the list but required by aaa_base. aaa_base aaa_skel bash bzip2 coreutils cpio dbus-1 dhcpcd e2fsprogs filesystem fillup glibc gzip hwinfo insserv #if !defined(__s390__) kbd #endif klogd ksymoops logrotate mingetty mkinitrd module-init-tools net-tools netcfg openssh pam pam-modules procps pwdutils rpm sed openSUSE-release suse-build-key sysconfig syslog-ng sysvinit tar util-linux #ifdef __ia64__ elilo efibootmgr ia32el #endif #if defined(__i386__) || defined (__x86_64__) grub #endif #ifdef __powerpc__ lilo #endif If you think that something should be removed or added, let's discuss it - and explain your definition of base, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Gerd Hoffmann <kraxel@suse.de> writes:

Andreas Jaeger wrote:

...

"Claes Bäckström" <claes.backstrom@gmail.com> writes:

Note that in most cases I omitted dependencies, so e.g. glibc in the list below could be removed since it's required by others. grep is not in the list but required by aaa_base.

Oh, the dependencies are interesting too. perl for example is quite big, would be nice to *not* require it in the base system, it's almost impossible now to get rid of it without breaking dependencies ...

Yes, I agree. But this is a second step. If anybody is interested in getting this smaller, ideas and patches are welcome. But this is nothing I personally will do right now, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Jim Pye <jim.pye@pyenet.co.nz> writes:

Andreas

I see that openssh is there, good. Having that gives the ability to do a lot of things remotely if networking is included (Which looks as if it is as dhcpcd is there)

However one thing I see missing, it could however be in things like coreutils, is an editor. Not wanting to start a flame war but vi, emacs, pico, nano etc.

That's why I decided to leave this out. I do expect that those experts that use the minimal base system will add their own choice.

My definition of base system (minimum system) would also be the hardware it runs on. Minimum memory, graphics/text display etc. When constructing a minimum/base system this could be taken into consideration when choosing pieces to be included or not.

What exactly do you mean here? Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On Mon, 2007-01-22 at 16:18 +0100, jdd wrote:

Andreas Jaeger wrote:

...

That's why I decided to leave this out. I do expect that those experts that use the minimal base system will add their own choice.

I don't agree. A minimal system without any editor is useless.

The minimal system does not need an editor, only the admin does, and the perfect editor is the one that is added to the base by the admin. Think of the minimal system as equal to the foundation of a building. The foundation has no need for windows or doors but the people that use the building that is put on top of the foundation do. Ken Schneider --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

...

The minimal system does not need an editor, only the admin does, and the perfect editor is the one that is added to the base by the admin.

Think of the minimal system as equal to the foundation of a building. The foundation has no need for windows or doors but the people that use the building that is put on top of the foundation do.

Nice analogy.

However, that brings us back to the goal we're trying to achieve here:

Do we want to define a good foundation for a house or do we want to define all parts mandatory for a house ? That is, if you take a single part away, it wouldn't be called a house any more.

We can envisage that this minimum system would not be used by the all the users but only by let's say more "advanced users" so we could really work on a minimum system that would make happy who works on embedded system (I see someone on this thread talking about it). Maybe, in the case that someone select this "minimum system", recommendations could be made (i.e recommended packages) I just have no idea on work required to do something similar .-) Gaël

On 1/22/07, Klaus Kaempf <kkaempf@suse.de> wrote:

* Andreas Jaeger <aj@suse.de> [Jan 22. 2007 15:50]:

...

Jim Pye <jim.pye@pyenet.co.nz> writes:

...

However one thing I see missing, it could however be in things like coreutils, is an editor. Not wanting to start a flame war but vi, emacs, pico, nano etc.

That's why I decided to leave this out. I do expect that those experts that use the minimal base system will add their own choice.

We could define the functionality "text editor" as a requirement, fulfilled by any of the mentioned packages. So you can't have a minimal system without an editor but you're still free to choose your own.

Yes please do, as I love vi and I probably never get that in the base pattern as many others think it's not user-friendly. Warm Regards, Claes Backstrom --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Klaus Kaempf wrote:

* Andreas Jaeger <aj@suse.de> [Jan 22. 2007 15:50]:

...

Jim Pye <jim.pye@pyenet.co.nz> writes:

...

Andreas

I see that openssh is there, good. Having that gives the ability to do a lot of things remotely if networking is included (Which looks as if it is as dhcpcd is there)

However one thing I see missing, it could however be in things like coreutils, is an editor. Not wanting to start a flame war but vi, emacs, pico, nano etc. That's why I decided to leave this out. I do expect that those experts that use the minimal base system will add their own choice.

We could define the functionality "text editor" as a requirement, fulfilled by any of the mentioned packages. So you can't have a minimal system without an editor but you're still free to choose your own.

Think about the consequences - for years we have assured all and sundry that the one thing in life that you can depend on is that any unix install will include vi. To suddenly yank that rug of security out from under an unsuspecting world would be outrageous. Joe --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Klaus Kaempf wrote:

Well, the default should stay with 'vi' , I agree. The question is, do we want to enforce this default or allow alternatives ?

and more the question is what incarnation of vi... I made a search, some time ago, there is no "original vi" nowaday. Vim is very nice but big, and there are many vi clones we have to ask us how small we want this to be. the smaller at all would be busybox related, minimal floppy distros like mulinux _have_ a minimal editor that can mimics as well vi as nano or pico. but this is probably too far to go jdd -- http://www.dodin.net Votez pour nous, merci - vote for us, thanks :-) http://musique.sfrjeunestalents.fr/artiste/Magic-Alliance/ http://photo.sfrjeunestalents.fr/artiste/jddphoto/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Jim Pye wrote:

10.1 and 10.2 does not handle the default resolution of the very first screens of the install.

textmode=1 jdd

-- http://www.dodin.net Votez pour nous, merci - vote for us, thanks :-) http://musique.sfrjeunestalents.fr/artiste/Magic-Alliance/ http://photo.sfrjeunestalents.fr/artiste/jddphoto/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Wed, 24 Jan 2007, Jim Pye wrote:

On Mon, 2007-01-22 at 22:31 +0100, jdd wrote:

...

Jim Pye wrote:

...

10.1 and 10.2 does not handle the default resolution of the very first screens of the install.

textmode=1

Problem was the screen where you enter this is the one trashed :-(

The work around was to have some doco that had screen shots that I could use to guess the right keypresses to be able to use the F3 (IIRC) to select VGA mode or enter options like above.

Guess I will have to upgrade the monitor when it finally buys the big one. But that it not likely soon, as I said it is unplugged most of the time.

I too had this problem on a few systems. It was reported by a few before rc but was not fixed. This is a case where I think more testing would have assisted the release. This really should have had a higher priority so it was fixed before release. I think there were a few of them. I wish the word had been raised earlier than it was to find bugs that should have had their priority raised and fixed before release. Over all this 10.2 release was the best. I think the devs really need to be acknowledged for their great work on such a good release. -- Boyd Gerber <gerberb@zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

1) logrotate is a beautifull tool, but should be optional, just like sed, (since i'm a perl convert, i abandonned sed, awk....)

I didn't think about that one being optional but, well, you're right, if we are talking about a minimum installation let's have it really minimum, this way nobody would be jealous :-)

Are you willing to re-analyse all packages, and rewrite the spec-files? Eventhough the effort will be worthwhile, considering the concequences, do you think it feasable for 10.3?

I suppose that it would be probably difficult/dangerous to try to it for 10.3 but we could see as a work-in-progress, some kind of "hidden" option during the installation, the default being similar to the current opensuse version. But I think that it should be done (especially if you see it going from opensuse to sles: less code, less bugs, more stability, more security :-) and, well, I would love to have the minimum suse system being near the debian basic system :-) Kins regards, Gaël

On Tue, 23 Jan 2007, Andreas Jaeger wrote:

Hans Witvliet <hwit@a-domani.nl> writes: ...

...

Why have dhcp, *if* one chooses for static address?

What do others think?

I really would like to see dhcp removed. It should be an additional choice. This would really speed things up. I have to wait almost 10 minutes because I have 3-4 network cards in my machine. They all have static IP's. I do not use dhcp. If/when I do use it I have most IP's assigned so that the machines are accessible at the same locations. Most people I work with do not use dhcp. When I have multiple ISP's. Usually one one assigns IP's via dhcp. In that case I would select dhcp. I really dislike it as a default. -- Boyd Gerber <gerberb@zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tue, 2007-01-23 at 13:59 +0100, Andreas Jaeger wrote:

> 
> >
> > 2) Get the base-packages as slim as possible: not even networking!
> > If i want ethernet/isdn/i2c/??? OR i want to perform an installation via
> > http/ftp/tftp/nfs it is my decision!
> > The only thing that a base-package should be able to do, is installing
> > other packages. I would suggest to think about the base-package as the
> > ground work for embedded systems, that have a minimum hardware
> 
> Here we disagree.  This is another purpose than what we need.
Don't think so.
Allthough it's good to keep your mind on what you're doing, it's good to
contemplate what and why one is doing something.
(correct me if i'm wrong or stray to far off ;-)
Currently, when installing you have four starting points with the
installer:
1) standard Gnome desktop
2) standard KDE desktop
3) Minimum with X
4) Minimum

With either of them you have the base package, and a number of
selectable threads (was: selections) and of course individual selectable
packages.

Even with "minimal" you get a lot of goodies, which should have been
selectable options, but are currently:
a) selectable, but "ON" by default, instead of "off" (like tcpdump)
b) have a mis-placed dependancy (like yast modules for radio,tv
blue-teeth, opensc in a system that lacks the hardware)

The first one, you can deselect manually, or create a xml-file for
installing. The second one, you can remove the packages afterwards.

But where are those options are going to?
Some of them, like tcpdump should go back where they orinally came from
powertools, or a "networking-thread" 

>From the top of my head, i remember installation is roughly done in two
stages.
1) running from the initial boot medium (most rpm's ge installed here)
2) after the first boot (in which also configuration is done)

AFAIR, in both stages a hardware scan is performed, not?
Can't you use that to base your descicion on what is initially "on" or
"off"?

Coming back to the "four starting points" isn't that the place to have
more options?
1) feature rich Gnome desktop (current "standard")
2) feature rich KDE desktop (ditto)
3) minimal gnome/kde desktop (fits on a pendrive, no autodetect)
4) minimal with X
5) "home server" 
6) real bare minimalistic starting point (good for XEN DOM-0)
7) suggestion?

> >
> > 3) as you allready stated, you didn't mention the dependancies.
> > And I think, here is where 99,99% of the work lies.
> >
> > For instance ssh has a dependency on opensc (because of libopensc)
> > For me no big deal, as i play around with smartcards and tokes, but for
> > other people? I really fear that the same is true for other packages.
> >
> > Are you willing to re-analyse all packages, and rewrite the spec-files?
> > Eventhough the effort will be worthwhile, considering the concequences,
> > do you think it feasable for 10.3?
> 
> I'm not willing to do all this myself ;-) But I hope that all of you
> will help with that and look at the culprits.  This is something we
> should do together ;-)

Centainly!

> Andreas


-- 
pgp-id: 926EBB12
pgp-fingerprint: BE97 1CBF FAC4 236C 4A73  F76E EDFC D032 926E BB12
Registered linux user: 75761 (http://counter.li.org)
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org
For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hello, Am Freitag, 19. Januar 2007 11:47 schrieb Andreas Jaeger:

ksymoops

If I get the package description right, ksymoops is a debugging tool for kernel error messages. I doubt you need it on a minimal system ;-) Additionally, no package depends on it - I could rpm -e it even on my full-blown installation. BTW: It would be more useful to have a list with all dependencies (or, even better, rpm -qa --qf "%{name}\t%{size}\n" | sort of such a minimal system). Regards, Christian Boltz -- Pinguine sind picklige Geeks, die sich ihren Sonnenbrand vorm Monitor holen. [Ratti] --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

"Claes Bäckström" <claes.backstrom@gmail.com> writes:

[removed long list]

Thanks - I let others comment first ;-)

Please add some comments or input what you think about this. I would love to see zypper added to this as well but that's me. (Then rpm could be removed as zypper depends on it)

There's an extra pattern that has zypper in it - and that one is installed by default.

Not sure how the kernel-default is installed during the installation if it's done with rpm more packages could be removed like mkinitrd.

It's done via some YaST magic, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On Mon, Jan 22, 2007 at 04:26:33PM +0100, Klaus Kaempf wrote:

In the future, the kernel package should advertise itself via dependencies

It does already by the symbol "kernel". Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."

On Mon, Jan 22, 2007 at 05:34:02PM +0100, Klaus Kaempf wrote:

* Robert Schiele <rschiele@gmail.com> [Jan 22. 2007 16:56]:

...

On Mon, Jan 22, 2007 at 04:26:33PM +0100, Klaus Kaempf wrote:

...

In the future, the kernel package should advertise itself via dependencies

It does already by the symbol "kernel".

But you still don't know if to choose kernel-default or kernel-bigsmp ;-)

Right, but _this_ decission can never be done by the package resolver but will always require input from a hardware capabilities test program. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."

"Claes Bäckström" <claes.backstrom@gmail.com> writes:

Here is my try to build a "base" pattern. For me this is aimed for a base computer that I can choose to build as a server or a workstation that only have the tools and functions the machine need. Like bastion dns, web, database server or a small and working graphical workstation. So this is not for a embeded environment. For an emebeded environment alot more work should be needed. Like replacing glibc with uclibc, dietlibc or something small like that. And the embeded systems I have all have arm cpu's so a little work is needed there as well.

This list is based on aj's list he sent out earlier with some comments.

aaa_base aaa_skel # bash aaa_base depends on this so it could be removed # bzip2 not needed # coreutils hwinfo depends on this so it could be removed # cpio aaa_base depends on this so it could be removed # dbus-1 dhcpcd depends on this so it could be removed dhcpcd # e2fsprogs mkinitrd depends on this so it could be removed # filesystem aaa_base depends on this so it could be removed # fillup aaa_base depends on this so it could be removed # glibc aaa_base depends on this so it could be removed

I'm a bit scared by all these dependencies - but ok, let's remove them and see where we go...

# gzip mkinitrd depends on this so it could be removed hwinfo # insserv aaa_base depends on this so it could be removed #if !defined(__s390__) kbd #endif # klogd syslog-ng depends on this so it could be removed # ksymoops not needed

Ok.

# logrotate aaa_base depends on this so it could be removed # mingetty aaa_base depends on this so it could be removed mkinitrd module-init-tools # net-tools aaa_base depends on this so it could be removed netcfg openssh # pam coreutils depends on this so it could be removed # pam-modules pwdutils depends on this so it could be removed procps pwdutils rpm # sed aaa_base depends on this so it could be removed openSUSE-release suse-build-key sysconfig syslog-ng # sysvinit mkinitrd depends on this so it could be removed # tar not needed # util-linux mkinitrd and module-init-tools depends on this so it could be removed

#ifdef __ia64__ elilo efibootmgr ia32el #endif #if defined(__i386__) || defined (__x86_64__) grub #endif #ifdef __powerpc__ lilo #endif

This leaves this list:

Ok, I've done the changes now - let's see how it works out, Thanks, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On 1/18/07, Klaus Kaempf <kkaempf@suse.de> wrote:

* Claes Bäckström <claes.backstrom@gmail.com> [Jan 18. 2007 09:56]:

...

Something I would like to see in the "base" pattern is tools to install new software and with that I don't only mean rpm but a way to use a network source for installation and update perhaps zypper?

As written before, I'd see such tools as convenience applications.

Maybe we should define the purpose and application of such a 'base' pattern first. Is it for 1. installing a really minimal but somewhat usable system via CD/DVD ? 2. running a (Xen) virtual guest ? 3. running a chroot environment ?

For 1., a minimal YaST or zypper would be essential, I agree.

For 2. or 3. a bash prompt would probably be sufficient (plus a way to install the application you want to run virtualized.)

Klaus

I see your point. And I agree. I just see a problem that it could lead to a lot of "servers" unmaintained updatewise. And that could be a potential problem. We should also think about the people not active in the opensuse community but still using it. I believe that they would choose base system to install thinking "I can add the rest of the stuff later." When we then tell them to download 10 (number taken from the air) rpm by hand and move to the server and then install with rpm they would say it sucks. But on the other side, you are correct. If would like to see opensuse used in embeded environments that puts it in another light. Now I even confused myself to the point that I'm not sure anymore. Warm Regards, Claes Backstrom

On Fri 19 Jan 2007 02:38:32 NZDT +1300, Jan Kupec wrote:

...

For 1., a minimal YaST or zypper would be essential, I agree.

installed size of libzypp + zypper is cca 7.2 MB

I see this as essential. A system so small that I can't conveniently install more software is no good to me. When I need to resolve dependencies manually because there's only rpm, it's on the other side of useful. The daemons' chroots are so minimal, it's only a few files, no point "installing a system" for. If it's slightly bigger it approaches fast a system which would run on actual hardware, and that needs to be maintained, and as importantly kept uptodate. Chroot or not, I don't see how that can work without zypp. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

* Gerd Hoffmann <kraxel@suse.de> [Jan 18. 2007 16:03]:

Klaus Kaempf wrote:

...

For 2. or 3. a bash prompt would probably be sufficient (plus a way to install the application you want to run virtualized.)

Xen: no. You don't use xen guests just to boot to the bash prompt, usually you want to do something useful with them.

Agreed. But "something useful" can mean a lot of things ;-)

So you need some convinent way to install software. You also want security updates for them. I don't see how xen guests are that much different than a minimum system on real hardware.

Depends on how you manage your xen guests. From the 'inside' (having network and e.g. online-update running inside the guest) or the 'outside' (loopback mounting the image and install selected updates) ? In the end, its the (usual) decision between security and convenience. For security, you only want those packages installed needed by your application. Otoh, having software management utilities available can be very convenient.

chroot: very much depends on what you plan to do with it. The chroots which are created for running daemons in there (named, dhcpd, ...) are smaller than any package on the distro ;) For building packages you don't need network, but some other tools such as make and a compiler.

Exactly. But even for these environments, you probably need a minimal set of packages like glibc, bash, etc. The question is, shouldn't this minimal set be the 'very minimal base' (:-)) pattern ? Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

* Gerd Hoffmann <kraxel@suse.de> [Jan 18. 2007 17:14]:

Inside. Outside implies downtime.

Inside has the risk of breaking your system if an update is broken. Outside does not necessarily mean a long downtime. Imagine the following. - create a copy of the virtual image - loopback mount it - apply updates - run this patched image in a controlled environment to verify the correctness of the update. - take the original image down - boot the updated image It still has a downtime larger than a simple application restart.

Or do you install security updates on real hardware by booting the rescue system, mounting disk and installing them?

Basically yes, for virtual images. Enterprise customers are asking for this capability as described above.

...

But even for these environments, you probably need a minimal set of packages like glibc, bash, etc. The question is, shouldn't this minimal set be the 'very minimal base' (:-)) pattern ?

Hmm, maybe we need two then? One "boot to bash prompt" and one "rescue-system like, with network and zypper"?

Yes. The latter one could simply depend on the first one. Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

* Robert Schiele <rschiele@gmail.com> [01-18-07 15:54]: [...]

So if this discussion should become constructive you should discuss about a minimal pattern that should be installed when installing a new system or a pattern that should be installed for doing this or that but not mix up everything and call this undefined thing "minimal pattern set".

So, SOMEONE needs to take the lead and SET parameters for *minimal* and let everybody add to that to achieve what they desire as *minimal*. You are correct that a consensus will not be reached. 1. Set a minimum minimal 2. Define several small adds or enhancements for minimal 3. Publish and allow everyone to achieve their own status -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2 OpenSUSE Linux http://en.opensuse.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

* Robert Schiele <rschiele@gmail.com> [Jan 18. 2007 23:04]:

...

So, SOMEONE needs to take the lead and SET parameters for *minimal* and let everybody add to that to achieve what they desire as *minimal*.

You are correct that a consensus will not be reached.

1. Set a minimum minimal

As I already said this is the empty set because for _every_ package you name I can find a use case where this one is not needed. I don't get it why some people insist on having a "generic minimum set" without having a concrete use case.

Maybe you have missed earlier discussions where three example usecases were presented for discussion: 1. installing a really minimal but somewhat usable system via CD/DVD 2. running a (Xen) virtual guest 3. running a chroot environment The intersection of packages for these usecases is what we're looking for. Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Fri, Jan 19, 2007 at 08:55:54AM +1100, Graham Smith wrote:

What might be needed is a "base package set" plus a number of extra pattern sets to cover specific jobs like:-

a) minimal networking b) package management c) virtualised systems

You would then select the "base package set", then whatever patterns you need to configure a certain system. This may need to placed under an advanced section of the package management to reduce the problems faced by newbies.

This is the thinko! Why should one have to select a "base package set" and "minimal networking" if he just wants "minimal networking" (whatever that would be)? Why shouldn't he just select _only_ "minimal networking" if this is what he wants? Sure, your various use cases might have a common kernel but there is no need to make this explicit, the dependency resolver is doing that for you. There is absolutely no point in presenting something without a meaning to the user. Honestly, most people in this thread try to solve a problem that is just not existing. That's like people in "The Hitchhiker's Guide to the Galaxy" trying to find the answer without knowing the question at all. I recommend that people interested in finding a solution for the scenario Andreas was talking about, write this in this thread. People that want to talk about chroot/xen/whatever just first think about what they actually want and if they found that then start a _new_ discussion because posting this in this thread is off-topic and just confusing the discussion. And describe your use case in a _detailed_ way because the less detailed your use case is the more troll-like will be the resulting discussion. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."

On Fri, Jan 19, 2007 at 10:52:06AM +0100, Klaus Kaempf wrote:

* Robert Schiele <rschiele@gmail.com> [Jan 18. 2007 23:04]:

...

As I already said this is the empty set because for _every_ package you name I can find a use case where this one is not needed. I don't get it why some people insist on having a "generic minimum set" without having a concrete use case.

Maybe you have missed earlier discussions where three example usecases were presented for discussion:

No, I did not miss that discussion but I can't see why all these use cases have to be unified into a single use case that just does not exist in reality.

1. installing a really minimal but somewhat usable system via CD/DVD 2. running a (Xen) virtual guest 3. running a chroot environment

The intersection of packages for these usecases is what we're looking for.

Why does one have to define this intersection explicitly? On Fri, Jan 19, 2007 at 10:59:23AM +0100, Klaus Kaempf wrote:

* Robert Schiele <rschiele@gmail.com> [Jan 18. 2007 23:19]:

...

This is the thinko! Why should one have to select a "base package set" and "minimal networking" if he just wants "minimal networking" (whatever that would be)?

There is no need to select both. "minimal networking" would install "base package set" through dependencies. It just that "minimal networking" is option (can be deselected) but "base package set" is not.

So why do we need "base package set" at all?

To me the question is, which packages (resp. patterns) should be enforced (required) by an openSUSE system and which are optional.

That actually depends on your use case. I mean for example on installation YaST has to enforce installation of a kernel (among other things), thus a kernel must be part of a package set defining a minimal set YaST must enforce on installation. But why is it important for you to know whether a kernel is needed in _all_ possible use cases. I mean when you implement the pattern for YaST installation you should try to solve _this_ question and not all other similar problems of the world at the same time.

If one still wants to de-install one of these packages, the resulting system isn't considered openSUSE any more.

Why do you need a set of packages to name "openSUSE"? If a set of packages fulfilles the specific needs of a use case then the set is fine, if it does not, it is broken for that use case. So what to you need this common intersection? I mean if you feel the need to answer the pure philosophical question on how this abstract construction has to look like according to your opinion then head on. I just say that you waste your time, will never come to a serious conclusion, and kill every serious discussion on related threads trying to find a pattern for a serious use case. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."

On Fri, Jan 19, 2007 at 12:11:23PM +0100, jdd wrote:

Robert Schiele wrote:

...

So why do we need "base package set" at all?

may be this package set don't have to be seen by the final user, but it have to be defined not to have to duplicate it's list in any of the situations we have already seen

Duplication of entries is not a severe problem if dependencies between packages are done in a reasonable way. Maintaining duplicate entries only becomes a real problem if you also add packages to the list that are not required for the use case by semantic reasons but only due to rechnical requirements (dependencies). For instance bash is often listed as being part of a minimal installation pattern for a normal system installation. This is wrong! For _using_ an installed system bash is not needed. It is obviously needed for some other packages to run their startup scripts and stuff like that. But this is solved by the other packages drawing in bash by dependencies. This also applies to glibc and more packages. If you list them explicitely you have made the mess yourself.

in fact this sub minimal list will be a dependency for all the patterns, so will not have to exists visibly, but we still need it here

No, we only need it if we don't do the patterns in the right way as described above. Although people _know_ that dependencies are resolved automatically, according to the way they do patterns they have not yet _realized_ it. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."

On 1/19/07, jdd <jdd@dodin.org> wrote:

Robert Schiele wrote:

...

No, we only need it if we don't do the patterns in the right way as described above. Although people _know_ that dependencies are resolved automatically, according to the way they do patterns they have not yet _realized_ it.

possible :-)

as of bash, for example, there are very small app to replace unix commands (busybox) that could be used on very minimal system jdd

I am a firm believer in that rpm packages should depend on the functions they need. No rpm package should take for granted that something is installed in the "base" pattern. I also hate it when single rpm packages depends on patterns (not sure if this exist in openSUSE) they should depend on rpm packages. And also thinks that a pattern should not depend on rpm packages that other rpm packages included in the pattern also depends on, as there is no need for that. This is not a problem technical speaking it's just harder to maintain and confusing to people. I hope we can agree on this things so we know how to move on. Warm Regards, Claes Backstrom --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 1/19/07, Andreas Jaeger <aj@suse.de> wrote:

"Claes Bäckström" <claes.backstrom@gmail.com> writes:

...

I am a firm believer in that rpm packages should depend on the functions they need. No rpm package should take for granted that something is installed in the "base" pattern. I also hate it when

I agree - and if this is not the case, it's worth a bugreport.

Great wasn't sure if this was the way suse worked now I know and will report any signs of this to bugzilla.

...

single rpm packages depends on patterns (not sure if this exist in openSUSE) they should depend on rpm packages.

There's no such case.

And I hope there will never be any. If it will happen I will report that to bugzilla as well .

...

And also thinks that a pattern should not depend on rpm packages that other rpm packages included in the pattern also depends on, as there is no need for that. This is not a problem technical speaking it's just harder to maintain and confusing to people.

I'm not sure I understand you here. Could you rephrase this, please?

Well I can try to explain what I mean with an example. (names as so on is just imagination) Say we have a backup pattern. Something like this: ---- securebackup (the tool that does the backups) tar bzip2 openssh --- The securebackup tool uses tar and bzip2 to do the backup then scp it to another server. This means that securebackup rpm depends on tar, bzip2 and openssh. In my meaning the backup pattern is wrong. It should only depend on securebackup as that will install tar, bzip2 and openssh. This means when securebackup is dead upstreams and no one will fork it. It's very simple to change the backup pattern to depend on gnubackup that uses tar, gzip and ssh instead. No need to change the backup pattern removing bzip2 and adding gzip to it. I hope this example explains what I was talking about. Warm Regards, Claes Backstrom

On 1/22/07, Andreas Jaeger <aj@suse.de> wrote:

Then we agree completely. I might not have done it consequently in my patterns, so you find redundancy, please tell me and I fix it ;-)

Andreas

Well not sure how you want this information. Checked the zmd-10.2-145.i586.pat +Prq: libzypp-zmd-backend rug zmd -Prq: +Psg: pin -Psg: And rug depends on zmd and zmd depends on libzypp-zmd-backend so rug is all that it need to have. Andreas do you want me to go on with more patterns? Warm Regards, Claes Backstrom --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

* Claes Bäckström <claes.backstrom@gmail.com> [Jan 19. 2007 13:11]:

I am a firm believer in that rpm packages should depend on the functions they need. No rpm package should take for granted that something is installed in the "base" pattern. I also hate it when single rpm packages depends on patterns (not sure if this exist in openSUSE) they should depend on rpm packages.

Fully agreed. We do not want to undermine package dependencies with patterns. Pattern should help to define 'building blocks' to ease software management.

And also thinks that a pattern should not depend on rpm packages that other rpm packages included in the pattern also depends on, as there is no need for that. This is not a problem technical speaking it's just harder to maintain and confusing to people.

Agreed. To get this right in every case probably needs tools support to - detect transitive dependencies - detect sub-patterns (if a subset of packages listed in a pattern effectively matches an already existing pattern) Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

* Robert Schiele <rschiele@gmail.com> [Jan 19. 2007 11:24]:

No, I did not miss that discussion but I can't see why all these use cases have to be unified into a single use case that just does not exist in reality.

Its not a unification, its what these use cases have in common.

So why do we need "base package set" at all?

Such a pattern would be helpful when displaying dependency problems. E.g. when removing glibc from a system, instead of listing hundreds of packages with broken dependencies, YaST could simple tell "this breaks your base system"

Why do you need a set of packages to name "openSUSE"? If a set of packages fulfilles the specific needs of a use case then the set is fine, if it does not, it is broken for that use case.

We need to identify the distribution in order to assign the correct update repository. Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Schiele wrote: [...]

So what people actually mean when they say "minimal package set" is actually either a "what-_I_-want-at-least-on-my-system package set" or a "what-is-needed-for-a-specific-job pattern set". In the first case you will never reach consesus by obvious reasons. In the second case you don't need _the_ "minimal package set" but you need _a_ "minimal package set" for a specific job.

So if this discussion should become constructive you should discuss about a minimal pattern that should be installed when installing a new system or a pattern that should be installed for doing this or that but not mix up everything and call this undefined thing "minimal pattern set".

That's pretty much was I was about to post on the topic. I think the discussion is not going anywhere because everyone has a different understanding of "minimal package set". As Robert wrote, I think we should first define what kind of "minimal package sets" we want/need. - From the discussion up to this point, there were already a few interesting proposals: - - chroot (that's probably the most minimalistic, not even RPM in there) - - very small without network (if that's of any use at all) - - very small with network etc... cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD4DBQFFr+9zr3NMWliFcXcRAt3FAJd59zad/ydA/rJdnWtYh0XVyFZ8AJ9hFq8b 5ae5zMlQo5dR4gbUHOkOLw== =r560 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Op donderdag 18 januari 2007 23:06, schreef Pascal Bleser:

From the discussion up to this point, there were already a few interesting proposals: - chroot (that's probably the most minimalistic, not even RPM in there) - very small without network (if that's of any use at all) - very small with network

very small with network + X for Thin Clients. -- Richard Bos Without a home the journey is endless --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

PiBUaGluayBtaW5pbWFsIGluc3RhbGwgcGx1cyB0aGUgYWJpbGl0eSB0byBhZGQgd2hhdCBfeW91XyBuZWVkIHRvIGl0LiBUaGUKPiBtaW5pbWFsIGluc3RhbGwgZG9lc24ndCBuZWVkIG5ldHdvcmtpbmcgb25seSB0aGUgYWJpbGl0eSB0byBhZGQgYXMgYW4KPiBleHRyYSBjaG9pY2UuCj4KPiBLZW4gU2NobmVpZGVyCgpJIGFncmVlIHdpdGggeW91LiBXZSByZWFsbHkgc2hvdWxkIHRoaW5rIG1pbmltYWwgYW5kIHRoZW4gaGF2ZSB0aGUKaW5zdGFsbGF0aW9uIChvciBwb3N0LWluc3RhbGxhdGlvbikgZ2l2aW5nIHlvdSB0aGUgcG9zc2liaWxpdHkgdG8gYWRkCndoYXQgeW91IG5lZWQ6IFhlbiwgbHZtLCAuLi4KCkknbSBjdXJyZW50bHkgcmVtb3ZpbmcgKy8tIDgwIHJwbXMgZnJvbSBhIGJhc2UgT3BlblN1c2UgYW5kIFNMRVMgYW5kIEkKd291bGQgcHJlZmVyIHRvIGhhdmUgdG8gYWRkIHRoZW0gbGF0ZXIuCgpBY3R1YWxseSBJJ20gYSBsaXR0bGUgYmlhc2VkIGNhdXNlIEknbSB1c2luZyBzdXNlIG9uIHNlcnZlcnMsIG5vdCBhcyBhCmRlc2t0b3AuIEluIHRoaXMgc2Vuc2UgaXQgd291bGQgYmUgZmluZSB3aXRoIHRvIG1lIGhhdmUgYnkgZGVmYXVsdCBhCiJiYXNlIHN5c3RlbSIgd2hpY2ggd291bGQgYmUgZmluZSB3aXRoICJub3JtYWwgdXNlcnMiIGJ1dCBoYXZpbmcgdGhlCnBvc3NpYmlsaXR5IGR1cmluZyB0aGUgaW5zdGFsbGF0aW9uIHRvIHNlbGVjdCBhICJtaW5pbXVtIHN5c3RlbSIuIFRha2UKaW50byBjb25zaWRlcmF0aW9uIHRoYXQgSSdtIHRoaW5raW5nIG1pbmltYWwgZm9yIHNlcnZlcnMgb24gd2hpY2ggSQp3b3VsZCBhZGQgYXBhY2hlLCBwb3N0Zml4LCB0b21jYXQsIGV0YyAuLi4sIG5vdCBlbWJlZGRlZCBzeXN0ZW1zLgoKQWN0dWFsbHkgSSB3b3VsZCBsb3ZlIHRvIHNlZSB0aGUgYmFzaWMgc3VzZSBiZWVuIGxlc3MgZmF0LCBpLmUgbmVhcgpkZWJpYW4ncyBiYXNlIHN5c3RlbSB3aGljaCBpcyArLy0gMzUwIE1CIChhdCBsZWFzdCB0aGF0IHdoYXQgSQpyZW1lbWJlciBmcm9tIG15IGxhc3QgaW5zdGFsbGF0aW9uIDIgeWVhcnMgYWdvKQoKS2luZyByZWdhcmRzLAoKR2HDq2wK---------------------------------------------------------------------To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.orgFor additional commands, e-mail: opensuse-factory+help@opensuse.org

Pascal Bleser <pascal.bleser@skynet.be> writes:

As Robert wrote, I think we should first define what kind of "minimal package sets" we want/need.

And I made a proposal for that one.

From the discussion up to this point, there were already a few interesting proposals: - chroot (that's probably the most minimalistic, not even RPM in there) - very small without network (if that's of any use at all) - very small with network etc...

"very small with network" is the one that I personally like to have as "Minimal Base Pattern": Definition Base System: Purpose: Minimal booting system running on real hardware Multiuser system with: * Local login (via /etc/passwd) * network setup via ethernet * default filesystems used (ext3) directly (without evms, lvm, mdraid etc) * no services running by default * YaST modules for 2nd part of installation I consider networking essential - or do you have real use cases where networking is not needed at all? Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

* Andreas Jaeger <aj@suse.de> [Jan 19. 2007 10:53]:

Definition Base System: Purpose: Minimal booting system running on real hardware Multiuser system with: * Local login (via /etc/passwd) * network setup via ethernet * default filesystems used (ext3) directly (without evms, lvm, mdraid etc) * no services running by default * YaST modules for 2nd part of installation

Can we put package names behind these functionalities ? Then we can easily compute the approximate install size of the system. Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Andreas Jaeger wrote:

I consider networking essential - or do you have real use cases where networking is not needed at all?

of course. why should we have network? stanbdalone machines are nice. modem connection are still frequent (and in this case we don't have network), USB ADSL are not really network and should be let to a second stage and then brand new mother board have network adapters that are not always fine with Linux, not to mention laptops with proprietary wireless NW... I _never_ set the network on the first instal if I have cd/dvd (and, please, do not anymore ask for dhcp at install boot, 1 minute lost anytime for nothing usable at that moment, 1 minute last very long :-) jdd -- http://www.dodin.net Votez pour nous, merci - vote for us, thanks :-) http://musique.sfrjeunestalents.fr/artiste/Magic-Alliance/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thu, 2007-01-18 at 16:03 +0100, Gerd Hoffmann wrote:

Klaus Kaempf wrote:

...

As written before, I'd see such tools as convenience applications.

Maybe we should define the purpose and application of such a 'base' pattern first. Is it for 1. installing a really minimal but somewhat usable system via CD/DVD ?

yes.

...

2. running a (Xen) virtual guest ?

yes.

...

3. running a chroot environment ?

Hmm ...

...

For 1., a minimal YaST or zypper would be essential, I agree.

Yep. I think it should install something roughly comparable to the rescue system (plus zypper to install packages and fetch security updates).

...

For 2. or 3. a bash prompt would probably be sufficient (plus a way to install the application you want to run virtualized.)

Xen: no. You don't use xen guests just to boot to the bash prompt, usually you want to do something useful with them. So you need some convinent way to install software. You also want security updates for them. I don't see how xen guests are that much different than a minimum system on real hardware.

chroot: very much depends on what you plan to do with it. The chroots which are created for running daemons in there (named, dhcpd, ...) are smaller than any package on the distro ;) For building packages you don't need network, but some other tools such as make and a compiler.

cheers, Gerd

You need to "slim-down" on two fronts: Disk-space and/or memory There are a number of tiny (live) distro's that whould run happily from a CD and are full featured graphical desktop, with OO.o, firefox, NX/VNC, gaim,.... Which should be able to have it on a 1GB usb-pendrive !!! While one could use all the mem there is. On the other hand, for XEN, you want to cut down on mem. Good examples for DOM-u's are: -DHCP -DNS -LAMP -Mysql/postgress -temporary compile engine You want to run those images with as little mem as needed At 10.0, i could have those running with as little as 128 MB, with still unclaimed memory. Now, with 10.2, 512 is hardly enough :( Here, disk-space if often not such a problem (SAN/NAS) When thinking of embedded system, then you have to slim down on both... Hans -- pgp-id: 926EBB12 pgp-fingerprint: BE97 1CBF FAC4 236C 4A73 F76E EDFC D032 926E BB12 Registered linux user: 75761 (http://counter.li.org) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Lars Rupp <lrupp@suse.de> writes:

Am Do 18.01.2007 09:39 schrieb Andreas Jaeger <aj@suse.de>:

...

* What do you think of this? Do you have better ideas?

Perhaps we can discuss if we need an additional option "Remove after installation" in the YaST2-Packagemanager - for Example: Some YaST2-Modules can be deleted, when the installation is finished...

I forgot to add: We need some Yast modules for installation: * YaST modules for 2nd part of installation Yes, something to think about, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Dňa Št 18. Január 2007 10:23 Klaus Kaempf napísal:

* Andreas Jaeger <aj@suse.de> [Jan 18. 2007 10:00]:

...

Lars Rupp <lrupp@suse.de> writes:

...

Am Do 18.01.2007 09:39 schrieb Andreas Jaeger <aj@suse.de>:

...

* What do you think of this? Do you have better ideas?

Perhaps we can discuss if we need an additional option "Remove after installation" in the YaST2-Packagemanager - for Example: Some YaST2-Modules can be deleted, when the installation is finished...

I forgot to add: We need some Yast modules for installation: * YaST modules for 2nd part of installation

I tried to deselect YaST modules to achieve this. The current YaST dependencies make it almost impossible. :-(

Then we need to clean it up. Do you have examples? Might shed some light on the complexity of the problem. Stano --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thursday 18 January 2007 08:39, S Glasoe wrote:

Could this be the Damn Small openSUSE Linux equivalent at less than ~50MB? Could this be a Rescue System too? Would it be able to NFS/FTP/HTTP to openSUSE repositories for the rest of the patterns?

I should have read all posts. I would vote for that kind of target that is usable even if it is not expanded. It has disadvantage that we would have to duplicate some packages, but with such small system they can be replaced easily. -- Regards, Rajko. http://en.opensuse.org/Portal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thu, 2007-01-18 at 21:33 -0600, Rajko M. wrote:

On Thursday 18 January 2007 02:39, Andreas Jaeger wrote:

...

I heard from several sides that the base system of openSUSE 10.2 is a bit large - and agree and would like to discuss with you what we can do. ...

I would set target to a basic system that can run and add more packages in a first instance from CD.

Good example, what should be the goal of minmal system, can be a DSL distribution.

Similar based on SUSE can be base for further installation if one wants more. As such base would be only about 50-100 MB pieces can be replaced very fast with bigger brother that has compiled in more functionality. This should be the same as Lars Rupp's idea of repackaging.

This would add some minimalistic tailored packages to the distribution, that can give us a usefull working and expandable (graphic) environment. Than if user needs more he can add software with full functionality that will pull in regular dependencies. That will grow system very fast, but that can be addressed later.

Advantage of this is that users will have small system and chance to bloat their system in direction they really have interest in, and not to be forced to use predefined set that is targeted to all possible usage profiles and demands almost 500 MB for text mode alone.

This combined with ability to store selection of software in user defined pattern (that feature is still not back in YaST) and publish it in some common place where others can access them. That will be some kind of voting machine, where the number of downloads will tell what is really in use and give developers idea what has to be improved.

To prevent idea that such mini installation is real SUSE it can be used MiniSUSE name instead. Hmm, have I seen that name somewhere?

Hey guys, isn't this whole discussion thread just a rehashing of the 1 cd intall with slick? I have said many times that I wished I could get to a gui desktop with the first CD and add what I wanted after that. It would be particularly nice on all my machines that still run a PIII with 10 gig or smaller drive, and yes, I still have a stack of pc's with 4 gig drives and pII's too. I have already played with the different versions of this idea i.e. super, slick and 1 cd and they all do things I like. I have had hopes that OpenSUSE would release a "1 cd install" version that was close enough to SLED desktop in appearance to use it on my PII's\ PIII's and build an application server to host extra's. In a school network I have to image and repair machines during "production" hours and I can't see any reason to load the whole distro when I could just deliver application shortcuts to a stripped down version twice as fast, much like I do now with W2k. I know this will go over like a "Lead Balloon" but a Novell Gnome based 1 cd install would be a huge thing for me and I'm sure the state of Indiana as well. Could this system include something like "sysprep" ? since Novell wants system registration for patch subscriptions and machine names for SMB compatibilty and I am sure lot's of people are looking for an easy imaging solution, this would be real nice! jasujt\fxrsliberty\JT --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Saturday 20 January 2007 12:51, Alexey Eremenko wrote:

I am happy with the base system we have now (10.2), and do *not* want any major changes.

The present status is that we need small base that can be expanded. How to achieve this is a topic of this thread, but obviously no one wants major changes. Although I'm not familiar with distribution creation, it is obvious that just dropping some packages will bring improvement, but still it will be far from usable desktop on single CD. More radical approach as discussed above may bring new way of thinking about distribution creation and upgrades. It will make possible to install openSUSE almost everywhere and upgrade to the level that user finds acceptable. This will eliminate need to guess what user might want, and automatically reduce size of initial system. I know that dependencies that package can't run without, will bloat upgraded system anyway, but that can be addressed later when enough users feedback is collected. -- Regards, Rajko. http://en.opensuse.org/Portal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org