[opensuse-packaging] New top-level project: utilities

newer
[opensuse-packaging] Simplifying...

older
[opensuse-packaging] Applying a...

Pascal Bleser

9 Nov 2010 9 Nov '10

17:59

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marcus was so kind to create a new top-level project: utilities I requested (*) such a project because there wasn't any appropriate place to maintain packages of command-line utilities, such as cpipe, mlocate, lockrun, likwid, pfm, pv, ttyrec, ack, calcurse, cdu, clpbar, cpuid, di, dtach, gcp, jobqueue, ts, mguesser, ncdu, nkmkpassword, pipemeter, progress, rand, rlwrap, tmux, xjobs, waitfor, ..... (just throwing a few I have in the queue for that project). Anyhow, the idea is to maintain (supposedly "small") command-line utilities in there that don't really fit any other category (server, monitoring, web, irc, ...) If anyone else wants to be maintainer, please poke me. (*) https://bugzilla.novell.com/show_bug.cgi?id=635617 cheers - -- -o) Pascal Bleser /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iD8DBQFM2YwFr3NMWliFcXcRAqo+AJ4uTViJhzYiC5LsNH+5UI3vzCqx3QCgl+qV skKvbr/nvIpLkmYsG2YIYLI= =N8mA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Show replies by date

Adrian Schröter

10 Nov 10 Nov

08:14

Am Dienstag, 9. November 2010, 18:59:33 schrieb Pascal Bleser:

...

Marcus was so kind to create a new top-level project: utilities

I requested (*) such a project because there wasn't any appropriate place to maintain packages of command-line utilities, such as cpipe, mlocate, lockrun, likwid, pfm, pv, ttyrec, ack, calcurse, cdu, clpbar, cpuid, di, dtach, gcp, jobqueue, ts, mguesser, ncdu, nkmkpassword, pipemeter, progress, rand, rlwrap, tmux, xjobs, waitfor, ..... (just throwing a few I have in the queue for that project).

Anyhow, the idea is to maintain (supposedly "small") command-line utilities in there that don't really fit any other category (server, monitoring, web, irc, ...)

If anyone else wants to be maintainer, please poke me.

(*) https://bugzilla.novell.com/show_bug.cgi?id=635617

great, you got already a submission from me ;) It may be a good idea to disable "useforbuild" in that to ensure that no package depends on another one in that project ? -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Michael Schroeder

08:34

On Wed, Nov 10, 2010 at 09:14:59AM +0100, Adrian Schröter wrote:

...

Am Dienstag, 9. November 2010, 18:59:33 schrieb Pascal Bleser:

...
Marcus was so kind to create a new top-level project: utilities

I requested (*) such a project because there wasn't any appropriate place to maintain packages of command-line utilities, such as cpipe, mlocate, lockrun, likwid, pfm, pv, ttyrec, ack, calcurse, cdu, clpbar, cpuid, di, dtach, gcp, jobqueue, ts, mguesser, ncdu, nkmkpassword, pipemeter, progress, rand, rlwrap, tmux, xjobs, waitfor, ..... (just throwing a few I have in the queue for that project).

Anyhow, the idea is to maintain (supposedly "small") command-line utilities in there that don't really fit any other category (server, monitoring, web, irc, ...)

If anyone else wants to be maintainer, please poke me.

(*) https://bugzilla.novell.com/show_bug.cgi?id=635617

great, you got already a submission from me ;)

It may be a good idea to disable "useforbuild" in that to ensure that no package depends on another one in that project ?

Why would that be useful? Either they depend on each other, then you need to have useforbuild enabled to have consistency. Or they don't depend on each other, then it makes no difference. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Ludwig Nussel

09:15

Michael Schroeder wrote:

...

On Wed, Nov 10, 2010 at 09:14:59AM +0100, Adrian Schröter wrote:

...
Am Dienstag, 9. November 2010, 18:59:33 schrieb Pascal Bleser:

...
Marcus was so kind to create a new top-level project: utilities

I requested (*) such a project because there wasn't any appropriate place to maintain packages of command-line utilities, such as cpipe, mlocate, lockrun, likwid, pfm, pv, ttyrec, ack, calcurse, cdu, clpbar, cpuid, di, dtach, gcp, jobqueue, ts, mguesser, ncdu, nkmkpassword, pipemeter, progress, rand, rlwrap, tmux, xjobs, waitfor, ..... (just throwing a few I have in the queue for that project).

Anyhow, the idea is to maintain (supposedly "small") command-line utilities in there that don't really fit any other category (server, monitoring, web, irc, ...)

If anyone else wants to be maintainer, please poke me.

(*) https://bugzilla.novell.com/show_bug.cgi?id=635617

great, you got already a submission from me ;)

It may be a good idea to disable "useforbuild" in that to ensure that no package depends on another one in that project ?

Why would that be useful? Either they depend on each other, then you need to have useforbuild enabled to have consistency. Or they don't depend on each other, then it makes no difference.

IIUC such a setting makes sure they stay independent. A change in one package can't accidentally influence others working in the same project then. However, I wonder why such such packages need a devel project at all. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Adrian Schröter

