On 24 November 2016 at 10:12, Dominique Leuenberger / DimStar wrote:

On Thu, 2016-11-24 at 09:51 +1030, Simon Lees wrote:

...

There is obvious things to do such as removing packages that are no longer in the repos, there is also a question of whether we keep patterns like "Miscellaneous Server" and "Voice over IP Clients" that you probably wouldn't install directly but make some packages easier to find should be kept.

Before doing any other big or invasive changes i'll of course discuss them here first. Also if someone would like to set up a task on progress.opensuse.org to track it that would be helpful otherwise ill track the items internally.

One thing that has been discussed several times (and I still think would be a good idea) - but will take quite some leg work, is splitting the 'big chunky' patterns-* .spec file into smaller packages.

This would especially be interesting for the 'Desktop Teams' where we can have them maintain their own set of patterns...

One thing I've wanted to see for a while is 'syncing up' the openSUSE Minimal pattern with something analogous/matching the SLE Minimal and Base patterns They work very nicely in SLE, with Minimal being very very minimal and Minimal+Base being what we currently know in openSUSE as 'Minimal', and with both SLE patterns both avoiding some of the weirder recommends-chains that the current openSUSE minimal pattern pulls through So either replacing the current openSUSE Minimal pattern with the equivalent of the SLE Minimal+Base patterns, or really making the openSUSE minimal very similar to the SLE minimal and introducing an openSUSE base pattern would certainly be something I'd like to see On the broader topic, I think Patterns should be 'functional'. I do not like Patterns which act as 'Collections' of packages in a broad category - we have RPM and Package groups for that So patterns like 'Web Server' that pull through Apache and such make sense to me. So do the various Development Patterns, and patterns like Office Software, Graphics, Technical Writing, where people might just want a quick and easy way of setting up openSUSE for a specific purpose, and not exactly care about micromanaging the packages they use to get that purpose. But patterns like 'VOIP Clients' do not make so much sense to me. a "VOIP Client" pattern might make sense if there was one 'default' VOIP client we wanted to make easy to install, but right now installing the pattern does nothing besides install the metadata of the pattern, which makes it next to useless in my not so humble opinion. And "Misc Server" always seemed like a weird pattern for me, for the same reasons So I guess what I'm trying to say is +1 for clean up +1 for adopting good practices from SLE patterns +1 for getting rid of any pattern that doesn't actually install any packages +1 for keeping and improving patterns that do install stuff -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cedric Bosdonnat wrote:

On Thu, 2016-11-24 at 11:38 +0100, Richard Brown wrote:

...

One thing I've wanted to see for a while is 'syncing up' the openSUSE Minimal pattern with something analogous/matching the SLE Minimal and Base patterns

They work very nicely in SLE, with Minimal being very very minimal and Minimal+Base being what we currently know in openSUSE as 'Minimal', and with both SLE patterns both avoiding some of the weirder recommends-chains that the current openSUSE minimal pattern pulls through

So either replacing the current openSUSE Minimal pattern with the equivalent of the SLE Minimal+Base patterns, or really making the openSUSE minimal very similar to the SLE minimal and introducing an openSUSE base pattern would certainly be something I'd like to see

I'ld love to see that too. This would be really helpful to setup system containers on openSUSE. On SLES the Minimal pattern is enough for this purpose, would be great to have something like it on openSUSE.

We've discussed the minimal pattern once or twice in the past, and it always eventually became clear that "minimal" meant something different to different people. Minimal size, minimal functionality, text-only, minimal server, the minimum that'll fit on my <favourite thimble-size device> et cetera. I have no idea what is on SLES, but the current minimal text-only pattern on Leap422 suits my purpose well - minimal text-only server pattern. It's good for a base server install, whether physical or virtual. -- Per Jessen, Zürich (8.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/28/2016 09:25 PM, Ludwig Nussel wrote:

I basically agree. I'd probably be a bit more radical in ripping out those patterns too. I rarely have the desire to install e.g. emacs for technical writing for example ;-)

However, patterns serve another not so visible purpose: they predetermine what ends up on the DVD. Ie the DVD pulls in the rest_dvd pattern which in turn requires a number of other patterns. So even though e.g. the "Mail and News server" pattern looks like an odd combination to install it makes sure those packages end up on the DVD. So we're somewhat abusing patterns to mark 'important' packages. I'm sure we can find some other way to do that though.

cu Ludwig

Thanks for the important info, i'll make sure that any packages that are removed from all other patterns are added to the correct rest patterns for now and if we come up with a better way to handle them it will be easy to remove the old patterns. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Thu, 2016-11-24 at 21:40 +1030, Simon Lees wrote:

One thing that has been discussed several times (and I still think

...

would be a good idea) - but will take quite some leg work, is splitting the 'big chunky' patterns-* .spec file into smaller packages.

This would especially be interesting for the 'Desktop Teams' where we can have them maintain their own set of patterns...

Cheers, Dominique

I guess most of the work here would probably be teaching yast or the installer to search for multiple files, the actual split should be ok,

I don't think yast needs to care: as it looks for packages (binary, not source).. the resulting packages would/could be the same after all. Cheers, Dominique

On 11/24/2016 09:52 PM, Stephan Kulow wrote:

On 24.11.2016 12:10, Simon Lees wrote:

...

I guess most of the work here would probably be teaching yast or the installer to search for multiple files, the actual split should be ok, i'll chat to the yast team next week. Some of the development patterns may also be worth splitting for similar reasons as well. Supporting multiple files might also allow us to share some particular patterns between openSUSE and SLE.

Huh? what files are you talking about? patterns aren't files.

