6:53 a.m.
After awk, util-linux is missing from build root, too.
At least getopt is no longer available.
--
Gérard Milmeister
Langackerstrasse 49
CH-8057 Zürich
6:59 a.m.
On Wed, Aug 29, 2007 at 01:53:56PM +0200, Gérard Milmeister wrote:
After awk, util-linux is missing from build root, too.
At least getopt is no longer available.
absence of util-linux causes /bin/kill is unavailable as well:
http://koji.fedoraproject.org/koji/getfile?taskID=134499&name=build.log
Jindrich
--
Jindrich Novy <jnovy(a)redhat.com> http://people.redhat.com/jnovy/
7:09 a.m.
On Wed, 29 Aug 2007 13:59:40 +0200
Jindrich Novy <jnovy(a)redhat.com> wrote:
absence of util-linux causes /bin/kill is unavailable as well:
http://koji.fedoraproject.org/koji/getfile?taskID=134499&name=build.log
Why does your build need /kill/ ?
util-linux is 'until-linux-ng' now if you need to BuildRequire it.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
7:22 a.m.
Jesse Keating wrote:
On Wed, 29 Aug 2007 13:59:40 +0200
Jindrich Novy <jnovy(a)redhat.com> wrote:
> absence of util-linux causes /bin/kill is unavailable as well:
> http://koji.fedoraproject.org/koji/getfile?taskID=134499&name=build.log
Why does your build need /kill/ ?
util-linux is 'until-linux-ng' now if you need to BuildRequire it.
I've had this problem too (all the OCaml packages use a script which
needs getopt(1)). I've worked around it by BR-ing util-linux-ng in the
one package which I had to rebuild, so that I can avoid having to
rebuild the base ocaml which would need the dozen or so other packages
to be done too. Since util-linux was in the default buildroot before,
why not util-linux-ng now?
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
7:46 a.m.
On Wed, Aug 29, 2007 at 08:09:01AM -0400, Jesse Keating wrote:
On Wed, 29 Aug 2007 13:59:40 +0200
Jindrich Novy <jnovy(a)redhat.com> wrote:
> absence of util-linux causes /bin/kill is unavailable as well:
> http://koji.fedoraproject.org/koji/getfile?taskID=134499&name=build.log
Why does your build need /kill/ ?
It's db4, it kills kittens ;)
Seriously, comment in the configure script says it's needed
for the Tcl suite. Don't ask me why.
util-linux is 'until-linux-ng' now if you need to
BuildRequire it.
Ok, thanks.
Jindrich
--
Jindrich Novy <jnovy(a)redhat.com> http://people.redhat.com/jnovy/
8:19 a.m.
On Wed, 29 Aug 2007 08:09:01 -0400, Jesse Keating wrote:
> absence of util-linux causes /bin/kill is unavailable as well:
> http://koji.fedoraproject.org/koji/getfile?taskID=134499&name=build.log
Why does your build need /kill/ ?
util-linux is 'until-linux-ng' now if you need to BuildRequire it.
It sounds really bad that the old plans of a minimal build environment
find such an unfortunate end here.
8:40 a.m.
On Wed, 2007-08-29 at 15:19 +0200, Michael Schwendt wrote:
On Wed, 29 Aug 2007 08:09:01 -0400, Jesse Keating wrote:
> > absence of util-linux causes /bin/kill is unavailable as well:
> > http://koji.fedoraproject.org/koji/getfile?taskID=134499&name=build.log
>
>
> Why does your build need /kill/ ?
>
> util-linux is 'until-linux-ng' now if you need to BuildRequire it.
It sounds really bad that the old plans of a minimal build environment
find such an unfortunate end here.
May be you now understand, why I prefer using file-BR's instead of
package BRs :-)
Ralf
10:39 a.m.
On Wed, 29 Aug 2007 15:40:24 +0200
Ralf Corsepius <rc040203(a)freenet.de> wrote:
May be you now understand, why I prefer using file-BR's instead
of
package BRs :-)
Irrelevant. util-linux-ng holds all proper Provides for the things it
obsoleted.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
10:52 a.m.
On Wed, 2007-08-29 at 11:39 -0400, Jesse Keating wrote:
On Wed, 29 Aug 2007 15:40:24 +0200
Ralf Corsepius <rc040203(a)freenet.de> wrote:
> May be you now understand, why I prefer using file-BR's instead of
> package BRs :-)
Irrelevant.
?!? BR: <exotic tool in use> and nothing would have happened,
independent of which package provides it or what currently might be in
your rolling "minmal buildroot"
Ralf
10:22 a.m.
On Wed, 29 Aug 2007 15:19:55 +0200
Michael Schwendt <mschwendt.tmp0701.nospam(a)arcor.de> wrote:
It sounds really bad that the old plans of a minimal build
environment
find such an unfortunate end here.
Not sure what you mean. We changed /nothing/ with regard to the
packages we ask to install in the buildroot. What gets depresolved out
from there is purely bonus packages and shouldn't be relied upon
completely.
I'm open to discussion about amending the hard set we ask for, but that
should be driven through say FESCo.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
10:54 a.m.
On Wed, 29 Aug 2007 11:22:04 -0400, Jesse Keating wrote:
> It sounds really bad that the old plans of a minimal build
environment
> find such an unfortunate end here.
Not sure what you mean.
What I mean is that suddenly it seems we're back to BuildRequiring
lots of hardcoded package names or file paths for low-level tools that
should _just be there_ in a core environment without the need to BR
them.
Seeing the suggestion that packagers should BR util-linux-ng triggered
my reaction. I feel that if more BR like that are needed "now", we
will see more path-based BR, too, and BR for fundamental tools like cpp,
gcc, gcc-c++, rpm-build, /bin/sh, ...
10:58 a.m.
On Wed, 29 Aug 2007 17:54:39 +0200
Michael Schwendt <mschwendt.tmp0701.nospam(a)arcor.de> wrote:
Seeing the suggestion that packagers should BR util-linux-ng
triggered
my reaction. I feel that if more BR like that are needed "now", we
will see more path-based BR, too, and BR for fundamental tools like
cpp, gcc, gcc-c++, rpm-build, /bin/sh, ...
Did you miss the last part of my mail where I gave an opportunity and a
place to bring suggestions to growing the base set of packages we
target? Depchains change and relying upon them to always equate out to
the same set of packages is risky at best. We list exactly what we ask
to install, anything beyond that should be listed in packages as BRs.
If we want to extend what we ask for, that's a FESCo topic, but I'm
very open to discussion.
What I don't want is reactionary "Oh this dep changed and $foo is no
longer being dragged into the buildroot for me, better update the
static list of what we ask for!"
--
Jesse Keating
Fedora -- All my bits are free, are yours?
12:09 p.m.
On Wed, 29 Aug 2007 11:58:25 -0400, Jesse Keating wrote:
> Seeing the suggestion that packagers should BR util-linux-ng
triggered
> my reaction. I feel that if more BR like that are needed "now", we
> will see more path-based BR, too, and BR for fundamental tools like
> cpp, gcc, gcc-c++, rpm-build, /bin/sh, ...
Did you miss the last part of my mail where I gave an opportunity and a
place to bring suggestions to growing the base set of packages we
target?
No, I saw it, but the bureaucracy (and suggested discussion) is beyond
my time. This is the 2nd time in one week that a tool is missing in
the buildroots, and it hasn't gone unnoticed by FESCo. The original
definition of the minimal buildroot is void.
What I don't want is reactionary "Oh this dep changed and
$foo is no
longer being dragged into the buildroot for me, better update the
static list of what we ask for!"
Then why the silent modifications to the buildroot list?
Follow from
http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions
to
http://fedoraproject.org/wiki/Packaging/FullExceptionList
and notice
http://fedoraproject.org/wiki/Packaging/FullExceptionList?action=diff&...
The Exceptions list is and the explanations at the top of the
FullExceptionList page are void now, too.
1:21 p.m.
Michael Schwendt wrote:
On Wed, 29 Aug 2007 11:58:25 -0400, Jesse Keating wrote:
>> Seeing the suggestion that packagers should BR util-linux-ng triggered
>> my reaction. I feel that if more BR like that are needed "now", we
>> will see more path-based BR, too, and BR for fundamental tools like
>> cpp, gcc, gcc-c++, rpm-build, /bin/sh, ...
>>
> Did you miss the last part of my mail where I gave an opportunity and a
> place to bring suggestions to growing the base set of packages we
> target?
>
No, I saw it, but the bureaucracy (and suggested discussion) is beyond
my time. This is the 2nd time in one week that a tool is missing in
the buildroots, and it hasn't gone unnoticed by FESCo. The original
definition of the minimal buildroot is void.
AFAIK this hasn't changed at all:
http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions
I'm sorry that what you assumed would be there isn't, but what we say
will be there (as listed in the Packaging Guidelines) is as it always
was. The implicit list has been removed but the explicit list hasn't
changed and without FESCo approval, won't.
-Mike
1:53 p.m.
On Wed, 29 Aug 2007 13:21:41 -0500, Mike McGrath wrote:
Michael Schwendt wrote:
> On Wed, 29 Aug 2007 11:58:25 -0400, Jesse Keating wrote:
>
>
>>> Seeing the suggestion that packagers should BR util-linux-ng triggered
>>> my reaction. I feel that if more BR like that are needed "now",
we
>>> will see more path-based BR, too, and BR for fundamental tools like
>>> cpp, gcc, gcc-c++, rpm-build, /bin/sh, ...
>>>
>> Did you miss the last part of my mail where I gave an opportunity and a
>> place to bring suggestions to growing the base set of packages we
>> target?
>>
>
> No, I saw it, but the bureaucracy (and suggested discussion) is beyond
> my time. This is the 2nd time in one week that a tool is missing in
> the buildroots, and it hasn't gone unnoticed by FESCo. The original
> definition of the minimal buildroot is void.
>
>
AFAIK this hasn't changed at all:
http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions
I'm sorry that what you assumed would be there isn't, but what we say
will be there (as listed in the Packaging Guidelines) is as it always
was. The implicit list has been removed but the explicit list hasn't
changed and without FESCo approval, won't.
Which only proves my original comment. ;)
Tom Callaway's explanations in the guidelines:
| These are the packages you can safely assume will be present in a
| BuildRoot without being pulled in by a package's BuildRequires.
That is NOT safe anymore.
Conclusively, if the expanded "FullExceptionList" cannot be relied
on anymore, the minimal list is useless. Packages like sed, tar, gawk
suddenly cannot be expected anymore to be available in the buildroot.
This sucks.
2:14 p.m.
On Wed, 29 Aug 2007 20:53:01 +0200
Michael Schwendt <mschwendt.tmp0701.nospam(a)arcor.de> wrote:
Conclusively, if the expanded "FullExceptionList" cannot be
relied
on anymore, the minimal list is useless. Packages like sed, tar, gawk
suddenly cannot be expected anymore to be available in the buildroot.
This sucks.
So help us come up with a better hard list of packages, so that the
explicit list is more useful and we don't have to worry about implicit
changes, instead of just whining about it on a mailing list.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
2:39 p.m.
On Wed, 29 Aug 2007 15:14:35 -0400, Jesse Keating wrote:
> Conclusively, if the expanded "FullExceptionList"
cannot be relied
> on anymore, the minimal list is useless. Packages like sed, tar, gawk
> suddenly cannot be expected anymore to be available in the buildroot.
> This sucks.
So help us come up with a better hard list of packages, so that the
explicit list is more useful and we don't have to worry about implicit
changes, instead of just whining about it on a mailing list.
I'm not whining, but pointing out flaws which -- surprisingly -- meet
resistance.
With the full list deleted, coreutils, bash and many other fundamental
packages are not guaranteed to be available in the default buildroot
anymore. It is beyond my comprehension that somebody claims everything
would be fine.
You want a fix? Join the old minimal list and the expanded list to
build a new list. Keep the combined list unchanged and under control
of FESCo. That's the defined minimal list of BR which need not be
added to spec files.
3:01 p.m.
Michael Schwendt wrote:
On Wed, 29 Aug 2007 15:14:35 -0400, Jesse Keating wrote:
>> Conclusively, if the expanded "FullExceptionList" cannot be relied
>> on anymore, the minimal list is useless. Packages like sed, tar, gawk
>> suddenly cannot be expected anymore to be available in the buildroot.
>> This sucks.
>>
> So help us come up with a better hard list of packages, so that the
> explicit list is more useful and we don't have to worry about implicit
> changes, instead of just whining about it on a mailing list.
>
I'm not whining, but pointing out flaws which -- surprisingly -- meet
resistance.
With the full list deleted, coreutils, bash and many other fundamental
packages are not guaranteed to be available in the default buildroot
anymore. It is beyond my comprehension that somebody claims everything
would be fine.
There must be a miscommunication here. Bash is on the list that will
always be there:
http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions
As far as the 'full list deletee' it never should have been created in
the first place as it created an incorrect expectation of what would be
there.
You want a fix? Join the old minimal list and the expanded list to
build a new list. Keep the combined list unchanged and under control
of FESCo. That's the defined minimal list of BR which need not be
added to spec files.
Sounds fine to me, I like gawk :) Anyone care to own this and take it
to the FESCo?
-Mike
3:10 p.m.
On Wed, Aug 29, 2007 at 03:01:28PM -0500, Mike McGrath wrote:
>
Sounds fine to me, I like gawk :) Anyone care to own this and take it to
the FESCo?
I have just sent a mail proposing to add
cpp binutils file findutils gawk glibc-devel grep libstdc++-devel mktemp
util-linux which
--
Pat
3:17 p.m.
Le mercredi 29 août 2007 à 22:10 +0200, Patrice Dumas a écrit :
On Wed, Aug 29, 2007 at 03:01:28PM -0500, Mike McGrath wrote:
>>
> Sounds fine to me, I like gawk :) Anyone care to own this and take it to
> the FESCo?
I have just sent a mail proposing to add
cpp binutils file findutils gawk glibc-devel grep libstdc++-devel mktemp
util-linux which
why gawk and not sed ?
more people use sed, and it's lighter
--
Nicolas Mailhot
3:20 p.m.
On Wed, Aug 29, 2007 at 10:17:46PM +0200, Nicolas Mailhot wrote:
Le mercredi 29 août 2007 à 22:10 +0200, Patrice Dumas a écrit :
> On Wed, Aug 29, 2007 at 03:01:28PM -0500, Mike McGrath wrote:
> >>
> > Sounds fine to me, I like gawk :) Anyone care to own this and take it to
> > the FESCo?
>
> I have just sent a mail proposing to add
> cpp binutils file findutils gawk glibc-devel grep libstdc++-devel mktemp
> util-linux which
why gawk and not sed ?
more people use sed, and it's lighter
sed is already in the list.
--
Pat
3:22 p.m.
On Wed, 29 Aug 2007 22:10:48 +0200, Patrice Dumas wrote:
On Wed, Aug 29, 2007 at 03:01:28PM -0500, Mike McGrath wrote:
>>
> Sounds fine to me, I like gawk :) Anyone care to own this and take it to
> the FESCo?
I have just sent a mail proposing to add
cpp binutils file findutils gawk glibc-devel grep libstdc++-devel mktemp
util-linux which
Ha! Patrice has had a close look and spotted it, too. ;)
sed is on the minimal list already.
3:34 a.m.
On Wed, Aug 29, 2007 at 10:10:48PM +0200, Patrice Dumas wrote:
On Wed, Aug 29, 2007 at 03:01:28PM -0500, Mike McGrath wrote:
>>
> Sounds fine to me, I like gawk :) Anyone care to own this and take it to
> the FESCo?
I have just sent a mail proposing to add
cpp binutils file findutils gawk glibc-devel grep libstdc++-devel mktemp
util-linux which
This list looks good. +1.
regards,
Florian La Roche
6:20 a.m.
On Thu, Aug 30, 2007 at 10:34:15AM +0200, Florian La Roche wrote:
On Wed, Aug 29, 2007 at 10:10:48PM +0200, Patrice Dumas wrote:
> On Wed, Aug 29, 2007 at 03:01:28PM -0500, Mike McGrath wrote:
> >>
> > Sounds fine to me, I like gawk :) Anyone care to own this and take it to
> > the FESCo?
>
> I have just sent a mail proposing to add
> cpp binutils file findutils gawk glibc-devel grep libstdc++-devel mktemp
> util-linux which
This list looks good. +1.
according to:
http://www.gnu.org/software/autoconf/manual/standards.html#Utilities-in-M...
7.2.2 Utilities in Makefiles
Write the Makefile commands (and any shell scripts, such as configure)
to run in sh, not in csh. Don't use any special features of ksh or
bash.
The configure script and the Makefile rules for building and
installation should not use any utilities directly except these:
cat cmp cp diff echo egrep expr false grep install-info
ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch
true
we also need the "info" package (install-info binary).
Karel
--
Karel Zak <kzak(a)redhat.com>
6:54 a.m.
On Thu, 30 Aug 2007 13:23:01 +0200, Patrice Dumas wrote:
On Thu, Aug 30, 2007 at 01:20:23PM +0200, Karel Zak wrote:
>
>
> we also need the "info" package (install-info binary).
I am not sure about this one, since it will never be usefull in staged
installs. And it has to be in Requires(pre) anyway.
If a Makefile uses it to install info files, it must be a BR. Else it
might happen that a missing install-info results in missing info
files. It's useful to make "info" part of the minimal buildroot.
10:39 a.m.
On Thursday 30 August 2007, Michael Schwendt wrote:
If a Makefile uses it to install info files, it must be a BR. Else it
might happen that a missing install-info results in missing info
files.
The same thing can be said of just about every feature that is optional in
upstream Makefile/configure etc.
It's useful to make "info" part of the minimal
buildroot.
If the above reason is the only one, I don't agree.
11:04 a.m.
On Thu, Aug 30, 2007 at 06:39:00PM +0300, Ville Skyttä wrote:
On Thursday 30 August 2007, Michael Schwendt wrote:
>
> If a Makefile uses it to install info files, it must be a BR. Else it
> might happen that a missing install-info results in missing info
> files.
The same thing can be said of just about every feature that is optional in
upstream Makefile/configure etc.
No, it is different. In fedora info manuals are always welcome,
and texinfo is widespread. However it may be considered broken to
have missing install-info results in missing info files. In
that case not having info in the buildroot would help finding the
issues.
Maybe we could add info to the minimal buildroot, remove it, then
rebuild everything and see if a lot of packges broke. We could do that
for all the utilities, but for info it may make more sense.
--
Pat
1:19 p.m.
On Thursday 30 August 2007, Patrice Dumas wrote:
On Thu, Aug 30, 2007 at 06:39:00PM +0300, Ville Skyttä wrote:
> On Thursday 30 August 2007, Michael Schwendt wrote:
> > If a Makefile uses it to install info files, it must be a BR. Else it
> > might happen that a missing install-info results in missing info
> > files.
>
> The same thing can be said of just about every feature that is optional
> in upstream Makefile/configure etc.
No, it is different. In fedora info manuals are always welcome,
and texinfo is widespread.
Ok, how is it different from something else that is optional per upstream
build setup, but considered always welcome in Fedora and widespread? X and
GNOME and Qt and KDE etc support is practically always welcome, so would you
like all libX*-devel, *gnome*-devel, qt*-devel and kde*-devel added to
the "minimal" build roots because some packages might not get those features
built in if the packager doesn't add the BR's?
(BTW, somewhat offtopic: I'm not saying they shouldn't always be packaged, but
info manuals are not really welcome in my setups, let alone texinfo. I hate
the "info" browser enough so I practically never use them, so all they do to
me is consume a bit of disk space and bandwidth on updates and cause package
scriptlet breakage every now and then.)
1:48 p.m.
On Thursday 30 August 2007 19:19:06 Ville Skyttä wrote:
(BTW, somewhat offtopic: I'm not saying they shouldn't always
be packaged,
but info manuals are not really welcome in my setups, let alone texinfo. I
hate the "info" browser enough so I practically never use them, so all they
do to me is consume a bit of disk space and bandwidth on updates and cause
package scriptlet breakage every now and then.)
info browser? Oh, you mean konqueror? ;-)
I know that konqueror uses info2html, it says so in every page converted :-) .
It is quite convenient while the original browser and even emacs mode are
uh... difficult to read/browse. :-)
--
José Abílio
2:08 p.m.
On Thu, Aug 30, 2007 at 09:19:06PM +0300, Ville Skyttä wrote:
Ok, how is it different from something else that is optional per upstream
build setup, but considered always welcome in Fedora and widespread? X and
GNOME and Qt and KDE etc support is practically always welcome, so would you
like all libX*-devel, *gnome*-devel, qt*-devel and kde*-devel added to
the "minimal" build roots because some packages might not get those features
built in if the packager doesn't add the BR's?
It is not the same, more like, for example, an optionnal build of a
fortran interface if the compiler is detected. Having gfortran in the
build root could have make sense if there were a lot of fortran
packages. For info it may be worth it.
--
Pat
7:10 a.m.
Hi,
On Thu, Aug 30, 2007 at 01:20:23PM +0200, Karel Zak wrote:
> On Wed, Aug 29, 2007 at 10:10:48PM +0200, Patrice Dumas wrote:
> > On Wed, Aug 29, 2007 at 03:01:28PM -0500, Mike McGrath wrote:
> > > Sounds fine to me, I like gawk :) Anyone care to own this and take it to
> > > the FESCo?
I'm willing to take this to FESCo. Is there a way to get to a FESCo
meeting, so that I can advocate this there?
I'm writing an essay on the topic, trying to prove every item very
thoroughly. All I know is that FESCo can be contacted by sending a
mail to fedora-maintainers(a)redhat.com. When I have my case complete,
I'll drop a mail there and wait for a reply.
> > cpp binutils file findutils gawk glibc-devel grep
libstdc++-devel mktemp
> > util-linux which
we also need the "info" package (install-info binary).
Yes, my current list for the essay contains it. Actually, I
currently have proofs only for:
findutils gawk grep info
For example, I'm not proposing "binutils," because relying on the
fact that gcc will always require them is not that dangerous.
I also considered util-linux, when jnovy mentioned that a package
needs "kill" to build properly. But I came to a conclusion that
"kill", "mount", nor any other command from util-linux doesn't
have
to be in the minimal buildroot.
OTOH, I think that it would be sane to have a rule that all packages
not explicitely listed on the Exception List have to be buildrequired
if they are necessary for the build.
If that rule were accepted, it would be of course necessary to add
"binutils" to Exception List.
Have a nice day,
Stepan Kasal
7:55 a.m.
On Thu, 30 Aug 2007 14:10:57 +0200, Stepan Kasal wrote:
I also considered util-linux, when jnovy mentioned that a package
needs "kill" to build properly. But I came to a conclusion that
"kill", "mount", nor any other command from util-linux doesn't
have
to be in the minimal buildroot.
arch, flock, getopt, rename are nice to have by default.
8:08 a.m.
Hi,
On Thu, Aug 30, 2007 at 02:55:12PM +0200, Michael Schwendt wrote:
On Thu, 30 Aug 2007 14:10:57 +0200, Stepan Kasal wrote:
> I also considered util-linux, when jnovy mentioned that a package
> needs "kill" to build properly. But I came to a conclusion that
> "kill", "mount", nor any other command from util-linux
doesn't have
> to be in the minimal buildroot.
arch, flock, getopt, rename are nice to have by default.
well, might be nice, but I'm afraid we need to be more exact.
Could you please find out or estimate, for each of the utils you
mentioned:
- how many upstream tarballs do not build without it?
- if they do not build, is it a transparent error, or
is it a hard-to-debug problem (builds but does not work in
certain special cases, for eample)?
- how many spec files call the utility?
If the number of packages affected is small, and if the broken
packages are easy to discover and fix, we can leave util-linux out.
Stepan
8:41 a.m.
On Thu, 30 Aug 2007 15:08:40 +0200, Stepan Kasal wrote:
Hi,
On Thu, Aug 30, 2007 at 02:55:12PM +0200, Michael Schwendt wrote:
> On Thu, 30 Aug 2007 14:10:57 +0200, Stepan Kasal wrote:
>
> > I also considered util-linux, when jnovy mentioned that a package
> > needs "kill" to build properly. But I came to a conclusion that
> > "kill", "mount", nor any other command from util-linux
doesn't have
> > to be in the minimal buildroot.
>
> arch, flock, getopt, rename are nice to have by default.
well, might be nice, but I'm afraid we need to be more exact.
Could you please find out or estimate, for each of the utils you
mentioned:
- how many upstream tarballs do not build without it?
- if they do not build, is it a transparent error, or
is it a hard-to-debug problem (builds but does not work in
certain special cases, for eample)?
- how many spec files call the utility?
If the number of packages affected is small, and if the broken
packages are easy to discover and fix, we can leave util-linux out.
Hyperbole. If such an enormous effort is needed to justify adding a
core package, it is certainly not worth it. It would require burning
cycles on thousands of tarballs, builds and checker-scripts to see
whether a tarball disables features or self-tests when a tool is
missing.
The "initscripts" package used to require "util-linux". For a package
that is available on the majority of Fedora/RHEL installations, I
don't see any reason to make it a special optional build requirement.
I'd rather add a generated set of buildroot packages to spec files
and save the time.
9:51 a.m.
Michael Schwendt wrote:
On Thu, 30 Aug 2007 15:08:40 +0200, Stepan Kasal wrote:
> Hi,
>
> On Thu, Aug 30, 2007 at 02:55:12PM +0200, Michael Schwendt wrote:
>> On Thu, 30 Aug 2007 14:10:57 +0200, Stepan Kasal wrote:
>>
>>> I also considered util-linux, when jnovy mentioned that a package
>>> needs "kill" to build properly. But I came to a conclusion that
>>> "kill", "mount", nor any other command from util-linux
doesn't have
>>> to be in the minimal buildroot.
>> arch, flock, getopt, rename are nice to have by default.
> well, might be nice, but I'm afraid we need to be more exact.
>
> Could you please find out or estimate, for each of the utils you
> mentioned:
> - how many upstream tarballs do not build without it?
> - if they do not build, is it a transparent error, or
> is it a hard-to-debug problem (builds but does not work in
> certain special cases, for eample)?
> - how many spec files call the utility?
>
> If the number of packages affected is small, and if the broken
> packages are easy to discover and fix, we can leave util-linux out.
Hyperbole. If such an enormous effort is needed to justify adding a
core package, it is certainly not worth it. It would require burning
cycles on thousands of tarballs, builds and checker-scripts to see
whether a tarball disables features or self-tests when a tool is
missing.
The "initscripts" package used to require "util-linux". For a
package
that is available on the majority of Fedora/RHEL installations, I
don't see any reason to make it a special optional build requirement.
I'd rather add a generated set of buildroot packages to spec files
and save the time.
Actually, we have been using a rebuild script here that actually does
some of those tests, though it's by far not 100% correct as it basically
only checks after a rebuild if
- The package built at all. If not, keeps the logfile to see where it
went wrong to figure out what was missing
- The build worked but the new requirements are different from the
"original" build.
The 2nd point obviously only covers stuff that generates requirements,
but in most cases this will happen (e.g. if you build some package that
checks for a lib and the devel package for that lib isn't installed it
will disable the feature then your final package will not have the
requirement on that said lib anymore, so an automatically detectable
change).
I think Karsten Hopp sent around a list every once in a while with the
results of those rebuilds. We're currently in the process of cleaning up
and documenting those rebuilds scripts properly (ugly hacks FTW ;) ) and
release them in the near future (some public repository). Keep in mind
though that a full rebuild of Fedora even on PHAT machines takes an
awful lot of time. We're using a big Intel 4 CPU dual core HT machine
(so virtually 16 CPUS) with loads of memory and even on that box it
takes several days to complete. Also disk storage needs to be quite
large as we need to keep a whole tree mirrored on disk (source and
binaries for comparisons) together with up to 20 build processes running
at the same time and logfiles and final binary rpms being stored. Ofc
you can do single rebuilds or partial trees with the scripts as well. ;)
Read ya, Phil
--
Philipp Knirsch | Tel.: +49-711-96437-470
Team Lead Core Services | Fax.: +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch <pknirsch(a)redhat.com>
Hauptstaetterstr. 58 | Web: http://www.redhat.com/
D-70178 Stuttgart, Germany
Motd: You're only jealous cos the little penguins are talking to me.
8:52 a.m.
On Thu, 2007-08-30 at 15:08 +0200, Stepan Kasal wrote:
Hi,
On Thu, Aug 30, 2007 at 02:55:12PM +0200, Michael Schwendt wrote:
> On Thu, 30 Aug 2007 14:10:57 +0200, Stepan Kasal wrote:
>
> > I also considered util-linux, when jnovy mentioned that a package
> > needs "kill" to build properly. But I came to a conclusion that
> > "kill", "mount", nor any other command from util-linux
doesn't have
> > to be in the minimal buildroot.
>
> arch, flock, getopt, rename are nice to have by default.
well, might be nice, but I'm afraid we need to be more exact.
Could you please find out or estimate, for each of the utils you
mentioned:
Instead of trying to cater each and everybody's demand I'd
simply start
with standards, such as FHS/LSB and POSIX.
If the number of packages affected is small, and if the broken
packages are easy to discover and fix, we can leave util-linux out.
Check POSIX,
you'll find several of the util-linux tools are covered by
it, e.g. kill.
Ralf
9:50 a.m.
Hi Ralf,
On Thu, Aug 30, 2007 at 03:52:30PM +0200, Ralf Corsepius wrote:
Instead of trying to cater each and everybody's demand I'd
simply start
with standards, such as FHS/LSB and POSIX.
I did not mention POSIX, as I supposed that would imply too huge
buildroot. But your suggestion has made to look at this alternative
more closely, and it actually looks very sane.
We have to remove the crazy things from POSIX, like sccs, and a few
more (like "lp" which would bring cups, or "talk"), and that might
work. We would have to add a few small utilities which, though not
standardized by POSIX, are widely supposed (fgrep, egrep, tar, cpio).
Then a few bigger utils (e.g., perl) and here we go.
Thanks,
Stepan
10:12 a.m.
On Thu, Aug 30, 2007 at 05:00:41PM +0200, Nicolas Mailhot wrote:
Le Jeu 30 août 2007 16:50, Stepan Kasal a écrit :
> We would have to add a few small utilities ...
Ok
> Then a few bigger utils (e.g., perl) and here we go.
NO!
perl is already in the minimal build root. Personnaly
I think that it should go away, but there are opponent to
that view. Maybe for the next FESCo meeting?
--
Pat
12:22 p.m.
Hi,
On Thu, Aug 30, 2007 at 05:12:17PM +0200, Patrice Dumas wrote:
On Thu, Aug 30, 2007 at 05:00:41PM +0200, Nicolas Mailhot wrote:
> Le Jeu 30 août 2007 16:50, Stepan Kasal a écrit :
> > Then a few bigger utils (e.g., perl) and here we go.
>
> NO!
perl is already in the minimal build root. [...]
yes, that's what I had in mind. I would never propose adding it to
Exception List, but I do not feel strong enough to lobby for its
removal.
Stepan
10:13 a.m.
On Thu, 2007-08-30 at 16:50 +0200, Stepan Kasal wrote:
Hi Ralf,
On Thu, Aug 30, 2007 at 03:52:30PM +0200, Ralf Corsepius wrote:
> Instead of trying to cater each and everybody's demand I'd simply start
> with standards, such as FHS/LSB and POSIX.
I did not mention POSIX, as I supposed that would imply too huge
buildroot. But your suggestion has made to look at this alternative
more closely, and it actually looks very sane.
We have to remove the crazy things from POSIX, like sccs, and a few
more (like "lp" which would bring cups, or "talk"), and that might
work.
No disagreement on this.
We would have to add a few small utilities which, though not
standardized by POSIX, are widely supposed (fgrep, egrep, tar, cpio).
One detail:
egrep is dead, deprecated and supposed not to be used
anymore ... for years (You might seen it on autoconf@)
Ralf
12:27 p.m.
Hi,
On Thu, Aug 30, 2007 at 05:13:04PM +0200, Ralf Corsepius wrote:
> We would have to add a few small utilities which, though not
> standardized by POSIX, are widely supposed (fgrep, egrep, tar, cpio).
One detail: egrep is dead, deprecated and supposed not to be used
anymore ... for years (You might seen it on autoconf@)
sure, I know. Yet I don't think we can remove it from the buildroot.
The consequence would be that many backages would happily build, but
misconfigured. Hard to hunt for that.
What might make sense, is placing a bomb instead of [fe]grep and then
rebuilding. For each package which nukes, we'd notify upstream.
But is it worth the effort?
I think we should accept the fact that these non--standard commands
will stay available for very long... Backward compatibility...
And relying on the fact that everyone provides backward
compatibility... :-)
Have anice day,
Stepan
8:26 p.m.
On Thu, 2007-08-30 at 19:27 +0200, Stepan Kasal wrote:
Hi,
On Thu, Aug 30, 2007 at 05:13:04PM +0200, Ralf Corsepius wrote:
> > We would have to add a few small utilities which, though not
> > standardized by POSIX, are widely supposed (fgrep, egrep, tar, cpio).
> One detail: egrep is dead, deprecated and supposed not to be used
> anymore ... for years (You might seen it on autoconf@)
sure, I know. Yet I don't think we can remove it from the buildroot.
The consequence would be that many backages would happily build, but
misconfigured. Hard to hunt for that.
What might make sense, is placing a bomb instead of [fe]grep and then
rebuilding. For each package which nukes, we'd notify upstream.
But is it worth the effort?
Well, IMO, you hardly can avoid starting the effort,
otherwise you will
never be able to get rid of deprecated "standard tools".
I think we should accept the fact that these non--standard commands
will stay available for very long... Backward compatibility...
And relying on the fact that everyone provides backward
compatibility... :-)
I think, it would be best to split out egrep/fgrep into
separate
packages, say "grep-deprecated" or "grep-dontuse" or similar.
Ralf
8:16 a.m.
On Thu, 2007-08-30 at 14:10 +0200, Stepan Kasal wrote:
I'm willing to take this to FESCo. Is there a way to get to a
FESCo
meeting, so that I can advocate this there?
FESCo meets every Thursday at 1:00pm EST at #fedora-meeting on Freenode.
/B
--
Brian Pepple <bpepple(a)fedoraproject.org>
http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
3:21 p.m.
On Wed, 29 Aug 2007 15:01:28 -0500, Mike McGrath wrote:
Michael Schwendt wrote:
> On Wed, 29 Aug 2007 15:14:35 -0400, Jesse Keating wrote:
>
>
>>> Conclusively, if the expanded "FullExceptionList" cannot be
relied
>>> on anymore, the minimal list is useless. Packages like sed, tar, gawk
>>> suddenly cannot be expected anymore to be available in the buildroot.
>>> This sucks.
>>>
>> So help us come up with a better hard list of packages, so that the
>> explicit list is more useful and we don't have to worry about implicit
>> changes, instead of just whining about it on a mailing list.
>>
>
> I'm not whining, but pointing out flaws which -- surprisingly -- meet
> resistance.
>
> With the full list deleted, coreutils, bash and many other fundamental
> packages are not guaranteed to be available in the default buildroot
> anymore. It is beyond my comprehension that somebody claims everything
> would be fine.
>
There must be a miscommunication here. Bash is on the list that will
always be there:
http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions
Okay, that I get for not reloading the page due to temporary network
probs. :) But:
Then substitute the examples with glibc, libstdc++, binutils, cpp,
file, grep, mktemp, util-linux, ... you get the idea.
As far as the 'full list deletee' it never should have been
created in
the first place as it created an incorrect expectation of what would be
there.
Without the full list, how do you check the dep-chain for whether a BR
is installed implicitly? e.g. whether binutils or cpp are available?
They are pulled in by gcc, but when they are not listed anywhere, how
do you check whether they must be put into explicit BR? Without the
expanded [full] list one would need to add lots of BR to almost every
package, which is something the minimal list tries to avoid.
3:23 p.m.
On Wed, Aug 29, 2007 at 10:21:29PM +0200, Michael Schwendt wrote:
Then substitute the examples with glibc, libstdc++, binutils, cpp,
file, grep, mktemp, util-linux, ... you get the idea.
> As far as the 'full list deletee' it never should have been created in
> the first place as it created an incorrect expectation of what would be
> there.
Without the full list, how do you check the dep-chain for whether a BR
is installed implicitly? e.g. whether binutils or cpp are available?
They are pulled in by gcc, but when they are not listed anywhere, how
do you check whether they must be put into explicit BR? Without the
expanded [full] list one would need to add lots of BR to almost every
package, which is something the minimal list tries to avoid.
In my opinion adding:
cpp binutils file findutils gawk glibc-devel grep libstdc++-devel mktemp
util-linux which
to the minimal list would be enough to have everything needed. The libs
associated with the devel packages would be implicit.
--
Pat
9:35 p.m.
On Wed, 2007-08-29 at 22:21 +0200, Michael Schwendt wrote:
On Wed, 29 Aug 2007 15:01:28 -0500, Mike McGrath wrote:
> Michael Schwendt wrote:
> > On Wed, 29 Aug 2007 15:14:35 -0400, Jesse Keating wrote:
> >
> >
> >>> Conclusively, if the expanded "FullExceptionList" cannot be
relied
> >>> on anymore, the minimal list is useless. Packages like sed, tar, gawk
> >>> suddenly cannot be expected anymore to be available in the buildroot.
> >>> This sucks.
> >>>
> >> So help us come up with a better hard list of packages, so that the
> >> explicit list is more useful and we don't have to worry about implicit
> >> changes, instead of just whining about it on a mailing list.
> >>
> >
> > I'm not whining, but pointing out flaws which -- surprisingly -- meet
> > resistance.
> >
> > With the full list deleted, coreutils, bash and many other fundamental
> > packages are not guaranteed to be available in the default buildroot
> > anymore. It is beyond my comprehension that somebody claims everything
> > would be fine.
> >
> There must be a miscommunication here. Bash is on the list that will
> always be there:
> http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions
Okay, that I get for not reloading the page due to temporary network
probs. :) But:
Then substitute the examples with glibc, libstdc++, binutils, cpp,
file, grep, mktemp, util-linux, ... you get the idea.
The key to get this usable would be to use a _list of applications and
libraries_ and keep this _list constant_. Not a list of packages as it
is being done now.
Ralf
3:25 a.m.
On Thu, Aug 30, 2007 at 04:35:43AM +0200, Ralf Corsepius wrote:
The key to get this usable would be to use a _list of applications and
libraries_ and keep this _list constant_. Not a list of packages as it
is being done now.
Indeed it would be much better. Some applications could be described
functionally, like 'a C compiler' instead of gcc (not necessarily the
best exampel since there is an associated program, 'cc').
--
Pat
4:34 a.m.
On Thu, 30 Aug 2007 04:35:43 +0200, Ralf Corsepius wrote:
> Then substitute the examples with glibc, libstdc++, binutils,
cpp,
> file, grep, mktemp, util-linux, ... you get the idea.
The key to get this usable would be to use a _list of applications and
libraries_ and keep this _list constant_. Not a list of packages as it
is being done now.
That would be a next [harder] level and also a key to verifying
periodically that the low-level contents of the minimal buildroot
packages stay the same. That is, that no files get removed or renamed
unnoticed.
A list of package names is of limited use, sure. But it is better than
no such list.
We've defined the contents of our minimal buildroot by means of
traversing the dependencies of a smaller, essential root-set of
package names and checking whether the full set of dependencies
suffices.
That's why "python", "grep" and "file" have been an
implicit BR in the
fully expanded list, for example, while we've had to add "perl" and
"unzip" to the root-list explicitly. Historically, a few packages have
been added to the primary list explicitly as a safety measure, as not
to rely on dependencies in those cases and to ensure they are really
pulled in. The same could have been done with further packages and,
apparently, is necessary *now*.
The full set of packages has not become the primary list because it is
the result of recursion and as a side-effect contains several
"disturbing" packages, which are not as plausible as many of the
others on the list. You could only get rid of them by excluding them
explicitly -- more work for those who've maintained the list so far.
From the perspective of Joe Packager, if you need a program/file, you
hunt it down, "rpm -qf" or "repoquery --whatprovides" it, and add the
found package name as a BR. Yes, you could be pedantic and add the
full path of the needed file instead, but that would break if a
program were moved around in $PATH. Also, who would verify that a huge
configure script strictly requires /bin/foo instead of $(which foo)
for several dozens of different tools?
4:41 a.m.
Le Jeu 30 août 2007 11:34, Michael Schwendt a écrit :
From the perspective of Joe Packager, if you need a program/file,
you
hunt it down, "rpm -qf" or "repoquery --whatprovides" it, and add
the
found package name as a BR.
Or you do which foo and add this BR (a lot simpler, faster and more
reliable)
Yes, you could be pedantic and add the
full path of the needed file instead, but that would break if a
program were moved around in $PATH.
This is a very unusual event (much more than package shuffling)
because the FHS nailed this a long time ago
--
Nicolas Mailhot
4:50 a.m.
On Thu, 30 Aug 2007 11:41:11 +0200 (CEST), Nicolas Mailhot wrote:
Le Jeu 30 août 2007 11:34, Michael Schwendt a écrit :
> From the perspective of Joe Packager, if you need a program/file, you
> hunt it down, "rpm -qf" or "repoquery --whatprovides" it, and
add the
> found package name as a BR.
Or you do which foo and add this BR (a lot simpler, faster and more
reliable)
No, "rpm -qf $(which foo)" to be precise, since it returns only a path
and not a package name. And $(which foo) has been mentioned in the
mail you replied to.
> Yes, you could be pedantic and add the
> full path of the needed file instead, but that would break if a
> program were moved around in $PATH.
This is a very unusual event (much more than package shuffling)
because the FHS nailed this a long time ago
The FHS does not cover every file a packager might want to BR.
5:56 a.m.
Le Jeu 30 août 2007 11:50, Michael Schwendt a écrit :
On Thu, 30 Aug 2007 11:41:11 +0200 (CEST), Nicolas Mailhot wrote:
>
> Le Jeu 30 août 2007 11:34, Michael Schwendt a écrit :
>
> > From the perspective of Joe Packager, if you need a program/file,
> you
> > hunt it down, "rpm -qf" or "repoquery --whatprovides" it,
and add
> the
> > found package name as a BR.
>
> Or you do which foo and add this BR (a lot simpler, faster and more
> reliable)
No, "rpm -qf $(which foo)" to be precise, since it returns only a path
and not a package name.
Which was exactly the point. When a script/Makefile requires a
particular command, and this command has multiple implementation or is
provided by a package which naming stability is dubious, BR/R-ing the
filename and not the package name is the right thing.
If package naming and package repartition was stable or reliable we'd
be requiring perl package names instead of the stuff inside.
When you know the exact R/BR your package needs it's totaly insane to
go through the package name indirection.
--
Nicolas Mailhot
6:13 a.m.
On Thu, 30 Aug 2007 12:56:40 +0200 (CEST), Nicolas Mailhot wrote:
Le Jeu 30 août 2007 11:50, Michael Schwendt a écrit :
> On Thu, 30 Aug 2007 11:41:11 +0200 (CEST), Nicolas Mailhot wrote:
>
>>
>> Le Jeu 30 août 2007 11:34, Michael Schwendt a écrit :
>>
>> > From the perspective of Joe Packager, if you need a program/file,
>> you
>> > hunt it down, "rpm -qf" or "repoquery --whatprovides"
it, and add
>> the
>> > found package name as a BR.
>>
>> Or you do which foo and add this BR (a lot simpler, faster and more
>> reliable)
>
> No, "rpm -qf $(which foo)" to be precise, since it returns only a path
> and not a package name.
Which was exactly the point. When a script/Makefile requires a
particular command, and this command has multiple implementation or is
provided by a package which naming stability is dubious, BR/R-ing the
filename and not the package name is the right thing.
If package naming and package repartition was stable or reliable we'd
be requiring perl package names instead of the stuff inside.
There is a big difference between the perl(Foo::Module) virtual provides
and requiring full paths to file names.
/usr/bin/foo can move to /usr/local/bin/foo if you don't require
/usr/bin/foo explicitly anywhere. And this example works for other
paths, too.
Requiring file paths is dangerous when conflicts between packages
are permitted and shortest pkg name wins in yum depsolving. Enjoy
https://bugzilla.redhat.com/208781 for a utility pkg that conflicts
with give other pkgs.
When you know the exact R/BR your package needs it's totaly
insane to
go through the package name indirection.
Except that loading and parsing the metadata filelists slows down
the depsolver a lot, and requiring a single file does only guarantee
that you get the single file -- if you need many more files, would
you require each of them explicitly?
Anyway, we're drifting off, IMO.
6:14 a.m.
On Thu, 30 Aug 2007 13:13:25 +0200, Michael Schwendt wrote:
[...]
Requiring file paths is dangerous when conflicts between packages
are permitted and shortest pkg name wins in yum depsolving. Enjoy
https://bugzilla.redhat.com/208781 for a utility pkg that conflicts
with give other pkgs.
s/give/five/
7:13 a.m.
Le Jeu 30 août 2007 13:13, Michael Schwendt a écrit :
There is a big difference between the perl(Foo::Module) virtual
provides and requiring full paths to file names.
/usr/bin/foo can move to /usr/local/bin/foo
Not in our packaging. It *can* move from /usr/bin to /bin but that's
pretty unusual.
if you don't require
/usr/bin/foo explicitly anywhere. And this example works for other
paths, too.
The vast majority of the stuff people are clamouring for in buildroots
are small commands in /usr/bin and /bin.
Those do *not* wander in the filesystem. Too many scripts that
hardcode their path would break.
I've almost never seen a file dep of this kind be broken by filesystem
layout changes, and when it did happen it *always* happened with
massive package name shuffling that would have required fixing if a
rpm name had been used instead (immediate or delayed fixing, depending
on the fake provides the new package exposed if it was a 1:1 change)
Requiring file paths is dangerous when conflicts between packages
are permitted and shortest pkg name wins in yum depsolving.
So? You can make the same argument for perl modules, library names,
etc (with more reason as semi-compatible forks are legion)
> When you know the exact R/BR your package needs it's totaly
insane
> to go through the package name indirection.
>
Except that loading and parsing the metadata filelists slows down
the depsolver a lot
That's a tooling problem. Since you bring it up commands that end up
in everyone's default $PATH should end up in autoprovides not
filelists IMHO (most of them have a lot more reason to end up there
than some of the fluff the existing autoprovides scripts unearth,
those who don't usually have no place in $PATH either, and by not
making them explicit provides they slip through conflict checking)
and requiring a single file does only guarantee
that you get the single file -- if you need many more files, would
you require each of them explicitly?
If you need many commands that have no special reason to be in a
single package and in fact migrate from package to package requiring
them instead of putting the current container name is the right thing.
If you need many commands that are closely associated requiring just
one of them will pull the others just as effectively as the package
name.
If you need many commands that are closely associated and specific to
a particular implementation of a toolset requiring the toolset name is
the right thing. This is not the common case though.
However for common commands which have many implementations build
scripts can handle any one of them, and depending on the package name
of the implementation Fedora currently favours buys you nothing and
results in broken builds after a few years.
--
Nicolas Mailhot
8:10 a.m.
On Thu, 30 Aug 2007 14:13:44 +0200 (CEST), Nicolas Mailhot wrote:
> /usr/bin/foo can move to /usr/local/bin/foo
Not in our packaging.
But making it impossible can't be the goal either.
Since we package for specific releases of a distribution, I'd rather
recommend more use of the %check section in spec files at build-time.
> Requiring file paths is dangerous when conflicts between
packages
> are permitted and shortest pkg name wins in yum depsolving.
So? You can make the same argument for perl modules, library names,
etc (with more reason as semi-compatible forks are legion)
Sure. Just that file path Requires aren't automatic, except for script
interpreters.
We don't have virtual Provides for executables in distribution $PATH,
e.g. exec(grep)
> and requiring a single file does only guarantee
> that you get the single file -- if you need many more files, would
> you require each of them explicitly?
If you need many commands that have no special reason to be in a
single package and in fact migrate from package to package requiring
them instead of putting the current container name is the right thing.
If you need many commands that are closely associated requiring just
one of them will pull the others just as effectively as the package
name.
The guidelines talk about _guarantees_, though. The probability that
"Requires: /usr/bin/mount" pulls in related tools via util-linux is
high but no guarantee. Just recently, /usr/bin/setarch got moved from
one package to another, which then got renamed.
8:32 a.m.
Le Jeu 30 août 2007 15:10, Michael Schwendt a écrit :
On Thu, 30 Aug 2007 14:13:44 +0200 (CEST), Nicolas Mailhot wrote:
> > /usr/bin/foo can move to /usr/local/bin/foo
>
> Not in our packaging.
But making it impossible can't be the goal either.
We're not "making it impossible", anymore than naming a package some
way "makes it impossible" for other entities to make a different
choice. you can put a symlink in /usr/bin/ just like you can put some
fugly compat goo inside your third-party rpm
(also a lot of this stuff can not be moved because of LSB anyway)
> > Requiring file paths is dangerous when conflicts between
packages
> > are permitted and shortest pkg name wins in yum depsolving.
>
> So? You can make the same argument for perl modules, library names,
> etc (with more reason as semi-compatible forks are legion)
Sure. Just that file path Requires aren't automatic, except for script
interpreters.
That does not make autoprovide name collisions any less dangerous than
filename collisions
We don't have virtual Provides for executables in distribution
$PATH,
e.g. exec(grep)
More the pity
> > and requiring a single file does only guarantee
> > that you get the single file -- if you need many more files, would
> > you require each of them explicitly?
>
> If you need many commands that have no special reason to be in a
> single package and in fact migrate from package to package requiring
> them instead of putting the current container name is the right
> thing.
>
> If you need many commands that are closely associated requiring just
> one of them will pull the others just as effectively as the package
> name.
The guidelines talk about _guarantees_, though. The probability that
"Requires: /usr/bin/mount" pulls in related tools via util-linux is
high but no guarantee. Just recently, /usr/bin/setarch got moved from
one package to another, which then got renamed.
This is a perfect example of why requiring the container instead of
the actual stuff you need is bad. mount and setarch are not closely
related, they just happened to be bundled together for some time.
Regards,
--
Nicolas Mailhot
9:06 a.m.
On Thu, 30 Aug 2007 15:32:16 +0200 (CEST), Nicolas Mailhot wrote:
Le Jeu 30 août 2007 15:10, Michael Schwendt a écrit :
> On Thu, 30 Aug 2007 14:13:44 +0200 (CEST), Nicolas Mailhot wrote:
>
>> > /usr/bin/foo can move to /usr/local/bin/foo
>>
>> Not in our packaging.
>
> But making it impossible can't be the goal either.
We're not "making it impossible", anymore than naming a package some
way "makes it impossible" for other entities to make a different
choice. you can put a symlink in /usr/bin/ just like you can put some
fugly compat goo inside your third-party rpm
Not if /usr/local is installed from tarballs instead of from rpms.
That won't fill the RPM db.
(also a lot of this stuff can not be moved because of LSB anyway)
Do we need explicit path-based R/BR for programs covered by the LSB? =:-O
>> > Requiring file paths is dangerous when conflicts
between packages
>> > are permitted and shortest pkg name wins in yum depsolving.
>>
>> So? You can make the same argument for perl modules, library names,
>> etc (with more reason as semi-compatible forks are legion)
>
> Sure. Just that file path Requires aren't automatic, except for script
> interpreters.
That does not make autoprovide name collisions any less dangerous than
filename collisions
Every file in $PATH is automatically provided in the file lists.
Compare that with a Perl source file that must do something special
to create a module that results in a virtual Provides.
>> > and requiring a single file does only guarantee
>> > that you get the single file -- if you need many more files, would
>> > you require each of them explicitly?
>>
>> If you need many commands that have no special reason to be in a
>> single package and in fact migrate from package to package requiring
>> them instead of putting the current container name is the right
>> thing.
>>
>> If you need many commands that are closely associated requiring just
>> one of them will pull the others just as effectively as the package
>> name.
>
> The guidelines talk about _guarantees_, though. The probability that
> "Requires: /bin/mount" pulls in related tools via util-linux is
> high but no guarantee. Just recently, /usr/bin/setarch got moved from
> one package to another, which then got renamed.
This is a perfect example of why requiring the container instead of
the actual stuff you need is bad. mount and setarch are not closely
related, they just happened to be bundled together for some time.
It demonstrates why you would rather need to require lots of single
files, because you cannot rely on /bin/mount being bundled with
/bin/umount and more likely not being bundled with /sbin/losetup
either. Same for cpp, gcc, ld, strip, ...
A well-defined base environment that need not be specified as R/BR
is superior.
9:21 a.m.
Hi Michael,
On Thu, 30 Aug 2007, Michael Schwendt wrote:
Sure. Just that file path Requires aren't automatic, except for
script
interpreters.
We don't have virtual Provides for executables in distribution $PATH,
e.g. exec(grep)
I don't want to flame, but this feature is in rpm5 already for a longer
time. IMHO this sounds like another hidden request for rpm5 in Fedora ;-)
Greetings,
Robert
8:04 a.m.
On Thu, 2007-08-30 at 11:34 +0200, Michael Schwendt wrote:
On Thu, 30 Aug 2007 04:35:43 +0200, Ralf Corsepius wrote:
> > Then substitute the examples with glibc, libstdc++, binutils, cpp,
> > file, grep, mktemp, util-linux, ... you get the idea.
>
> The key to get this usable would be to use a _list of applications and
> libraries_ and keep this _list constant_. Not a list of packages as it
> is being done now.
That would be a next [harder] level and also a key to verifying
periodically that the low-level contents of the minimal buildroot
packages stay the same. That is, that no files get removed or renamed
unnoticed.
This doesn't sound terrible to me. If we did provide a list of library
requirements and application requirements that we define as minimal it
would be easy to pass that list to yum to resolve and install.
something to think about, anyway.
-sv
8:42 a.m.
On Thu, 30 Aug 2007 09:04:52 -0400
seth vidal <skvidal(a)fedoraproject.org> wrote:
This doesn't sound terrible to me. If we did provide a list of
library
requirements and application requirements that we define as minimal it
would be easy to pass that list to yum to resolve and install.
something to think about, anyway.
Can it be expressed as a comps group though? Does yum comps module
handle that?
Also keep in mind that part of having the minimal buildroot was so that
when people rebuild packages on their own, they didn't have to hunt
down why their package didn't build right due to silent missing
BuildRequires. That means we start with very little assumptions and
use the BuildRequires to build up exactly what we want around when this
package is built.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
8:45 a.m.
On Thu, 2007-08-30 at 09:42 -0400, Jesse Keating wrote:
On Thu, 30 Aug 2007 09:04:52 -0400
seth vidal <skvidal(a)fedoraproject.org> wrote:
> This doesn't sound terrible to me. If we did provide a list of library
> requirements and application requirements that we define as minimal it
> would be easy to pass that list to yum to resolve and install.
>
> something to think about, anyway.
Can it be expressed as a comps group though? Does yum comps module
handle that?
It can't atm, no. That could change, potentially.
Also keep in mind that part of having the minimal buildroot was so
that
when people rebuild packages on their own, they didn't have to hunt
down why their package didn't build right due to silent missing
BuildRequires. That means we start with very little assumptions and
use the BuildRequires to build up exactly what we want around when this
package is built.
I understand - I was just thinking that a base definition of libraries +
applications that we need for a minimal chroot has the virtue of
surviving independent of package renaming.
-sv
8:49 a.m.
On Thu, 30 Aug 2007 09:45:41 -0400
seth vidal <skvidal(a)fedoraproject.org> wrote:
I understand - I was just thinking that a base definition of
libraries + applications that we need for a minimal chroot has the
virtue of surviving independent of package renaming.
Yes, I see the value too, although it doesn't get us any closer to
doing away with file deps :/
--
Jesse Keating
Fedora -- All my bits are free, are yours?
9:12 a.m.
On Thu, 2007-08-30 at 09:49 -0400, Jesse Keating wrote:
On Thu, 30 Aug 2007 09:45:41 -0400
seth vidal <skvidal(a)fedoraproject.org> wrote:
> I understand - I was just thinking that a base definition of
> libraries + applications that we need for a minimal chroot has the
> virtue of surviving independent of package renaming.
Yes, I see the value too, although it doesn't get us any closer to
doing away with file deps :/
One easy way to implement this would be to collect a
list of tools those
tools being wanted and to generate a list of those packages providing
them "buildgroups.xml".
An alternative would be to implement an rpm which simply pulls all these
tools in ;)
Ralf
9:12 a.m.
On Thu, 30 Aug 2007 09:42:03 -0400, Jesse Keating wrote:
On Thu, 30 Aug 2007 09:04:52 -0400
seth vidal wrote:
> This doesn't sound terrible to me. If we did provide a list of library
> requirements and application requirements that we define as minimal it
> would be easy to pass that list to yum to resolve and install.
>
> something to think about, anyway.
Can it be expressed as a comps group though? Does yum comps module
handle that?
Also keep in mind that part of having the minimal buildroot was so that
when people rebuild packages on their own, they didn't have to hunt
down why their package didn't build right due to silent missing
BuildRequires. That means we start with very little assumptions and
use the BuildRequires to build up exactly what we want around when this
package is built.
One used to be able to NOT use mock, but build rpms in an average
desktop/workstation installation of Fedora and fill in missing BR
consecutively. Dropping core packages from the default target build
environment has the effect that one cannot use rpmdev-rmdevelrpms
anymore, because it would not uninstall enough packages. It cannot
uninstall core packages which are deep in the dep-chain, but which are
missing in a new minimal buildroot. Effectively, one would be forced
to use mock or lots of scratch-builds in koji to find the new BR.
2:44 a.m.
Mike McGrath wrote:
AFAIK this hasn't changed at all:
http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions
I'm sorry that what you assumed would be there isn't, but what we say
will be there (as listed in the Packaging Guidelines) is as it always
was. The implicit list has been removed but the explicit list hasn't
changed and without FESCo approval, won't.
Blah blah.
I have packages broken because basic programs like 'awk' and 'getopt'
are missing. All my Fedora contributions need to be rebuilt which is
going to take hours.
The aim of Fedora's team should be to encourage outside developers to
contribute, because **if outside developers are pissed like this and
leave for other friendlier distributions** then Fedora itself will be
destroyed.
So pointing to nebulous package guidelines as above is not just
unhelpful, but rude and will damage Fedora. Instead, you should be
working hard to help contributors and not changing everything underneath
them on whim.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
3:19 a.m.
On Thu, Aug 30, 2007 at 08:44:21AM +0100, Richard W.M. Jones wrote:
Blah blah.
I have packages broken because basic programs like 'awk' and 'getopt' are
missing. All my Fedora contributions need to be rebuilt which is going to
take hours.
Not getopt, but popt-devel.
I proposed gawk to be added to the minimal buildroot.
The aim of Fedora's team should be to encourage outside
developers to
contribute, because **if outside developers are pissed like this and leave
for other friendlier distributions** then Fedora itself will be destroyed.
It is right that encouraging outside developers to contribute is
important, but following guidelines is at least as important. Your
packages dependended on packages not in the BuildRequires exceptions
list. This should have been spotted during the review but it wasn't, so
it is normal that it breaks later.
So pointing to nebulous package guidelines as above is not just
unhelpful,
but rude and will damage Fedora. Instead, you should be working hard to
help contributors and not changing everything underneath them on whim.
The exception list is not a nebulous package guideline it is an
important guideline. Maybe you would prefer more packages in the minimal
build root, but it also has drawbacks. If the build root is bigger, then
there are more chances that an unwanted dependency enters, and it also
renders the minimal build root installation longer. So BuildRequires
exceptions have to be in the guidelines and the contributors must know
them.
And also this means that what is in the minimal build root should be
discussed because all the users don't have the same interests. In the
past wrong dependencies hide the issue, now it has become apparent, but
it was always here.
--
Pat
11:56 a.m.
On Wed, Aug 29, 2007 at 11:22:04AM -0400, Jesse Keating wrote:
On Wed, 29 Aug 2007 15:19:55 +0200
Michael Schwendt <mschwendt.tmp0701.nospam(a)arcor.de> wrote:
> It sounds really bad that the old plans of a minimal build environment
> find such an unfortunate end here.
Not sure what you mean. We changed /nothing/ with regard to the
packages we ask to install in the buildroot. What gets depresolved out
from there is purely bonus packages and shouldn't be relied upon
completely.
I was wondering what exactly has caused the change. It's removed
requirement in libselinux for mcstrans -> initscripts -> gawk,
util-linux and bunch of other packages.
--
Miroslav Lichvar
6100
days inactive
6102
days old
68 comments
19 participants
participants (19)
-
Brian Pepple -
Florian La Roche -
Gérard Milmeister -
Jesse Keating -
Jindrich Novy -
José Abílio Matos -
Karel Zak -
Michael Schwendt -
Mike McGrath -
Miroslav Lichvar -
Nicolas Mailhot -
Patrice Dumas -
Phil Knirsch -
Ralf Corsepius -
Richard W.M. Jones -
Robert Scheck -
Seth Vidal -
Stepan Kasal -
Ville Skyttä