09:35

Am Mittwoch, 10. November 2010, 09:34:27 schrieb Michael Schroeder:

...

On Wed, Nov 10, 2010 at 09:14:59AM +0100, Adrian Schröter wrote:

...
Am Dienstag, 9. November 2010, 18:59:33 schrieb Pascal Bleser:

...
Marcus was so kind to create a new top-level project: utilities

I requested (*) such a project because there wasn't any appropriate place to maintain packages of command-line utilities, such as cpipe, mlocate, lockrun, likwid, pfm, pv, ttyrec, ack, calcurse, cdu, clpbar, cpuid, di, dtach, gcp, jobqueue, ts, mguesser, ncdu, nkmkpassword, pipemeter, progress, rand, rlwrap, tmux, xjobs, waitfor, ..... (just throwing a few I have in the queue for that project).

Anyhow, the idea is to maintain (supposedly "small") command-line utilities in there that don't really fit any other category (server, monitoring, web, irc, ...)

If anyone else wants to be maintainer, please poke me.

(*) https://bugzilla.novell.com/show_bug.cgi?id=635617

great, you got already a submission from me ;)

It may be a good idea to disable "useforbuild" in that to ensure that no package depends on another one in that project ?

Why would that be useful? Either they depend on each other, then you need to have useforbuild enabled to have consistency. Or they don't depend on each other, then it makes no difference.

You would know that you could move any of these packages around without further dependencies. It was just an idea, not really important ... -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Michal Marek

13:03

On 9.11.2010 18:59, Pascal Bleser wrote:

...

Marcus was so kind to create a new top-level project: utilities

I requested (*) such a project because there wasn't any appropriate place to maintain packages of command-line utilities, such as cpipe, mlocate, lockrun, likwid, pfm, pv, ttyrec, ack, calcurse, cdu, clpbar, cpuid, di, dtach, gcp, jobqueue, ts, mguesser, ncdu, nkmkpassword, pipemeter, progress, rand, rlwrap, tmux, xjobs, waitfor, ..... (just throwing a few I have in the queue for that project).

Wow, so we can finally clean up Base:System to only host the basic packages. Candidates for 'utilities' would be: acct buffer cdrdao cdrtools collectl convert delayacct-utils delta dialog dicts dmidecode dos2unix dvd+rw-tools eject espeak fam figlet file firmwarekit FirmwareUpdateKit fortune fs-check fxload gcal gpart hex igerman98 iotop iwatch john-wordlists kerneloops killerd ksymoops lsof mbuffer mc mcal minicom mmv pin pinfo powertop pwgen recode rzsz screen sitar smake spu-tools stan supportutils sysstat tree vlock wipe wodim words Note that I did not check if these are really leaf packages, but it should be a good starting point. Michal -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Petr Uzel

13:11

Hi, On Tue, Nov 09, 2010 at 06:59:33PM +0100, Pascal Bleser wrote:

...

Marcus was so kind to create a new top-level project: utilities

I requested (*) such a project because there wasn't any appropriate place to maintain packages of command-line utilities, such as cpipe, mlocate, lockrun, likwid, pfm, pv, ttyrec, ack, calcurse, cdu, clpbar, cpuid, di, dtach, gcp, jobqueue, ts, mguesser, ncdu, nkmkpassword, pipemeter, progress, rand, rlwrap, tmux, xjobs, waitfor, ..... (just throwing a few I have in the queue for that project).

I would like to move following packages from Base:System there (then changedevelrequest) - less - pinfo - lsof Next, these package from Contrib - ack [*] - calcurse [**] - devtodo - remind - urlview - vifm - wyrd Afterwards, I would submit these to Factory and delete from Contrib. Objections? [*] ack is also in your list. I checked the differences between Contrib/ack and your version - the Contrib (originally based on your package) is newer (git snapshot) and has a patch to ignore .osc files. If it goes to Factory, I think it should be stable version (1.92), so I suggest you to submit your package and will add stuff from Contrib/ack later. Oh, and ack depends on perl-File-Next, which is not in Factory. I will update the package in devel:languages:perl and submit to Factory. [**] Your calcurse package looks better, so let's just submit your version to Factory (FWIW I could be (co)maintainer if needed) and delete the one from Contrib. Does it make sense? -- Petr Uzel IRC: ptr_uzl @ freenode

Stephan Kulow

13:16

Am Mittwoch 10 November 2010 schrieb Petr Uzel:

...

Does it make sense?

Petr, I don't think you need to ask that question. But in case you really wanted an answer: go ahead! I hope we will see more useful utilities in factory and close contrib - the sooner the happier I am. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Petr Uzel

13:24

On Wed, Nov 10, 2010 at 02:16:56PM +0100, Stephan Kulow wrote:

...

Am Mittwoch 10 November 2010 schrieb Petr Uzel:

...
Does it make sense?

Petr, I don't think you need to ask that question.

OK, I kind of expected such answer, but could not resist to ask anyway - that's just me :)

...

But in case you really wanted an answer: go ahead! I hope we will see more useful utilities in factory and close contrib - the sooner the happier I am.