Greetings, Stephan

Ahh my miss understanding, I guess if we had multiple pattern packages in the repo they would all get picked up fine? I slightly forgot how they worked other then in the past I edited one big file that resembled a .spec file. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Thu, 2016-11-24 at 11:40 +0100, Johannes Meixner wrote:

Therefore in the end a "Printing" pattern should contain those binary packages:

cups cups-client cups-libs cups-filters cups-filters-cups-browsed cups-filters-foomatic-rip cups-filters-ghostscript OpenPrintingPPDs-ghostscript OpenPrintingPPDs-hpijs OpenPrintingPPDs-postscript epson-inkjet-printer-escpr ghostscript ghostscript-fonts-other ghostscript-fonts-std gutenprint hplip-hpijs manufacturer-PPDs splix

Using rbrown's words, the "Printing" pattern combines the "functional" and "collection" pattern types. Would it perhaps make sense to have "Printing:Basic" plus "Printing:HP", "Printing:Epson", ... ?? Not to mention those 15000+ PPD files I have installed on my system ... Martin -- Dr. Martin Wilck , Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 2016-11-28 at 11:26 +0100, Johannes Meixner wrote:

...

Not to mention those 15000+ PPD files I have installed on my system ...

I would appreciate it if such comments would be made with some credit for basic intelligence that there is probably a valid reason behind why the current default is as it is.

I didn't mean to question that intelligence. I'm aware that my remark was touching a tough problem, perhaps too superficially, sorry for that.

openSUSE contributors can do what they need and maintain it as they need it - e.g. an openSUSE default system without printer drivers and PPDs RPMs installed.

OK, point taken. Best regards, Martin -- Dr. Martin Wilck , Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On Nov 28 22:54 Simon Lees wrote (excerpt):

Yes that is one of the main goals to start SLE 13 and openSUSE Leap 43.0 development with as close to a unified set of patterns as possible as this will make everyone's life easier. I guess given the feedback we have had about the printing pattern in openSUSE, if it is currently servicing multiple roles maybe we should consider taking this feedback in when creating the printing patterns for SLE 13, this is certainly the best time we will have to do so. It is my intention at this stage to make the openSUSE patterns match what the SLE patterns are doing but really for almost all cases I will be guided by the maintainers of the respective subsystems as they know there packages and hopefully there users better then I do. The main thing splitting some of the patterns out into separate packages and devel repositories should do is make it easier for the maintainers in those areas to update the patterns.

I think we (at least I) need a common understanding what it should actually mean in parctice when a user installs a pattern. I think different maintainers of different subsystems have different assumptions what users expect when installing a pattern. For example my personal assumption when installing a pattern that is broadly just called "Printing" would be that I get basically "all and everything that is needed for normal printing" installed. Or in other words: When I have a "Printing" pattern installed, I would not expect to get ever bothered again with installing "Printing" related software (except for very exotic use-cases). In contrast when there are specifically named patterns like "Printing:HP", "Printing:Epson",... and "Printing:Bluetooth", "Printing:AirPrint",... I would expect to get only installed what is specific for each one. But now things get complicated because e.g. "Printing:Epson" woud require to split each printer driver package that supports at least one 'Epson' printer model into sub-packages so that only the 'Epson' stuff could be installed. E.g. have fun with splitting the PPD files in /usr/share/cups/model/gutenprint/5.2/C/ Current 'gutenprint' supports 44 real printer manufacturers plus "Generic" - what the heck to do with the latter? And technically it does not make much sense for usual printer driver packages because usually a printer driver package provides one big driver binary (plus perhaps a library) for all its supported models so that sub-packages would only artificially cut away PPD files for other manufactures from one particular driver which would make basically only those users happy who count PPD files ;-)

Sorry if any of that doesn't make sense I probably should be sleeping.

At least for me everything you wrote makes perfect sense so you can relax and sleep well ;-) Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Martin Wilck schrieb:

On Thu, 2016-11-24 at 11:40 +0100, Johannes Meixner wrote:

...

Therefore in the end a "Printing" pattern should contain those binary packages:

cups cups-client cups-libs cups-filters cups-filters-cups-browsed cups-filters-foomatic-rip cups-filters-ghostscript OpenPrintingPPDs-ghostscript OpenPrintingPPDs-hpijs OpenPrintingPPDs-postscript epson-inkjet-printer-escpr ghostscript ghostscript-fonts-other ghostscript-fonts-std gutenprint hplip-hpijs manufacturer-PPDs splix

Using rbrown's words, the "Printing" pattern combines the "functional" and "collection" pattern types. Would it perhaps make sense to have "Printing:Basic" plus "Printing:HP", "Printing:Epson", ... ??

Not to mention those 15000+ PPD files I have installed on my system ...

Printer driver packages that pull in python-cups during build will be tagged with Provides that allow for installing the drivers only on demand when the hardware is actually plugged in. I'm not sure whether all driver packages do that and whether it actually works for all of them. I also don't know if all desktop environments and the YaST printer module handle on demand installation of drivers well. Not to forget the cups web interface itself. So likely nobody dared to remove cups and the drivers from a default install yet. Network printing nowadays doesn't require a running cups daemon anymore (at least in GNOME). So IMO installing and launching cups only when there's actually a printer connected would make sense. To implement that we'd need someone to take the lead with testing and pointing developers at what's missing. I was about to suggest to get some cheap printers from ebay for testing with different desktop environments. But then we have openQA :-) So if there was a way to make qemu pretend that there's some USB printer with certain properties connected we could just let openQA test the different scenarios and make sure we don't regress anymore. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org