Hi,
Are Requires(post{,un}) needed for things in coreutils?
Thanks,
Andrew
On Fri, Feb 09, 2007 at 01:34:16PM -0600, Rex Dieter wrote:
Andrew Overholt wrote:
Are Requires(post{,un}) needed for things in coreutils?
I'd lean toward yes.
That would mean that any use of say "rm" or "test" in the scriplets would need a coreutils dependency. Since almost all upgrade/remove scriplets test $1, we'd have to add coreutils everywhere.
Maybe we need a minimal assumed runtime environment just like we define a minimal assumed build evironment? The definition of such a beast would be the minimal set of packages that are needed to do anything sensible, for example everything that is pulled in by redhat-lsb (which includes coreutils).
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
That would mean that any use of say "rm" or "test" in the scriplets would need a coreutils dependency. Since almost all upgrade/remove scriplets test $1, we'd have to add coreutils everywhere.
'test' is a bash builtin
Maybe we need a minimal assumed runtime environment just like we define a minimal assumed build evironment?
What's wrong with the current situation that we need such a change?
The definition of such a beast would be the minimal set of packages that are needed to do anything sensible, for example everything that is pulled in by redhat-lsb (which includes coreutils).
Hahaha... Why not just add KDE and openoffice to the base environment?
Enrico
On Fri, Feb 09, 2007 at 10:42:17PM +0100, Enrico Scholz wrote:
Maybe we need a minimal assumed runtime environment just like we define a minimal assumed build evironment?
What's wrong with the current situation that we need such a change?
Because as it stands now the OP's question on whether to add coreutils as a dependency is valid and would have to be positively confirmed. Or rephrased: the current situation is that the practice and the guidelines diverge and we need to fix one of them.
The definition of such a beast would be the minimal set of packages that are needed to do anything sensible, for example everything that is pulled in by redhat-lsb (which includes coreutils).
Hahaha... Why not just add KDE and openoffice to the base environment?
Because they are too big? Hohoho.
On Friday 09 February 2007 23:24, Axel Thimm wrote:
Maybe we need a minimal assumed runtime environment just like we define a minimal assumed build evironment? The definition of such a beast would be the minimal set of packages that are needed to do anything sensible, for example everything that is pulled in by redhat-lsb (which includes coreutils).
redhat-lsb is far from being a suitable package for this. As an example, here's what "yum install redhat-lsb" would do to my very sensibly working, although admittedly quite trimmed down PVR running FC6:
============================================================================= Package Arch Version Repository Size ============================================================================= Installing: redhat-lsb i386 3.1-11 core 21 k Installing for dependencies: at i386 3.1.8-84.fc6 updates 55 k bc i386 1.06-21 core 106 k binutils i386 2.17.50.0.6-2.fc6 updates 2.9 M cairo i386 1.2.6-1.fc6 updates 406 k cups i386 1:1.2.7-1.8.fc6 updates 2.8 M cups-libs i386 1:1.2.7-1.8.fc6 updates 181 k dbus i386 1.0.1-9.fc6 updates 471 k ed i386 0.3-0.fc6 updates 54 k file i386 4.19-1.fc6 updates 357 k gettext i386 0.14.6-4.fc6 updates 1.4 M gnutls i386 1.4.1-2 core 349 k groff i386 1.18.1.1-11.1 core 1.9 M libXft i386 2.1.10-1.1 core 44 k libXi i386 1.0.1-3.1 core 25 k libXrender i386 0.9.1-3.1 core 27 k libXt i386 1.0.2-3.1.fc6 core 174 k libxml2-python i386 2.6.27-1.FC6 updates 705 k m4 i386 1.4.5-4 updates 133 k make i386 1:3.81-1.1 core 465 k man i386 1.6d-2.fc6 updates 263 k pango i386 1.14.8-1.fc6 updates 330 k paps i386 0.6.6-17.fc6 updates 32 k patch i386 2.5.4-29.2.2 core 64 k pax i386 3.4-1.2.2 core 63 k time i386 1.7-27.2.2 core 17 k tmpwatch i386 2.9.7-1.1 core 18 k
Transaction Summary ============================================================================= Install 27 Package(s) Update 0 Package(s) Remove 0 Package(s)
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
Maybe we need a minimal assumed runtime environment just like we define a minimal assumed build evironment?
What's wrong with the current situation that we need such a change?
Because as it stands now the OP's question on whether to add coreutils as a dependency is valid and would have to be positively confirmed. Or rephrased: the current situation is that the practice and the guidelines diverge and we need to fix one of them.
Obviously, 'coreutils' MUST be a Requires(...) when they are used in the corresponding scriptlet. Afais, only some Core package are violating this simple rule and must be fixed.
The definition of such a beast would be the minimal set of packages that are needed to do anything sensible, for example everything that is pulled in by redhat-lsb (which includes coreutils).
Hahaha... Why not just add KDE and openoffice to the base environment?
Because they are too big? Hohoho.
Is there such big difference in the size between 'redhat-lsb' and 'KDE'?
Enrico
On Fri, Feb 09, 2007 at 11:54:46PM +0200, Ville Skyttä wrote:
On Friday 09 February 2007 23:24, Axel Thimm wrote:
Maybe we need a minimal assumed runtime environment just like we define a minimal assumed build evironment? The definition of such a beast would be the minimal set of packages that are needed to do anything sensible, for example everything that is pulled in by redhat-lsb (which includes coreutils).
redhat-lsb is far from being a suitable package for this. As an example, here's what "yum install redhat-lsb" would do to my very sensibly working, although admittedly quite trimmed down PVR running FC6:
libXrender i386 0.9.1-3.1 core 27 k
Indeed, redhat-lsb does pull in a lot of crap, and thanks for going into details to demonstrate this (it does make a difference whether s/o explains his viewpoint or not ..., Ville get's all the karma points this round ;).
Anyway the basic idea remains, we need something to define a very basic run time environment which all packages (but some bootstraping ones like glibc/setup/filesystem) may assume existing to not bloat the dependencies. Perhaps that's just coreutils and its dependencies, perhaps more.
Axel Thimm (Axel.Thimm@ATrpms.net) said:
Anyway the basic idea remains, we need something to define a very basic run time environment which all packages (but some bootstraping ones like glibc/setup/filesystem) may assume existing to not bloat the dependencies. Perhaps that's just coreutils and its dependencies, perhaps more.
... why?
Bill, who must have missed the first part of this...
Axel.Thimm@ATrpms.net (Axel Thimm) writes:
Anyway the basic idea remains, we need something to define a very basic run time environment which all packages (but some bootstraping ones like glibc/setup/filesystem) may assume existing to not bloat the dependencies.
Why do we need such exceptions? Are there existing problems with the current practice?
Enrico
On Fri, 2007-02-09 at 15:46 -0500, Fernando Nasser wrote:
Andrew Overholt wrote:
Are Requires(post{,un}) needed for things in coreutils?
The build system does not need it but Anaconda can get in trouble. We've been adding Requires(post{,un}) to rm and ls to several packages because of Anaconda.
More accurately, it's needed to get proper ordering in any case of building a new chroot. This doesn't get hit with initializing build roots due to the fact that they're (currently) done by "install minimal system, then build deps". This could change at a point in the future.
But yes, the requirements for things in coreutils must be explicitly specified, just like anything else.
Jeremy
On Fri, 2007-02-09 at 23:54 +0200, Ville Skyttä wrote:
On Friday 09 February 2007 23:24, Axel Thimm wrote:
Maybe we need a minimal assumed runtime environment just like we define a minimal assumed build evironment?
How about implementing a POSIX utilities package (or meta-package) consisting of all mandatory POSIX utilities?
c.f. http://www.opengroup.org/onlinepubs/009695399/idx/utilities.html
Ralf
On Sat, Feb 10, 2007 at 07:13:27AM +0100, Ralf Corsepius wrote:
c.f. http://www.opengroup.org/onlinepubs/009695399/idx/utilities.html
There are some old stuff in it, I spotted fort77 which is doesn't seems to be provided in fedora.
-- Pat
On Fri, Feb 09, 2007 at 06:03:08PM -0500, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm@ATrpms.net) said:
Anyway the basic idea remains, we need something to define a very basic run time environment which all packages (but some bootstraping ones like glibc/setup/filesystem) may assume existing to not bloat the dependencies. Perhaps that's just coreutils and its dependencies, perhaps more.
... why?
Bill, who must have missed the first part of this...
My assumption is that there are many packages making use of coreutils implicitely in their scriplets by using mv/rm/cp/touch etc w/o Requires(xxx) on coreutils (or a virtual/file provides of it). I think any package with a scriplet that doesn't chkconfig/service is most probably using coreutils w/o pulling it in (e.g. like rpm).
The situation is saved by sibling packages like initscripts and/or the kernel, e.g. the "bug" of missing coreutils dependencies goes unseen as there are very few setups w/o initscripts/kernel already in place. Still the packages are "broken" in the sense of not pulling in their dependencies themselves (inlcuding recursive pulling) as required by the guidelines.
So it's either a) Axel's assumption wrong, there are only few packages doing that - ignore him b) A large number of packages violating guidelines, so we either b1) fix all these packages b2) adjust the guidelines to assume existence of coreutils for 99.9% of all packages (reverse exceptions would be kernel/initscripts etc., something has to pull in coreutils after all)
Depending on the actual number of these packages the order of action is a) b1) b2), and I think the number will be large.
Maybe someone wants to script something to grep though all scriplets for coreutils bits to get these numbers.
On Sat, 2007-02-10 at 10:52 +0100, Patrice Dumas wrote:
On Sat, Feb 10, 2007 at 07:13:27AM +0100, Ralf Corsepius wrote:
c.f. http://www.opengroup.org/onlinepubs/009695399/idx/utilities.html
There are some old stuff in it,
What you call old is IEEE Std 1003.1, aka. SUSv3, THE current POSIX standard.
I spotted fort77 which is doesn't seems to be provided in fedora.
It's an FD extension to SUSv3, an option.
Ralf
On Sat, Feb 10, 2007 at 03:19:00PM +0100, Ralf Corsepius wrote:
What you call old is IEEE Std 1003.1, aka. SUSv3, THE current POSIX standard.
The standard may be recent, there are some old stuff in it. I have nothing against old stuff, I actually happen to maintain asa, but I don't think it belongs to a package set installed anywhere. Reading a bit more, there are indeed categories, so asa , fort77 and sccs are optional.
Maybe you wanted to have the all the mandatory commands? I think that it is still too much since there seems to be bc, for example, which is very usefull but not vital at all.
-- Pat
On Sat, Feb 10, 2007 at 03:59:05PM +0100, Patrice Dumas wrote:
Maybe you wanted to have the all the mandatory commands? I think that
In fact it is exactly what you said...
it is still too much since there seems to be bc, for example, which is very usefull but not vital at all.
A meta package or a comps category could be used, however, but I don't think it should be assumed to be there.
-- Pat
On Sat, 2007-02-10 at 16:01 +0100, Patrice Dumas wrote:
On Sat, Feb 10, 2007 at 03:59:05PM +0100, Patrice Dumas wrote:
Maybe you wanted to have the all the mandatory commands? I think that
In fact it is exactly what you said...
Almost, but not quite - POSIX mandates a certain set of "utilities" any POSIX compliant system must provide as "smallest common denominator".
These tools are a real world "norm"/"standard", all portable SW should be able to rely on.
My initial posting therefore was aim at, instead of "implementing a Fedora ad-hock standard set of utilities" to adopt what POSIX mandates.
Ralf
Andrew Overholt wrote :
Are Requires(post{,un}) needed for things in coreutils?
From the rest of the discussion, the answer seems to be "yes" as of
today.
But what you'd want for tomorrow is having the dependencies from a run of "bash --rpm-requires" on the scriplets be automatically added to the package's Requires(...).
It's pretty silly to still be doing all of these pre/post/... requirements manually, especially given that the vast majority of scriplets are the default (shell), and that the mechanism to fix this as been there for ages in both bash and rpm...
Matthias
packaging@lists.fedoraproject.org