Will do. Thanks Coolo! Petr -- Petr Uzel IRC: ptr_uzl @ freenode

Peter Linnell

13:57

On 11/10/10 2:24 PM, Petr Uzel wrote:

...

On Wed, Nov 10, 2010 at 02:16:56PM +0100, Stephan Kulow wrote:

...
Am Mittwoch 10 November 2010 schrieb Petr Uzel:

...
Does it make sense?

Petr, I don't think you need to ask that question.

OK, I kind of expected such answer, but could not resist to ask anyway - that's just me :)

...
But in case you really wanted an answer: go ahead! I hope we will see more useful utilities in factory and close contrib - the sooner the happier I am.

Will do. Thanks Coolo!

Petr

-- Petr Uzel IRC: ptr_uzl @ freenode

Hi, OK, with Contrib, what I would recommend is a workflow: branch somewhere run spec-cleaner on the spec file fix any rpmlint errors where possible SR > Utilties lather, rinse, repeat. Thanks, Peter -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Stephan Kulow

14:05

Am Mittwoch 10 November 2010 schrieb Peter Linnell:

...

OK, with Contrib, what I would recommend is a workflow:

branch somewhere run spec-cleaner on the spec file fix any rpmlint errors where possible SR > Utilties

lather, rinse, repeat.

Note that utilities is not a new name for contrib - so this only applies to command line utilities! We still need to find devel projects for other contrib packages. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

P Linnell

23:50

On Wednesday 10 November 2010 15:05:24 Stephan Kulow wrote:

...

Am Mittwoch 10 November 2010 schrieb Peter Linnell:

...
OK, with Contrib, what I would recommend is a workflow:

branch somewhere run spec-cleaner on the spec file fix any rpmlint errors where possible SR > Utilties

lather, rinse, repeat.

Note that utilities is not a new name for contrib - so this only applies to command line utilities! We still need to find devel projects for other contrib packages.

Greetings, Stephan

Oh yeah.. no arguing there. My point is in doing these kinds of moves from repo > repo, we have a chance to use spec-cleaner to get some consistency in the layout of the spec files. While spec-cleaner is work in progress TM, it does make it more readable for reviewers and this helps to catch possible errors. Plus, except for some known issues most rpmlint complaints are legit and should be fixed or filtered with a good reason. Cheers, Peter -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Pascal Bleser

20:14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/10/2010 02:11 PM, Petr Uzel wrote:

...

On Tue, Nov 09, 2010 at 06:59:33PM +0100, Pascal Bleser wrote:

...
Marcus was so kind to create a new top-level project: utilities

I requested (*) such a project because there wasn't any appropriate place to maintain packages of command-line utilities, such as cpipe, mlocate, lockrun, likwid, pfm, pv, ttyrec, ack, calcurse, cdu, clpbar, cpuid, di, dtach, gcp, jobqueue, ts, mguesser, ncdu, nkmkpassword, pipemeter, progress, rand, rlwrap, tmux, xjobs, waitfor, ..... (just throwing a few I have in the queue for that project).

I would like to move following packages from Base:System there (then changedevelrequest) - less - pinfo - lsof

Really? Why not keep them in Base:System? (at least less and lsof) Hm.. we might have a need to clarify the difference between Base:System and utilities then, because I'm still a bit confused -- but maybe that's just me :)))

...

Next, these package from Contrib - ack [*] - calcurse [**] - devtodo - remind - urlview - vifm - wyrd

Keep'em coming :) Anyhow, if anyone wants to help maintaining utilities, please poke. I don't want to be the bottleneck here :)

...

Afterwards, I would submit these to Factory and delete from Contrib.

Objections?

[*] ack is also in your list. I checked the differences between Contrib/ack and your version - the Contrib (originally based on your package) is newer (git snapshot) and has a patch to ignore .osc files. If it goes to Factory, I think it should be stable version (1.92), so I suggest you to submit your package and will add stuff from Contrib/ack later.

Ok, I already moved ack from my home to utilities, and I'll merge the patch from Contrib myself later tonight.

...

Oh, and ack depends on perl-File-Next, which is not in Factory. I will update the package in devel:languages:perl and submit to Factory.

I made a _link from devel:languages:perl to utilities as well.

...

[**] Your calcurse package looks better, so let's just submit your version to Factory (FWIW I could be (co)maintainer if needed) and delete the one from Contrib.

Ok, I moved it from my home to utilities, and added you as a maintainer.

...

Does it make sense?

Totally :) cheers - -- -o) Pascal Bleser /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iD8DBQFM2v0zr3NMWliFcXcRAl2IAJ92B5zeu8uMWZbQIh2WzXANwotC/wCfUXHb kNLExqkd1Q1sDPtOCWGn9vc= =NWC5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Petr Uzel

11 Nov 11 Nov

11:05

On Wed, Nov 10, 2010 at 09:14:43PM +0100, Pascal Bleser wrote:

...

On 11/10/2010 02:11 PM, Petr Uzel wrote:

...
I would like to move following packages from Base:System there (then changedevelrequest) - less - pinfo - lsof

Really? Why not keep them in Base:System? (at least less and lsof)

Because I think they are rather "utilities" than "base system" :) If you think Base:System is better place, I'm fine with that - in that case, just decline the requests / delete utilities/less.

...

Hm.. we might have a need to clarify the difference between Base:System and utilities then, because I'm still a bit confused -- but maybe that's just me :)))

I think your definition of utilities is fine: <quote> Supposedly "small" command-line utilities that don't really fit any other category (server, monitoring, web, irc, ...) </quote> This itself does not differentiate it from Base:System - I think it is best to decide on case-by-case basis which project is better.

...

...
[*] ack is also in your list. I checked the differences between Contrib/ack and your version - the Contrib (originally based on your package) is newer (git snapshot) and has a patch to ignore .osc files. If it goes to Factory, I think it should be stable version (1.92), so I suggest you to submit your package and will add stuff from Contrib/ack later.

Ok, I already moved ack from my home to utilities, and I'll merge the patch from Contrib myself later tonight.

Cool, thanks.

...

...
Oh, and ack depends on perl-File-Next, which is not in Factory. I will update the package in devel:languages:perl and submit to Factory.

I made a _link from devel:languages:perl to utilities as well.

It is on its way to Factory already. So we can later delete the link.

...

...
[**] Your calcurse package looks better, so let's just submit your version to Factory (FWIW I could be (co)maintainer if needed) and delete the one from Contrib.

Ok, I moved it from my home to utilities, and added you as a maintainer.

Thx. Regards, Petr -- Petr Uzel IRC: ptr_uzl @ freenode

Pascal Bleser

23:10

On 2010-11-11 12:05:11 (+0100), Petr Uzel wrote:

...

On Wed, Nov 10, 2010 at 09:14:43PM +0100, Pascal Bleser wrote:

...
On 11/10/2010 02:11 PM, Petr Uzel wrote:

...
I would like to move following packages from Base:System there (then changedevelrequest) - less - pinfo - lsof

Really? Why not keep them in Base:System? (at least less and lsof)

Because I think they are rather "utilities" than "base system" :) If you think Base:System is better place, I'm fine with that - in that case, just decline the requests / delete utilities/less.

See below.

...

...
Hm.. we might have a need to clarify the difference between Base:System and utilities then, because I'm still a bit confused -- but maybe that's just me :)))

I think your definition of utilities is fine:

<quote> Supposedly "small" command-line utilities that don't really fit any other category (server, monitoring, web, irc, ...) </quote>

This itself does not differentiate it from Base:System - I think it is best to decide on case-by-case basis which project is better.

But now I'm still lacking a proper definition/differenciator for Base:System. As an example, less is definitely something that should be shipped with every "base system", nevermind how small it is, so what should go into Base:System and what into utilities ? I'm not just asking for me, because I'm sure that question will come up quite often and needs to be clarified soonish. Maybe it is totally clear what the difference is, or what the exact purpose of Base:system is to.. dunno, coolo, Adrian, AJ and darix, and apparently to you too but... not to me :\ If someone could explain, that would help a lot.

...

...
...
[*] ack is also in your list. I checked the differences between Contrib/ack and your version - the Contrib (originally based on your package) is newer (git snapshot) and has a patch to ignore .osc files. If it goes to Factory, I think it should be stable version (1.92), so I suggest you to submit your package and will add stuff from Contrib/ack later.

Ok, I already moved ack from my home to utilities, and I'll merge the patch from Contrib myself later tonight.

Cool, thanks.

Done in r2 of ack, re-did the patch against 1.92 and also merged your .changes entries from o:F:C/ack

...

...
...
Oh, and ack depends on perl-File-Next, which is not in Factory. I will update the package in devel:languages:perl and submit to Factory.

I made a _link from devel:languages:perl to utilities as well.

It is on its way to Factory already. So we can later delete the link.

Hmm.. why Factory? /me confused The primary project for perl-File-Next is devel:languages:perl I added a _link utilities -> devel:languages:perl for that package, to have it there as well as it is a dependency of ack. Now, why do you mention Factory? :) cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org

Petr Uzel

12 Nov 12 Nov

08:46

On Fri, Nov 12, 2010 at 12:10:25AM +0100, Pascal Bleser wrote:

...

On 2010-11-11 12:05:11 (+0100), Petr Uzel wrote:

...
I think your definition of utilities is fine:

<quote> Supposedly "small" command-line utilities that don't really fit any other category (server, monitoring, web, irc, ...) </quote>

This itself does not differentiate it from Base:System - I think it is best to decide on case-by-case basis which project is better.

But now I'm still lacking a proper definition/differenciator for Base:System.

As an example, less is definitely something that should be shipped with every "base system", nevermind how small it is, so what should go into Base:System and what into utilities ?

I'm not just asking for me, because I'm sure that question will come up quite often and needs to be clarified soonish.

Maybe it is totally clear what the difference is, or what the exact purpose of Base:system is to.. dunno, coolo, Adrian, AJ and darix, and apparently to you too but... not to me :\

Frankly, no, I don't have any clear and universal definition of Base:System / utilities packages that would work as proper differentiator for all packages (if anybody has, it would certainly help, but honestly I doubt there could be any clear/universal definition). I think I should at least try to be constructive, so, what about something along these lines (for Base:System): "Set of packages that are necessary to boot and run default minimalistic installation on typical system". Obvious exception is kernel - I believe there is a good reason why it is not in Base:System. Certainly there are more, so case-by-case decisions and common sense still needed. Sorry, I don't have anything better :)

...

...
...
I made a _link from devel:languages:perl to utilities as well.

It is on its way to Factory already. So we can later delete the link.

Hmm.. why Factory? /me confused

Because I would like to have ack (actually all the packages I mentioned before) in Factory. So perl-File-Next has to be there as well. Once it is in factory, the _link in utilities is no longer needed. Sorry if I wasn't clear before.

...

The primary project for perl-File-Next is devel:languages:perl I added a _link utilities -> devel:languages:perl for that package, to have it there as well as it is a dependency of ack. Now, why do you mention Factory? :)

Regards, Petr -- Petr Uzel IRC: ptr_uzl @ freenode

Michael Schroeder

08:58

On Fri, Nov 12, 2010 at 09:46:25AM +0100, Petr Uzel wrote:

...

I think I should at least try to be constructive, so, what about something along these lines (for Base:System): "Set of packages that are necessary to boot and run default minimalistic installation on typical system".

That's not the definition of a "devel project". Devel projects are about people working together on some set of packages. It a social thing, not a technical. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Adrian Schröter

09:08

Am Freitag, 12. November 2010, 09:58:20 schrieb Michael Schroeder:

...

On Fri, Nov 12, 2010 at 09:46:25AM +0100, Petr Uzel wrote:

...
I think I should at least try to be constructive, so, what about something along these lines (for Base:System): "Set of packages that are necessary to boot and run default minimalistic installation on typical system".

That's not the definition of a "devel project". Devel projects are about people working together on some set of packages. It a social thing, not a technical.

It is also a technical thing to some degree. For example that the new kdelibs package should always get tested together with the kdebase package. Or kernel & mkinitrd for example However, you can of course always discuss what makes sense and what not. There is no sharp line. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Ludwig Nussel

15 Nov 15 Nov

10:16

Adrian Schröter wrote:

...

Am Freitag, 12. November 2010, 09:58:20 schrieb Michael Schroeder:

...
On Fri, Nov 12, 2010 at 09:46:25AM +0100, Petr Uzel wrote:

...
I think I should at least try to be constructive, so, what about something along these lines (for Base:System): "Set of packages that are necessary to boot and run default minimalistic installation on typical system".

That's not the definition of a "devel project". Devel projects are about people working together on some set of packages. It a social thing, not a technical.

It is also a technical thing to some degree. For example that the new kdelibs package should always get tested together with the kdebase package. Or kernel & mkinitrd for example

That does not necessarily mean that the devel project for both packages needs to be the same. You can link technically related packages from Factory just fine. Even on a case by case basis, depending on the changes of your own package. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Petr Baudis

16 Nov 16 Nov

01:28

On Fri, Nov 12, 2010 at 09:58:20AM +0100, Michael Schroeder wrote:

...

On Fri, Nov 12, 2010 at 09:46:25AM +0100, Petr Uzel wrote:

...
I think I should at least try to be constructive, so, what about something along these lines (for Base:System): "Set of packages that are necessary to boot and run default minimalistic installation on typical system".

That's not the definition of a "devel project". Devel projects are about people working together on some set of packages. It a social thing, not a technical.

I think this falls apart to four areas: (i) Distribution policies. Mainly aaa-base, I guess. The people who care about the SUSE fundamentals should gather here. (ii) The basic userland related to run-time lifetime of the system. This does not seem to have much of a social aspect, but I do not think we can avoid a catch-all like this; the goal should perhaps be to make it as narrow as possible. E.g. glibc is pretty antisocial, I'd say. ;-) It affects everything, but has very weak actual external ties. This covers glibc, *kit, dbus, grub, ... But does this need to cover *all* userland required to run the system? Perhaps we use it for something I'm not aware of, but what would actually break if *gasp* coreutils got moved to utilities? (Hey, it's named that way too!) (iii) Userspace-kernel interfaces. pciutils, *acpi*, *obex*, most of *fs* and util-linux, ... Perhaps they could live elsewhere? (iv) All the cruft that should IMO be mostly in utilities; bc, pinfo, less, ... Another question is whether it's actually worth to do huge changes in Base:System as for many of the packages, on one level the social aspect ("anyone but person X is interested") is quite low while on the next level, you'd already want to have them in four different projects. IMHO it's qualitatively quite different from the GNOME/KDE, graphics, devel:* and such projects. For me, Base:System is only "the place where I commit glibc so that I can submitreq it to Factory if I don't see a followup build failures storm". I'm not sure how it (or other devel project) could do more for e.g. me in particular. -- Petr "Pasky" Baudis The true meaning of life is to plant a tree under whose shade you will never sit. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Greg KH

03:40

On Tue, Nov 16, 2010 at 02:28:17AM +0100, Petr Baudis wrote:

...

On Fri, Nov 12, 2010 at 09:58:20AM +0100, Michael Schroeder wrote:

...
On Fri, Nov 12, 2010 at 09:46:25AM +0100, Petr Uzel wrote:

...
I think I should at least try to be constructive, so, what about something along these lines (for Base:System): "Set of packages that are necessary to boot and run default minimalistic installation on typical system".

That's not the definition of a "devel project". Devel projects are about people working together on some set of packages. It a social thing, not a technical.

I think this falls apart to four areas:

(i) Distribution policies. Mainly aaa-base, I guess. The people who care about the SUSE fundamentals should gather here.

aaa-base is getting smaller and smaller, and hopefully should be gone entirely soon. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Pascal Bleser

13 Nov 13 Nov

17:50

On 2010-11-11 12:05:11 (+0100), Petr Uzel wrote:

...

On Wed, Nov 10, 2010 at 09:14:43PM +0100, Pascal Bleser wrote:

...
On 11/10/2010 02:11 PM, Petr Uzel wrote:

...
I would like to move following packages from Base:System there (then changedevelrequest) - less - pinfo - lsof

Really? Why not keep them in Base:System? (at least less and lsof)

Because I think they are rather "utilities" than "base system" :) If you think Base:System is better place, I'm fine with that - in that case, just decline the requests / delete utilities/less.

Again, it's just a matter of comprehension.. so.. what's Base:System for? If it is 1) smallest possible set of packages to boot openSUSE or 2) minimalistic but usable system With 1, I'd agree that less is not needed, but for 2, I'd rather have less, vim (minimalistic), lsof, ... in there. cheers, -- -o) Pascal Bleser /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org

Stephan Kulow

15 Nov 15 Nov

10:13

Am Samstag 13 November 2010 schrieb Pascal Bleser:

...

On 2010-11-11 12:05:11 (+0100), Petr Uzel wrote:

...
On Wed, Nov 10, 2010 at 09:14:43PM +0100, Pascal Bleser wrote:

...
On 11/10/2010 02:11 PM, Petr Uzel wrote:

...
I would like to move following packages from Base:System there (then changedevelrequest) - less - pinfo - lsof

Really? Why not keep them in Base:System? (at least less and lsof)

Because I think they are rather "utilities" than "base system" :) If you think Base:System is better place, I'm fine with that - in that case, just decline the requests / delete utilities/less.

Again, it's just a matter of comprehension.. so.. what's Base:System for?

If it is 1) smallest possible set of packages to boot openSUSE or 2) minimalistic but usable system

It's neither of those. I would like to summarize it as: packages that break booting older distributions if updated ;) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Ludwig Nussel

10:25

Stephan Kulow wrote:

...

Am Samstag 13 November 2010 schrieb Pascal Bleser:

...
On 2010-11-11 12:05:11 (+0100), Petr Uzel wrote:

...
On Wed, Nov 10, 2010 at 09:14:43PM +0100, Pascal Bleser wrote:

...
On 11/10/2010 02:11 PM, Petr Uzel wrote:

...
I would like to move following packages from Base:System there (then changedevelrequest) - less - pinfo - lsof

Really? Why not keep them in Base:System? (at least less and lsof)

Because I think they are rather "utilities" than "base system" :) If you think Base:System is better place, I'm fine with that - in that case, just decline the requests / delete utilities/less.

Again, it's just a matter of comprehension.. so.. what's Base:System for?

If it is 1) smallest possible set of packages to boot openSUSE or 2) minimalistic but usable system

It's neither of those. I would like to summarize it as: packages that break booting older distributions if updated ;)

... and everyone else's package in the same project. Base:System is an artificial construct and fails it's purpose as devel project. You can't really develop in there as the risk of interrupting unrelated work of other people in the same project is high if you touch packages needed in the build environment itself. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Jean Delvare

12:45

On Wednesday 10 November 2010 02:11:51 pm Petr Uzel wrote:

...

Hi,

On Tue, Nov 09, 2010 at 06:59:33PM +0100, Pascal Bleser wrote:

...
Marcus was so kind to create a new top-level project: utilities

I requested (*) such a project because there wasn't any appropriate place to maintain packages of command-line utilities, such as cpipe, mlocate, lockrun, likwid, pfm, pv, ttyrec, ack, calcurse, cdu, clpbar, cpuid, di, dtach, gcp, jobqueue, ts, mguesser, ncdu, nkmkpassword, pipemeter, progress, rand, rlwrap, tmux, xjobs, waitfor, ..... (just throwing a few I have in the queue for that project).

I would like to move following packages from Base:System there (then changedevelrequest) - less - pinfo - lsof

I pretty much doubt you want to move less out of Base:System, given that man depends on it. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Stephan Kulow

12:53

Am Montag 15 November 2010 schrieb Jean Delvare:

...

I pretty much doubt you want to move less out of Base:System, given that man depends on it.

What definition of Base:System is that statement based on? man depends on _tons_ of things not in Base:System. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Petr Uzel

13:41

On Mon, Nov 15, 2010 at 01:53:40PM +0100, Stephan Kulow wrote:

...

Am Montag 15 November 2010 schrieb Jean Delvare:

...
I pretty much doubt you want to move less out of Base:System, given that man depends on it.

What definition of Base:System is that statement based on? man depends on _tons_ of things not in Base:System.

I just created request to delete less from utilities - let it stay in Base:System only. Regards, Petr -- Petr Uzel IRC: ptr_uzl @ freenode

Pascal Bleser

16 Nov 16 Nov

09:10

On 2010-11-15 14:41:50 (+0100), Petr Uzel wrote:

...

On Mon, Nov 15, 2010 at 01:53:40PM +0100, Stephan Kulow wrote:

...
Am Montag 15 November 2010 schrieb Jean Delvare:

...
I pretty much doubt you want to move less out of Base:System, given that man depends on it.

What definition of Base:System is that statement based on? man depends on _tons_ of things not in Base:System.

I just created request to delete less from utilities - let it stay in Base:System only.

Couldn't we use utilities/less as a devel for Base:System/less ? (or is Base:System already the devel project for Factory ?) That being said, I would personally feel a bit uncomfortable doing SRs for Base:System, as it sounds like it is a very critical project which needs very conservative handling (of new versions and such). Or is that just an impression? :) My point is that we might be able to maintain a "latest and greatest" less in utilities, rather than in Base:System. Well... if "latest and greatest" applies to less in the first place.. erm... probably not. But coolo wants Base:System to become smaller, so why move less back into Base:System now ? Let's please clarify that with coolo first :) cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org

Marcus Meissner

09:21

On Tue, Nov 16, 2010 at 10:10:03AM +0100, Pascal Bleser wrote:

...

On 2010-11-15 14:41:50 (+0100), Petr Uzel wrote:

...
On Mon, Nov 15, 2010 at 01:53:40PM +0100, Stephan Kulow wrote:

...
Am Montag 15 November 2010 schrieb Jean Delvare:

...
I pretty much doubt you want to move less out of Base:System, given that man depends on it.

What definition of Base:System is that statement based on? man depends on _tons_ of things not in Base:System.

I just created request to delete less from utilities - let it stay in Base:System only.

Couldn't we use utilities/less as a devel for Base:System/less ? (or is Base:System already the devel project for Factory ?)

That being said, I would personally feel a bit uncomfortable doing SRs for Base:System, as it sounds like it is a very critical project which needs very conservative handling (of new versions and such). Or is that just an impression? :)

My point is that we might be able to maintain a "latest and greatest" less in utilities, rather than in Base:System. Well... if "latest and greatest" applies to less in the first place.. erm... probably not.

But coolo wants Base:System to become smaller, so why move less back into Base:System now ?

Let's please clarify that with coolo first :)

As "man" does not require specific version of less to build, I see no issues of "less" living somewhere else. Base:System is also not a backports repository. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Pascal Bleser

10:13

On 2010-11-16 10:21:09 (+0100), Marcus Meissner wrote:

...

On Tue, Nov 16, 2010 at 10:10:03AM +0100, Pascal Bleser wrote: [...]

...
But coolo wants Base:System to become smaller, so why move less back into Base:System now ? Let's please clarify that with coolo first :)

As "man" does not require specific version of less to build, I see no issues of "less" living somewhere else.

Okay, but, to me, it did sound like we wouldn't even need to have "man" in Base:System in the first place. At least that's how I understood coolo. So what about: - moving less to utilities - moving man to ... documentation? (or utilities ?)

...

Base:System is also not a backports repository.

Mmm... okay... did sound like it has to be managed in a very conservative manner nevertheless. cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org

Stephan Kulow

09:23

Am Dienstag 16 November 2010 schrieb Pascal Bleser:

...

On 2010-11-15 14:41:50 (+0100), Petr Uzel wrote:

...
On Mon, Nov 15, 2010 at 01:53:40PM +0100, Stephan Kulow wrote:

...
Am Montag 15 November 2010 schrieb Jean Delvare:

...
I pretty much doubt you want to move less out of Base:System, given that man depends on it.

What definition of Base:System is that statement based on? man depends on _tons_ of things not in Base:System.

I just created request to delete less from utilities - let it stay in Base:System only.

Couldn't we use utilities/less as a devel for Base:System/less ? (or is Base:System already the devel project for Factory ?)

That being said, I would personally feel a bit uncomfortable doing SRs for Base:System, as it sounds like it is a very critical project which needs very conservative handling (of new versions and such). Or is that just an impression? :)

My point is that we might be able to maintain a "latest and greatest" less in utilities, rather than in Base:System. Well... if "latest and greatest" applies to less in the first place.. erm... probably not.

But coolo wants Base:System to become smaller, so why move less back into Base:System now ?

Let's please clarify that with coolo first :) Hey! I'm just one of the 300 maintainers of it - but I see a huge tendency of "if I don't get what devel projects are for, I pick Base:System", so Base:System shouldn't become smaller per se, but should have a clear definition that people can stick to. And all definitions I can come up with happen to mean a smaller Base:System, yes.

And I think pasky's definition is roughly the one it should be. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Michal Vyskocil

19 Nov 19 Nov

08:35

On Tuesday 16 of November 2010 10:23:48 Stephan Kulow wrote:

...

Am Dienstag 16 November 2010 schrieb Pascal Bleser:

...
On 2010-11-15 14:41:50 (+0100), Petr Uzel wrote:

...
On Mon, Nov 15, 2010 at 01:53:40PM +0100, Stephan Kulow wrote:

...
Am Montag 15 November 2010 schrieb Jean Delvare:

...
I pretty much doubt you want to move less out of Base:System, given that man depends on it.

What definition of Base:System is that statement based on? man depends on _tons_ of things not in Base:System.

I just created request to delete less from utilities - let it stay in Base:System only.

Couldn't we use utilities/less as a devel for Base:System/less ? (or is Base:System already the devel project for Factory ?)

That being said, I would personally feel a bit uncomfortable doing SRs for Base:System, as it sounds like it is a very critical project which needs very conservative handling (of new versions and such). Or is that just an impression? :)

My point is that we might be able to maintain a "latest and greatest" less in utilities, rather than in Base:System. Well... if "latest and greatest" applies to less in the first place.. erm... probably not.

But coolo wants Base:System to become smaller, so why move less back into Base:System now ?

Let's please clarify that with coolo first :)

Hey! I'm just one of the 300 maintainers of it - but I see a huge tendency of "if I don't get what devel projects are for, I pick Base:System", so Base:System shouldn't become smaller per se, but should have a clear definition that people can stick to. And all definitions I can come up with happen to mean a smaller Base:System, yes.

And I think pasky's definition is roughly the one it should be.

You mean the Base:System is only "the place where I commit glibc so that I can submitreq it to Factory if I don't see a followup build failures storm" right? ;-) Anyway I like that, so I'm sure the description of Base:System has to be updated. I propose a following description of that project Base:System is intended for (i) Distribution policies. Mainly aaa-base, I guess. The people who care about the SUSE fundamentals should gather here. (ii) The basic userland related to run-time lifetime of the system. This covers glibc, *kit, dbus, grub, (iii) Userspace-kernel interfaces. pciutils, *acpi*, *obex*, most of fs and util-linux. (iv) All other userspace tools should lives elsewhere, most likely in utilities BTW: this reminds me - there was an announcement glib will be moved to /lib - does it makes a sense to move glib to Base:System yet? Regards Michal Vyskocil

Petr Uzel

16 Nov 16 Nov

14:54

On Tue, Nov 16, 2010 at 10:10:03AM +0100, Pascal Bleser wrote:

...

On 2010-11-15 14:41:50 (+0100), Petr Uzel wrote:

...
I just created request to delete less from utilities - let it stay in Base:System only.

Couldn't we use utilities/less as a devel for Base:System/less ? (or is Base:System already the devel project for Factory ?)

Yes, it is.

...

My point is that we might be able to maintain a "latest and greatest" less in utilities, rather than in Base:System. Well... if "latest and greatest" applies to less in the first place.. erm... probably not.

But coolo wants Base:System to become smaller, so why move less back into Base:System now ?

Because although my personal opinion was that utilities is a better home(devel project) than Base:System, I don't care that much about in which project will it live. And I got the impression that the dominant opinion is 'keep it in Base:System', for whatever reason. OK, got it: I should read http://blog.hennevogel.de/kick-ass/ again ;) Petr -- Petr Uzel IRC: ptr_uzl @ freenode

Jean Delvare

15 Nov 15 Nov

13:57

On Monday 15 November 2010 01:53:40 pm Stephan Kulow wrote:

...

Am Montag 15 November 2010 schrieb Jean Delvare:

...
I pretty much doubt you want to move less out of Base:System, given that man depends on it.

What definition of Base:System is that statement based on? man depends on _tons_ of things not in Base:System.

That wouldn't be a definition, but a property of Base:System: that its packages should have no external dependencies (except to the kernel.) But feel free to ignore me. I am notoriously unskilled when it comes to packaging and the build service. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Stephan Kulow

14:18

Am Montag 15 November 2010 schrieb Jean Delvare:

...

On Monday 15 November 2010 01:53:40 pm Stephan Kulow wrote:

...
Am Montag 15 November 2010 schrieb Jean Delvare:

...
I pretty much doubt you want to move less out of Base:System, given that man depends on it.

What definition of Base:System is that statement based on? man

depends on _tons_ of things not in Base:System.

That wouldn't be a definition, but a property of Base:System: that its packages should have no external dependencies (except to the kernel.)

man does not require lot, but of those groff lives in M17N, gdbm lives in devel:libraries:c_c++ - having a "minimal factory" project might fun to setup, but it wouldn't be a good devel project. I would move man to Publishing or Documentation. Base:System really has way too much stuff. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

4913

Age (days ago)

4923

Last active (days ago)

List overview

Download

34 comments

14 participants

participants (14)

Adrian Schröter
Greg KH
Jean Delvare
Ludwig Nussel
Marcus Meissner
Michael Schroeder
Michal Marek
Michal Vyskocil
P Linnell
Pascal Bleser
Peter Linnell
Petr Baudis
Petr Uzel
Stephan Kulow