7:40 a.m.
Hey all,
I know I'm opening up Pandoras box here but what the heck, it's Friday and
I'm feeling slightly bored...
With RPM 4.4.2.1 fresh out and 4.4.x branched off to maintenance mode,
time to start looking forward to next major release. While the focus will
be largely in cleaning up and streamlining the codebase, it can't
realistically be all about just that.
Not everybody is on rpm-maint list and we'd like to hear the wishes of
(Fedora) developers/packagers too. So: what have you always wanted to do
with rpm, but wasn't able to? Or the other way around: what you always
wished rpm would do for you? What always annoyed you out of your mind?
Just to kick off the discussion (like it was necessary, this is rpm
afterall...), here are a few things that have been brought up in various
forums and private discussions, but don't feel constrained by these items,
they're just some examples of what's being considered:
* Improving automatic dependency extraction
- Plugin architecture for internal dependency extractor to avoid having
to patch rpm itself for each new language
- libtool, pkgconfig requires + provides (easily ported from rpm5.org)
- <your favorite language> (python for me) library requires +
provides discovery
- Buildrequires match cross-arch on multilib, not good
- -devel package dependencies match cross-arch on multilib, not good
* Python bindings
- Ever wanted to fully drive a package build from python, without
having to resort to screenscraping rpmbuild output etc? I know I
have...
* Unix philosophy - do just one thing and do it well:
- RPM is not a GPG key manager but a package manager.
- RPM is not an ftp/http client, it's a package manager.
The more specific you can be, the better - "make it not suck" isn't
productive. Of course there's no way everything can be done, we want the
next major release out before end of the decade... Also this is not a
voting where most votes guarantee implementation, but consider it your
chance to be heard. I'm listening... :)
- Panu -
7:50 a.m.
Panu Matilainen wrote:
Not everybody is on rpm-maint list and we'd like to hear the wishes of
(Fedora) developers/packagers too. So: what have you always wanted to
do with rpm, but wasn't able to? Or the other way around: what you
always wished rpm would do for you? What always annoyed you out of
your mind?
arch requires and provides ... to end the endless multilib discussions ;)
should be automatic until the packager say Requires: foo.arch
3:46 p.m.
On Fri, 2007-07-27 at 14:50 +0200, dragoran wrote:
Panu Matilainen wrote:
>
> Not everybody is on rpm-maint list and we'd like to hear the wishes of
> (Fedora) developers/packagers too. So: what have you always wanted to
> do with rpm, but wasn't able to? Or the other way around: what you
> always wished rpm would do for you? What always annoyed you out of
> your mind?
arch requires and provides ... to end the endless multilib discussions ;)
should be automatic until the packager say Requires: foo.arch
Wow, beat me to the punch on that one.
+10
~spot
3:55 a.m.
On Fri, 27 Jul 2007, dragoran wrote:
Panu Matilainen wrote:
>
> Not everybody is on rpm-maint list and we'd like to hear the wishes of
> (Fedora) developers/packagers too. So: what have you always wanted to do
> with rpm, but wasn't able to? Or the other way around: what you always
> wished rpm would do for you? What always annoyed you out of your mind?
arch requires and provides ... to end the endless multilib discussions ;)
should be automatic until the packager say Requires: foo.arch
I wish it was that simple...
Sure, being able to say "Requires: foo.arch = version-release" would help
in many cases, but it does not *solve* the multilib problems.
A big offender here is the x86 architecture with i386, i486 ... etc
subarchitectures. While most packages are i386 there, the assumed
--
Requires: <name>.%{_target_cpu} = <version>-<release>
BuildRequires: <name>.%{_target_cpu} >= ...
--
gets into trouble when the subarch's don't match between packages (eg i386
vs i686 - just look at glibc vs glibc-common). Instead, you'd want to
match within 32bit vs 64bit (or independent, basically noarch) bitness of
the package (rpm uses the term "color" for this) and have the depsolver
sort out package with the best arch within that "color".
I'm starting to get tempted to have rpmbuild automatically slap in the
equivalent of
Provides: %{name}.%{color} = %{epoch}:%{version}-%{release}
..where %{color} gets expanded to 32bit, 64bit or none, based on the
highest color present in the package being built. I don't particularly
like the term "color" there, and also "none" for "noarch" is
not good,
but I don't want it to be "noarch" to avoid mixing with %{arch} when
it's
a different concept. Better suggestions welcome...
RPM itself could parse requires on %{name}.%{color} without having the
explicit provides added, but the color information is not present in the
repository metadata (at least currently) so depsolvers would need to be
taught about it separately, and second-guess the color based on the
package %arch.. probably just easier to slap in the explicit provide,
which can be then required by packages needing it.
BTW, there are cases where the dependency on the exact %{_target_cpu}
would be proper (look at libbeagle vs libbeagle-devel), but those are so
rare that I think they are sufficiently covered by manually adding
provides-requires pair on %{name}.%{_target_cpu}
It would be nice to automate all this, but it gets damn hairy. If you have
a manual "Requires: foo" or "BuildRequires: foo", how's rpm
supposed to
know whether foo is a package that
a) contains a utility the build needs, never mind the arch
b) contains a dlopen()'ed library, arch very much matters, to the point of
subarch's even
c) is a -devel package's dependency on another -devel package, color
matters (must match or be a noarch)
From there we get to the chicken-and-egg problem of srpms and spec
files.
The arch and color can only be determined on spec evaluation, but
src.rpm's are used to deliver the specs, duh... (this problem already
exists of course, "rpmbuild -bs foo.spec" can deliver different results
depending on which are it was run on due to spec conditionals)
And so on. Multilib is so lovely...
- Panu -
4:14 a.m.
Panu Matilainen wrote:
On Fri, 27 Jul 2007, dragoran wrote:
> Panu Matilainen wrote:
>>
>> Not everybody is on rpm-maint list and we'd like to hear the wishes
>> of (Fedora) developers/packagers too. So: what have you always
>> wanted to do with rpm, but wasn't able to? Or the other way around:
>> what you always wished rpm would do for you? What always annoyed you
>> out of your mind?
>
> arch requires and provides ... to end the endless multilib
> discussions ;)
> should be automatic until the packager say Requires: foo.arch
I wish it was that simple...
Sure, being able to say "Requires: foo.arch = version-release" would
help in many cases, but it does not *solve* the multilib problems.
A big offender here is the x86 architecture with i386, i486 ... etc
subarchitectures. While most packages are i386 there, the assumed
what about being
able to say foo.i?86
4:42 a.m.
On Thu, 2 Aug 2007, dragoran wrote:
Panu Matilainen wrote:
> On Fri, 27 Jul 2007, dragoran wrote:
>
>> Panu Matilainen wrote:
>>>
>>> Not everybody is on rpm-maint list and we'd like to hear the wishes of
>>> (Fedora) developers/packagers too. So: what have you always wanted to do
>>> with rpm, but wasn't able to? Or the other way around: what you always
>>> wished rpm would do for you? What always annoyed you out of your mind?
>>
>> arch requires and provides ... to end the endless multilib discussions ;)
>> should be automatic until the packager say Requires: foo.arch
>
> I wish it was that simple...
>
> Sure, being able to say "Requires: foo.arch = version-release" would help
> in many cases, but it does not *solve* the multilib problems.
>
> A big offender here is the x86 architecture with i386, i486 ... etc
> subarchitectures. While most packages are i386 there, the assumed
what about being able to say foo.i?86
What about foo.athlon which is also a 32bit arch?
And don't suggest "Requires: foo.i?86 || foo.athlon", because then you'd
have monsters like this in each and every spec:
%ifarch %{ix86}
Requires: foo.i?86 || foo.athlon
%fi
%ifarch x86_64
Requires: foo.x86_64
%fi
...
The exact %{arch} is not the point at all here.
- Panu -
4:54 a.m.
Panu Matilainen wrote:
On Thu, 2 Aug 2007, dragoran wrote:
> Panu Matilainen wrote:
>> On Fri, 27 Jul 2007, dragoran wrote:
>>
>>> Panu Matilainen wrote:
>>>>
>>>> Not everybody is on rpm-maint list and we'd like to hear the
>>>> wishes of (Fedora) developers/packagers too. So: what have you
>>>> always wanted to do with rpm, but wasn't able to? Or the other way
>>>> around: what you always wished rpm would do for you? What always
>>>> annoyed you out of your mind?
>>>
>>> arch requires and provides ... to end the endless multilib
>>> discussions ;)
>>> should be automatic until the packager say Requires: foo.arch
>>
>> I wish it was that simple...
>>
>> Sure, being able to say "Requires: foo.arch = version-release" would
>> help in many cases, but it does not *solve* the multilib problems.
>>
>> A big offender here is the x86 architecture with i386, i486 ... etc
>> subarchitectures. While most packages are i386 there, the assumed
> what about being able to say foo.i?86
What about foo.athlon which is also a 32bit arch?
And don't suggest "Requires: foo.i?86 || foo.athlon",
this is just
ugly so no.
because then you'd have monsters like this in each and every
spec:
%ifarch %{ix86}
Requires: foo.i?86 || foo.athlon
%fi
%ifarch x86_64
Requires: foo.x86_64
%fi
...
The exact %{arch} is not the point at all here.
ok thats indeed the wrong way to solve it.
what about forgot about the arch names and say foo.64bit or foo.32bit ?
5:08 a.m.
On Thu, 2 Aug 2007, dragoran wrote:
Panu Matilainen wrote:
> On Thu, 2 Aug 2007, dragoran wrote:
>
>> Panu Matilainen wrote:
>>> On Fri, 27 Jul 2007, dragoran wrote:
>>>
>>>> Panu Matilainen wrote:
>>>>>
>>>>> Not everybody is on rpm-maint list and we'd like to hear the
wishes of
>>>>> (Fedora) developers/packagers too. So: what have you always wanted to
>>>>> do with rpm, but wasn't able to? Or the other way around: what
you
>>>>> always wished rpm would do for you? What always annoyed you out of
your
>>>>> mind?
>>>>
>>>> arch requires and provides ... to end the endless multilib discussions
>>>> ;)
>>>> should be automatic until the packager say Requires: foo.arch
>>>
>>> I wish it was that simple...
>>>
>>> Sure, being able to say "Requires: foo.arch = version-release"
would help
>>> in many cases, but it does not *solve* the multilib problems.
>>>
>>> A big offender here is the x86 architecture with i386, i486 ... etc
>>> subarchitectures. While most packages are i386 there, the assumed
>> what about being able to say foo.i?86
>
> What about foo.athlon which is also a 32bit arch?
>
> And don't suggest "Requires: foo.i?86 || foo.athlon",
this is just ugly so no.
> because then you'd have monsters like this in each and every spec:
>
> %ifarch %{ix86}
> Requires: foo.i?86 || foo.athlon
> %fi
> %ifarch x86_64
> Requires: foo.x86_64
> %fi
> ...
>
> The exact %{arch} is not the point at all here.
>
ok thats indeed the wrong way to solve it.
what about forgot about the arch names and say foo.64bit or foo.32bit ?
Well that's more or less what I was suggesting :)
Only you can't have Requires: foo.64bit etc hardcoded in the spec for the
same reason as above: otherwise you'd have ugly arch conditionals all over
the specs. It must be something that's automatically expanded to correct
value at build time.
- Panu -
5:13 a.m.
Panu Matilainen wrote:
On Thu, 2 Aug 2007, dragoran wrote:
> Panu Matilainen wrote:
>> On Thu, 2 Aug 2007, dragoran wrote:
>>
>>> Panu Matilainen wrote:
>>>> On Fri, 27 Jul 2007, dragoran wrote:
>>>>
>>>>> Panu Matilainen wrote:
>>>>>>
>>>>>> Not everybody is on rpm-maint list and we'd like to hear the
>>>>>> wishes of (Fedora) developers/packagers too. So: what have you
>>>>>> always wanted to do with rpm, but wasn't able to? Or the
other
>>>>>> way around: what you always wished rpm would do for you? What
>>>>>> always annoyed you out of your mind?
>>>>>
>>>>> arch requires and provides ... to end the endless multilib
>>>>> discussions ;)
>>>>> should be automatic until the packager say Requires: foo.arch
>>>>
>>>> I wish it was that simple...
>>>>
>>>> Sure, being able to say "Requires: foo.arch = version-release"
>>>> would help in many cases, but it does not *solve* the multilib
>>>> problems.
>>>>
>>>> A big offender here is the x86 architecture with i386, i486 ...
>>>> etc subarchitectures. While most packages are i386 there, the assumed
>>> what about being able to say foo.i?86
>>
>> What about foo.athlon which is also a 32bit arch?
>>
>> And don't suggest "Requires: foo.i?86 || foo.athlon",
> this is just ugly so no.
>> because then you'd have monsters like this in each and every spec:
>>
>> %ifarch %{ix86}
>> Requires: foo.i?86 || foo.athlon
>> %fi
>> %ifarch x86_64
>> Requires: foo.x86_64
>> %fi
>> ...
>>
>> The exact %{arch} is not the point at all here.
>>
> ok thats indeed the wrong way to solve it.
> what about forgot about the arch names and say foo.64bit or foo.32bit ?
Well that's more or less what I was suggesting :)
;)
Only you can't have Requires: foo.64bit etc hardcoded in the spec
for
the same reason as above: otherwise you'd have ugly arch conditionals
all over the specs. It must be something that's automatically expanded
to correct value at build time.
was thinking the same whe need something like foo.%{32_64bit*}
*better name needed here ....
4:55 a.m.
On Thu, Aug 02, 2007 at 12:42:27PM +0300, Panu Matilainen wrote:
>>>>Not everybody is on rpm-maint list and we'd like
to hear the wishes of
>>>>(Fedora) developers/packagers too. So: what have you always wanted to
>>>>do with rpm, but wasn't able to? Or the other way around: what you
>>>>always wished rpm would do for you? What always annoyed you out of your
>>>>mind?
>>>
>>>arch requires and provides ... to end the endless multilib discussions ;)
>>>should be automatic until the packager say Requires: foo.arch
>>
>>I wish it was that simple...
>>
>>Sure, being able to say "Requires: foo.arch = version-release" would
help
>>in many cases, but it does not *solve* the multilib problems.
>>
>>A big offender here is the x86 architecture with i386, i486 ... etc
>>subarchitectures. While most packages are i386 there, the assumed
>what about being able to say foo.i?86
What about foo.athlon which is also a 32bit arch?
Can you match against the canonical arch, i.e. %{_arch}?
On ARM, we have armv3l, armv4l, armv4tl, armv5tl, armv5tel,
armv5tejl, armv6l, et cetera, but %{_arch} is always just 'arm'.
7:01 a.m.
On Thu, 2 Aug 2007, Lennert Buytenhek wrote:
On Thu, Aug 02, 2007 at 12:42:27PM +0300, Panu Matilainen wrote:
>>>>> Not everybody is on rpm-maint list and we'd like to hear the
wishes of
>>>>> (Fedora) developers/packagers too. So: what have you always wanted
to
>>>>> do with rpm, but wasn't able to? Or the other way around: what
you
>>>>> always wished rpm would do for you? What always annoyed you out of
your
>>>>> mind?
>>>>
>>>> arch requires and provides ... to end the endless multilib discussions
;)
>>>> should be automatic until the packager say Requires: foo.arch
>>>
>>> I wish it was that simple...
>>>
>>> Sure, being able to say "Requires: foo.arch = version-release"
would help
>>> in many cases, but it does not *solve* the multilib problems.
>>>
>>> A big offender here is the x86 architecture with i386, i486 ... etc
>>> subarchitectures. While most packages are i386 there, the assumed
>> what about being able to say foo.i?86
>
> What about foo.athlon which is also a 32bit arch?
Can you match against the canonical arch, i.e. %{_arch}?
On ARM, we have armv3l, armv4l, armv4tl, armv5tl, armv5tel,
armv5tejl, armv6l, et cetera, but %{_arch} is always just 'arm'.
That'd probably work for i386 and x86_64 but I wonder how ppc vs ppc64
behaves with %{_arch} ?
My dislike with that is it overloads the meaning of arch. Consider a
package for which i386 and i686 package is available, both would then
provide foo.i386. Confusing and problematic, at least in the cases where
you want (additional) dependency on %{_target_cpu}.
- Panu -
8:01 a.m.
On Friday 27 July 2007 14:40:40 Panu Matilainen wrote:
Not everybody is on rpm-maint list and we'd like to hear the
wishes of
(Fedora) developers/packagers too. So: what have you always wanted to do
with rpm, but wasn't able to? Or the other way around: what you always
wished rpm would do for you? What always annoyed you out of your mind?
I am missing "soft dependencies", e.g. the possibility to make a package
suggest which other packages may enhance it, e.g. with plugins. Afaik in
debian packages it is called "Suggests:".
Regards,
Till
11:53 a.m.
Till Maas wrote:
On Friday 27 July 2007 14:40:40 Panu Matilainen wrote:
> Not everybody is on rpm-maint list and we'd like to hear the wishes of
> (Fedora) developers/packagers too. So: what have you always wanted to do
> with rpm, but wasn't able to? Or the other way around: what you always
> wished rpm would do for you? What always annoyed you out of your mind?
>
I am missing "soft dependencies", e.g. the possibility to make a package
suggest which other packages may enhance it, e.g. with plugins. Afaik in
debian packages it is called "Suggests:".
+1.
I would really like to see this, especially for apps that are plugin
oriented / modular.
It's one of the few things I miss from Debian.
Regards,
Till
8:20 a.m.
On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
Or the other way around: what you always
wished rpm would do for you? What always annoyed you out of your mind?
* Version control the meta-information
This can't be efficiently done outside RPM, and it would provide
an administrator with an invaluable tool (say a malfunction starts
at about 4am):
- what packages changes are different from yesterday?
- what files have changed for package foo between version V and W?
- what's the history of package foo on this system?
Not very difficult, but quite useful. Every time something breaks
on a system (usually via an automatic yum update) I would kill
for the ability to run such queries.
* Ability to save a pristine copy for the configuration files
This would make it a _lot_ simpler to integrate the new .rpmnew
files, in a lot of cases being as simple as:
diff foo.pristine foo | patch -o foo foo.rpmnew
At the very least to provide some sort of mechanism that would
permit an external trigger to so easily and efficiently.
This maybe already implemented (never checked in depth the transaction
triggers), but a mechanism for external tools to hook into the
transactions would be great. More generally, the external triggers must
be given enough information about the current transaction to be able to
know the delta that the transaction introduces without having to scan
the entire state of the system. As a litmus test, you should be able to
implement the version control idea mentioned above via this mechanism
easily and efficiently.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
1:31 p.m.
On Fri, 27 Jul 2007, Dimi Paun wrote:
On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
> Or the other way around: what you always
> wished rpm would do for you? What always annoyed you out of your mind?
* Version control the meta-information
This can't be efficiently done outside RPM, and it would provide
an administrator with an invaluable tool (say a malfunction starts
at about 4am):
- what packages changes are different from yesterday?
- what files have changed for package foo between version V and W?
- what's the history of package foo on this system?
Not very difficult, but quite useful. Every time something breaks
on a system (usually via an automatic yum update) I would kill
for the ability to run such queries.
Ah, something fresh for a change :) Most of the things that have come up
in this thread, well lets just say I'd been very surprised if they hadn't
come up.
* Ability to save a pristine copy for the configuration files
This would make it a _lot_ simpler to integrate the new .rpmnew
files, in a lot of cases being as simple as:
diff foo.pristine foo | patch -o foo foo.rpmnew
At the very least to provide some sort of mechanism that would
permit an external trigger to so easily and efficiently.
This maybe already implemented (never checked in depth the transaction
triggers), but a mechanism for external tools to hook into the
transactions would be great. More generally, the external triggers must
be given enough information about the current transaction to be able to
know the delta that the transaction introduces without having to scan
the entire state of the system. As a litmus test, you should be able to
implement the version control idea mentioned above via this mechanism
easily and efficiently.
I've been thinking of somewhat different use case, but one of my plans is
to indeed make information about the current transaction available to
(lua-)scripts. I already have written beginnings of lua-rpm bindings, once
that's in usable shape and integrated, scripts could look at current
transaction member packages, their files etc and do decisions based on
that info.
- Panu -
5:57 p.m.
On Sat, 2007-07-28 at 21:31 +0300, Panu Matilainen wrote:
> * Version control the meta-information
[...]
Ah, something fresh for a change :) Most of the things that have come
up
in this thread, well lets just say I'd been very surprised if they hadn't
come up.
Great, since I got no reaction to this idea, I thought maybe I was out
to lunch :) Apart from being fresh, do you think it's worth it?
Would you consider it for inclusion? Do you think it would be hard
to do?
I've been thinking of somewhat different use case, but one of my
plans is
to indeed make information about the current transaction available to
(lua-)scripts. I already have written beginnings of lua-rpm bindings, once
that's in usable shape and integrated, scripts could look at current
transaction member packages, their files etc and do decisions based on
that info.
I'd be interested in seeing the interface when you have it available.
If it could support the features I proposed, I'd still be happy (even
though I really think they should be base features in rpm(1) instead
of extension scripts, so that people can rely on them everywhere).
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
11:14 a.m.
On Sat, 2007-07-28 at 21:31 +0300, Panu Matilainen wrote:
On Fri, 27 Jul 2007, Dimi Paun wrote:
> On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
>> Or the other way around: what you always
>> wished rpm would do for you? What always annoyed you out of your mind?
>
> * Version control the meta-information
> This can't be efficiently done outside RPM, and it would provide
> an administrator with an invaluable tool (say a malfunction starts
> at about 4am):
> - what packages changes are different from yesterday?
> - what files have changed for package foo between version V and W?
> - what's the history of package foo on this system?
> Not very difficult, but quite useful. Every time something breaks
> on a system (usually via an automatic yum update) I would kill
> for the ability to run such queries.
Ah, something fresh for a change :) Most of the things that have come up
in this thread, well lets just say I'd been very surprised if they hadn't
come up.
I know I'm a bit late to the party here but let me second (read: "+1")
this idea. Having historical rpmdb info would be a huge boon for testing
as well as sysadmins: being able to show exactly which packages changed
(and when) would make it easier to implement all kinds of things.
Example use case: Over the course of a week, Jake installs 25 new
packages. He starts up foo-client and it crashes - but it worked when he
started it last week! Jake wants to get a list of packages that were
updated in the past week and try rolling some of them back to their
previous versions.
Yeah, being able to have a "packages installed/updated in the last N
days" dialog, with "revert this change" buttons (and love/hate/add
comment for testing purposes etc.) would be completely awesome.
-w
12:11 p.m.
On Thu, 2007-08-02 at 12:14 -0400, Will Woods wrote:
On Sat, 2007-07-28 at 21:31 +0300, Panu Matilainen wrote:
> On Fri, 27 Jul 2007, Dimi Paun wrote:
>
> > On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
> >> Or the other way around: what you always
> >> wished rpm would do for you? What always annoyed you out of your mind?
> >
> > * Version control the meta-information
> > This can't be efficiently done outside RPM, and it would provide
> > an administrator with an invaluable tool (say a malfunction starts
> > at about 4am):
> > - what packages changes are different from yesterday?
> > - what files have changed for package foo between version V and W?
> > - what's the history of package foo on this system?
> > Not very difficult, but quite useful. Every time something breaks
> > on a system (usually via an automatic yum update) I would kill
> > for the ability to run such queries.
>
> Ah, something fresh for a change :) Most of the things that have come up
> in this thread, well lets just say I'd been very surprised if they hadn't
> come up.
I know I'm a bit late to the party here but let me second (read: "+1")
this idea. Having historical rpmdb info would be a huge boon for testing
as well as sysadmins: being able to show exactly which packages changed
(and when) would make it easier to implement all kinds of things.
Example use case: Over the course of a week, Jake installs 25 new
packages. He starts up foo-client and it crashes - but it worked when he
started it last week! Jake wants to get a list of packages that were
updated in the past week and try rolling some of them back to their
previous versions.
Yeah, being able to have a "packages installed/updated in the last N
days" dialog, with "revert this change" buttons (and love/hate/add
comment for testing purposes etc.) would be completely awesome.
AFAIK there's no good way to get at this direct from a host's local
data: we have e.g. /var/log/yum.log, but it only records the changes
made via yum; it seems to me like the place for this to live is inside
the rpmdb itself.
There's plenty of complexity in the details here, of course, like
rotating out the logs to stop filling up the disk, etc etc.
The biggest issue: what to store? one approach might be timestamped
triples of sets of (ENVR, checksum) for packages
installed/uninstalled/upgraded, so you'd do things like this:
rpm -qa --date=2007-04-01
(get list of packages installed at the given time/date; how to express
dates/times?)
rpm -q --changed --from-date=2007-04-01 --to-date=2007-04-31
(get list of packages installed, uninstalled, changed E-V-R within the
date ranges)
rpm -q --changes
(get list of transactions, handwaving away issues of formatting...)
rpm -q --changes --from-date=2007-04-01 --to-date=2007-04-31
(get list of transactions within the date ranges)
rpm -q --changes --from-date=2007-04-01 --to-date=2007-04-31 glibc
(get list of transactions within the date ranges that affected glibc)
rpm -qf --changes --from-date=2007-04-01 --to-date=2007-04-31 /usr/bin/foo
(get list of transactions affecting the specified file; but this isn't
implementable without storing a much larger amount of data, and similar
for other such queries e.g.
rpm -q --what-provides --changes --from-date=2007-04-01 --to-date=2007-04-31
some-requirement
[snip]
Hope this helps
Dave
12:44 p.m.
David Malcolm wrote:
> Example use case: Over the course of a week, Jake installs 25
new
> packages. He starts up foo-client and it crashes - but it worked when he
> started it last week! Jake wants to get a list of packages that were
> updated in the past week and try rolling some of them back to their
> previous versions.
>
> Yeah, being able to have a "packages installed/updated in the last N
> days" dialog, with "revert this change" buttons (and love/hate/add
> comment for testing purposes etc.) would be completely awesome.
>
AFAIK there's no good way to get at this direct from a host's local
data: we have e.g. /var/log/yum.log, but it only records the changes
made via yum; it seems to me like the place for this to live is inside
the rpmdb itself.
As long as you are proposing wild changes changes here, why not consider
(optionally) using a real version control system to manage the list of
installed package versions, preferably with the option to use a network
server with many machines appearing as branches. Then you'd commit your
list (and leave it to the version control system to store the
differences efficiently) at any state you might want to recover. You'd
still have to deal with doing everything in the right order to survive a
re-install of some arbitrary number of old packages but you'd always
be able to find what those packages were and you'd have all the VC tools
to view the differences between any points in time - or different
machines if you go the branching route. The bit of magic that falls out
of this scheme is that you'd not only be able to fix a still
sort-of-working machine (as anything relying on the rpm db files could)
but you could reproduce the installation on a different machine or
reconstruct it to an earlier state after a complete meltdown. Of course
having gone this far, I'd want a scheme to also version-control the
local changes to each machine's config files with the same mechanism so
the same tool would show both the installed package differences and the
config differences between any points in time or different machines.
--
Les Mikesell
lesmikesell(a)gmail.com
8:22 a.m.
On Fri, July 27, 2007 7:40 am, Panu Matilainen wrote:
Not everybody is on rpm-maint list and we'd like to hear the
wishes of
(Fedora) developers/packagers too. So: what have you always wanted to do
with rpm, but wasn't able to? Or the other way around: what you always
wished rpm would do for you? What always annoyed you out of your mind?
I would like to be able to specify in what order Requires get installed in.
8:29 a.m.
On Fri, July 27, 2007 8:29 am, Ralf Ertzinger wrote:
I'd argue that if you have to specify that in order for the
install to
work then your requires are wrong.
I would agree. But with corporations providing RPM's in which you do not
have the sources for or .spec files for you cannot always fix them.
8:23 a.m.
On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
Not everybody is on rpm-maint list and we'd like to hear the
wishes of
(Fedora) developers/packagers too. So: what have you always wanted to do
with rpm, but wasn't able to? Or the other way around: what you always
wished rpm would do for you? What always annoyed you out of your mind?
A working %posttrans or equivalent.
9:29 a.m.
Matthias Clasen wrote:
On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
> Not everybody is on rpm-maint list and we'd like to hear the wishes of
> (Fedora) developers/packagers too. So: what have you always wanted to do
> with rpm, but wasn't able to? Or the other way around: what you always
> wished rpm would do for you? What always annoyed you out of your mind?
A working %posttrans or equivalent.
%posttrans works now afaik. Is there something you want that isn't there
now?
-- Rex
9:54 a.m.
Bill Nottingham wrote:
Bill Nottingham (notting(a)redhat.com) said:
> > %posttrans works now afaik. Is there something you want that isn't
> > there now?
>
> Ideally, merging of identical %posttrans.
... and, running on uninstall as well.
Ah, that *is* a problem. Yes, please. :)
-- Rex
2:04 p.m.
On Fri, 27 Jul 2007, Bill Nottingham wrote:
Bill Nottingham (notting(a)redhat.com) said:
>> %posttrans works now afaik. Is there something you want that isn't there
>> now?
>
> Ideally, merging of identical %posttrans.
... and, running on uninstall as well.
Rather than trying to figure identical %posttrans between packages, I'd
like to see a mechanism to allow packages flagging things like "after
install/removal I need a) ldconfig run b) icon cache updated" and
have them run centrally after everything else has completed (lets call it
"%sysposttrans" that gets run after any non-empty transaction has fully
completed). Basically what was discussed in this thread:
https://www.redhat.com/archives/fedora-maintainers/2007-July/msg00061.html
I remember when some years ago something like
[ -x /usr/bin/update-foo ] && /usr/bin/update-foo
was copy-pasted into dozens of packages, only there was a typo that caused
every such scriptlet breaking and needed another mass rebuild to fix. If
it had been just a flag to do "update-foo" then the actual update-foo
script could've been fixed just once instead of having to copy-paste it
into every bleeping package and ran several times during a transaction.
Obviously packages have their special needs and not everything can be
generalized, but there are plenty enough things where this would be
applicaple.
- Panu -
10:48 a.m.
On Sat, 2007-07-28 at 22:04 +0300, Panu Matilainen wrote:
On Fri, 27 Jul 2007, Bill Nottingham wrote:
> Bill Nottingham (notting(a)redhat.com) said:
>>> %posttrans works now afaik. Is there something you want that isn't
there
>>> now?
>>
>> Ideally, merging of identical %posttrans.
>
> ... and, running on uninstall as well.
Rather than trying to figure identical %posttrans between packages, I'd
like to see a mechanism to allow packages flagging things like "after
install/removal I need a) ldconfig run b) icon cache updated" and
have them run centrally after everything else has completed (lets call it
"%sysposttrans" that gets run after any non-empty transaction has fully
completed). Basically what was discussed in this thread:
https://www.redhat.com/archives/fedora-maintainers/2007-July/msg00061.html
I remember when some years ago something like
[ -x /usr/bin/update-foo ] && /usr/bin/update-foo
was copy-pasted into dozens of packages, only there was a typo that caused
every such scriptlet breaking and needed another mass rebuild to fix. If
it had been just a flag to do "update-foo" then the actual update-foo
script could've been fixed just once instead of having to copy-paste it
into every bleeping package and ran several times during a transaction.
Obviously packages have their special needs and not everything can be
generalized, but there are plenty enough things where this would be
applicaple.
- Panu -
/+1.
icon cache, ldconfig, depmod, etc are common things.
No need to copy-paste the same code over and over and over.... and over
again.
- Gilboa
9:32 a.m.
On Fri, 2007-07-27 at 09:29 -0500, Rex Dieter wrote:
Matthias Clasen wrote:
>
> On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
>
>> Not everybody is on rpm-maint list and we'd like to hear the wishes of
>> (Fedora) developers/packagers too. So: what have you always wanted to do
>> with rpm, but wasn't able to? Or the other way around: what you always
>> wished rpm would do for you? What always annoyed you out of your mind?
>
> A working %posttrans or equivalent.
%posttrans works now afaik. Is there something you want that isn't there
now?
Oh ? That wasn't communicated to me. Whenever I ask about %posttrans I
hear that one shouldn't use it, because it doesn't work. If it is fixed
now, than maybe the packaging committee should look at coming up with
recommendations for icon cache handling (and similar things) using it.
9:33 a.m.
On Fri, 2007-07-27 at 09:29 -0500, Rex Dieter wrote:
Matthias Clasen wrote:
> On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
>> Not everybody is on rpm-maint list and we'd like to hear the wishes of
>> (Fedora) developers/packagers too. So: what have you always wanted to do
>> with rpm, but wasn't able to? Or the other way around: what you always
>> wished rpm would do for you? What always annoyed you out of your mind?
>
> A working %posttrans or equivalent.
%posttrans works now afaik. Is there something you want that isn't there
now?
%posttrans is really a bit of a short-term fix and fundamentally not
changing anything. We need to get to where we're doing a lot of small
transactions rather than one so that things like power failures aren't
catastrophic. At which point, the value of %posttrans over %post starts
to become far far lower.
Jeremy
9:45 a.m.
On Fri, 2007-07-27 at 10:33 -0400, Jeremy Katz wrote:
On Fri, 2007-07-27 at 09:29 -0500, Rex Dieter wrote:
> Matthias Clasen wrote:
> > On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
> >> Not everybody is on rpm-maint list and we'd like to hear the wishes of
> >> (Fedora) developers/packagers too. So: what have you always wanted to do
> >> with rpm, but wasn't able to? Or the other way around: what you always
> >> wished rpm would do for you? What always annoyed you out of your mind?
> >
> > A working %posttrans or equivalent.
>
> %posttrans works now afaik. Is there something you want that isn't there
> now?
%posttrans is really a bit of a short-term fix and fundamentally not
changing anything. We need to get to where we're doing a lot of small
transactions rather than one so that things like power failures aren't
catastrophic. At which point, the value of %posttrans over %post starts
to become far far lower.
The other approach for handling the power failure problem is the
Stateless cached client:
http://fedoraproject.org/wiki/StatelessLinuxCachedClient
11:05 a.m.
On Fri, 2007-07-27 at 10:33 -0400, Jeremy Katz wrote:
We need to get to where we're doing a lot of small
transactions rather than one so that things like power failures aren't
catastrophic.
That would be a step backwards in all but the power-failure scenario.
Conceptually, the transactional part of rpm is is a good thing. Now
I know we're nowhere close to ACID, but maybe we can improve on that
instead of making it even worse.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
11:09 a.m.
On Fri, 2007-07-27 at 12:05 -0400, Dimi Paun wrote:
On Fri, 2007-07-27 at 10:33 -0400, Jeremy Katz wrote:
> We need to get to where we're doing a lot of small
> transactions rather than one so that things like power failures aren't
> catastrophic.
That would be a step backwards in all but the power-failure scenario.
Conceptually, the transactional part of rpm is is a good thing. Now
I know we're nowhere close to ACID, but maybe we can improve on that
instead of making it even worse.
Well, it would also be good if we could get a bit more state on where we
are in the transaction and record that somewhere as much as possible.
It'd be nice to know that if we're past stage X that bits are on disk
and we just need metadata, or somesuch.
a bit finer granularity and instrumentation at the stages a pkg goes
through during a transaction would be helpful to verifying our state.
-sv
1:42 p.m.
On Fri, 2007-07-27 at 12:05 -0400, Dimi Paun wrote:
On Fri, 2007-07-27 at 10:33 -0400, Jeremy Katz wrote:
> We need to get to where we're doing a lot of small
> transactions rather than one so that things like power failures aren't
> catastrophic.
That would be a step backwards in all but the power-failure scenario.
Conceptually, the transactional part of rpm is is a good thing. Now
I know we're nowhere close to ACID, but maybe we can improve on that
instead of making it even worse.
The problem is that you need transactions not for the RPM database
but for the *system*; if you are installing 20 packages, and the
first package install overwrites some file, then something fails
as we are running the %post for the 15th package, can we go back and
restore that file we overwrote to it's original state?
To even start at being able to do that, I think you have to have
separate filesystem for the system image that is read-only except
for RPM operations.
(Yes, RPM could save the files it overwrites in a undo buffer, but
you also have system changes done by scripts.)
- Owen
2:58 p.m.
On Fri, 2007-07-27 at 14:42 -0400, Owen Taylor wrote:
The problem is that you need transactions not for the RPM database
but for the *system*;
I understand that, it's not a trivial feature.
To even start at being able to do that, I think you have to have
separate filesystem for the system image that is read-only except
for RPM operations.
Working with LVM here provides part of the answer.
We'll probably need some more support from LVM if
we are to achieve system-level ACIDity,
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
8:55 a.m.
Panu Matilainen (pmatilai(a)redhat.com) said:
* Improving automatic dependency extraction
- Plugin architecture for internal dependency extractor to avoid having
to patch rpm itself for each new language
Filtering of the provides/requires without disabling the internal
dependency generator. (Or, making it external again to simplify this.)
Bill
9:06 a.m.
On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
Hey all,
I know I'm opening up Pandoras box here but what the heck, it's Friday and
I'm feeling slightly bored...
With RPM 4.4.2.1 fresh out and 4.4.x branched off to maintenance mode,
time to start looking forward to next major release. While the focus will
be largely in cleaning up and streamlining the codebase, it can't
realistically be all about just that.
1. expose the rpm verify interface to the python bindings. All we really
need is a fast way of getting out the current file status on disk. We
could do it all in native python but since rpm already has some of the
code to do it..
2. make it so when I open an rpm from a file I do not need the rpmdb and
a transaction set to be open. This also means disconnecting the gpgkeys
from the rpmdb, I think.
3. more of what you said - get rid of all the pieces that we don't
actually need.
-sv
9:08 a.m.
On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
Hey all,
I know I'm opening up Pandoras box here but what the heck, it's Friday and
I'm feeling slightly bored...
With RPM 4.4.2.1 fresh out and 4.4.x branched off to maintenance mode,
time to start looking forward to next major release. While the focus will
be largely in cleaning up and streamlining the codebase, it can't
realistically be all about just that.
Not everybody is on rpm-maint list and we'd like to hear the wishes of
(Fedora) developers/packagers too. So: what have you always wanted to do
with rpm, but wasn't able to? Or the other way around: what you always
wished rpm would do for you? What always annoyed you out of your mind?
Just to kick off the discussion (like it was necessary, this is rpm
afterall...), here are a few things that have been brought up in various
forums and private discussions, but don't feel constrained by these items,
they're just some examples of what's being considered:
A few of the bugs on
https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=multilib
are assigned to to RPM. The most important one is probably the lack of
arch-specific Requires: and BuildRequires: (#235755).
I don't think we'll manage #235757 in time for Fedora 8 but it would be
good to get it done (and the packages updated accordingly) for Fedora 9.
(Note that comments 3-19 are about the short-term hack we did for F7,
not the real subject of the bug).
Thoughts on #235758 would be appreciated.
--
dwmw2
6:49 a.m.
David Woodhouse wrote:
A few of the bugs on
https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=multilib
are assigned to to RPM. The most important one is probably the lack of
arch-specific Requires: and BuildRequires: (#235755).
I don't think we'll manage #235757 in time for Fedora 8 but it would be
good to get it done (and the packages updated accordingly) for Fedora 9.
(Note that comments 3-19 are about the short-term hack we did for F7,
not the real subject of the bug).
Thoughts on #235758 would be appreciated.
Obsoletes aren't arch specific too, which is a real pain:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246598
--
http://jeremysanders.net/
5:55 a.m.
On Mon, 2007-07-30 at 12:49 +0100, Jeremy Sanders wrote:
David Woodhouse wrote:
> A few of the bugs on
> https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=multilib
> are assigned to to RPM. The most important one is probably the lack of
> arch-specific Requires: and BuildRequires: (#235755).
>
> I don't think we'll manage #235757 in time for Fedora 8 but it would be
> good to get it done (and the packages updated accordingly) for Fedora 9.
> (Note that comments 3-19 are about the short-term hack we did for F7,
> not the real subject of the bug).
>
> Thoughts on #235758 would be appreciated.
Obsoletes aren't arch specific too, which is a real pain:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246598
That could be considered to be just another manifestation of bug 235756.
The problem is not necessarily the fact that the Obsoletes: wasn't
arch-specific. It's that yum went from 'please install digikam to get
rid of digikamimageplugins' to 'hey, let's install both the sensible
x86_64 version _and_ the unwanted i386 version too'.
--
dwmw2
9:43 p.m.
On Tue, Jul 31, 2007 at 11:55:50AM +0100, David Woodhouse wrote:
The problem is not necessarily the fact that the Obsoletes:
wasn't
arch-specific. It's that yum went from 'please install digikam to get
rid of digikamimageplugins' to 'hey, let's install both the sensible
x86_64 version _and_ the unwanted i386 version too'.
Take a look at the new "basearchonly" plugin in yum-utils (or rather, in the
next release of yum-utils). It could use a little work, and eventually I
hope it will be completely unnecessary, but until then, that's what plugins
are *for*.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
9:36 a.m.
On Fri, Jul 27, 2007 at 15:40:40 +0300,
Panu Matilainen <pmatilai(a)redhat.com> wrote:
Not everybody is on rpm-maint list and we'd like to hear the wishes of
(Fedora) developers/packagers too. So: what have you always wanted to do
with rpm, but wasn't able to? Or the other way around: what you always
wished rpm would do for you? What always annoyed you out of your mind?
Since I have switched to using yum with local repostories the following haven't
really been a problem, but since you asked and they bugged me in the past
I thought I'd mention them.
Until the kernel gets changed to allow larger command lines (which might
be pretty soon) it would be nice if rpm had a way to read in the list of
files to process via standard input or a file. I used to have problems
doing rpm -Fvh *.rpm when the number of rpms got to be very large. xargs
won't work because much of the time several updates need to be done at
the same time.
9:37 a.m.
On Fri, 2007-07-27 at 09:36 -0500, Bruno Wolff III wrote:
Until the kernel gets changed to allow larger command lines (which
might
be pretty soon) it would be nice if rpm had a way to read in the list of
files to process via standard input or a file. I used to have problems
doing rpm -Fvh *.rpm when the number of rpms got to be very large. xargs
won't work because much of the time several updates need to be done at
the same time.
IIRC, a file listing paths to packages should just work already.
Jeremy
10:09 a.m.
On Fri, Jul 27, 2007 at 10:37:43 -0400,
Jeremy Katz <katzj(a)redhat.com> wrote:
On Fri, 2007-07-27 at 09:36 -0500, Bruno Wolff III wrote:
> Until the kernel gets changed to allow larger command lines (which might
> be pretty soon) it would be nice if rpm had a way to read in the list of
> files to process via standard input or a file. I used to have problems
> doing rpm -Fvh *.rpm when the number of rpms got to be very large. xargs
> won't work because much of the time several updates need to be done at
> the same time.
IIRC, a file listing paths to packages should just work already.
Do you know what option is used for that? I don't see a way to do that
described in the man page. (In particular the -f option is not for a file
with a list of rpm names, bhut rather the package(s) that own a particular
file.)
10:26 a.m.
On Fri, 2007-07-27 at 10:09 -0500, Bruno Wolff III wrote:
On Fri, Jul 27, 2007 at 10:37:43 -0400,
Jeremy Katz <katzj(a)redhat.com> wrote:
> On Fri, 2007-07-27 at 09:36 -0500, Bruno Wolff III wrote:
> > Until the kernel gets changed to allow larger command lines (which might
> > be pretty soon) it would be nice if rpm had a way to read in the list of
> > files to process via standard input or a file. I used to have problems
> > doing rpm -Fvh *.rpm when the number of rpms got to be very large. xargs
> > won't work because much of the time several updates need to be done at
> > the same time.
>
> IIRC, a file listing paths to packages should just work already.
Do you know what option is used for that? I don't see a way to do that
described in the man page. (In particular the -f option is not for a file
with a list of rpm names, bhut rather the package(s) that own a particular
file.)
Just give the manifest file in place of where you'd give teh list of rpm
names
Jeremy
10:41 a.m.
On Fri, Jul 27, 2007 at 11:26:14 -0400,
Jeremy Katz <katzj(a)redhat.com> wrote:
On Fri, 2007-07-27 at 10:09 -0500, Bruno Wolff III wrote:
> On Fri, Jul 27, 2007 at 10:37:43 -0400,
> Jeremy Katz <katzj(a)redhat.com> wrote:
> > On Fri, 2007-07-27 at 09:36 -0500, Bruno Wolff III wrote:
> > > Until the kernel gets changed to allow larger command lines (which might
> > > be pretty soon) it would be nice if rpm had a way to read in the list of
> > > files to process via standard input or a file. I used to have problems
> > > doing rpm -Fvh *.rpm when the number of rpms got to be very large. xargs
> > > won't work because much of the time several updates need to be done
at
> > > the same time.
> >
> > IIRC, a file listing paths to packages should just work already.
>
> Do you know what option is used for that? I don't see a way to do that
> described in the man page. (In particular the -f option is not for a file
> with a list of rpm names, bhut rather the package(s) that own a particular
> file.)
Just give the manifest file in place of where you'd give teh list of rpm
names
OK. Is that info in the man page? I tried looking again for something that
said you could do that and didn't see anything. If it isn't there then a bug
should get filed, but maybe I am just missing it?
11:11 a.m.
On 27/07/07, Bruno Wolff III <bruno(a)wolff.to> wrote:
OK. Is that info in the man page? I tried looking again for something
that
said you could do that and didn't see anything. If it isn't there then a bug
should get filed, but maybe I am just missing it?
Yeah, just search for "manifest" ... :) it's not that intuitive, but
it's there.
11:25 a.m.
On Fri, Jul 27, 2007 at 17:11:52 +0100,
Bill Crawford <billcrawford1970(a)gmail.com> wrote:
On 27/07/07, Bruno Wolff III <bruno(a)wolff.to> wrote:
> OK. Is that info in the man page? I tried looking again for something that
> said you could do that and didn't see anything. If it isn't there then a
bug
> should get filed, but maybe I am just missing it?
Yeah, just search for "manifest" ... :) it's not that intuitive, but
it's there.
Thanks, I found it now. I think I just never finished that paragraph.
10:29 a.m.
On 27/07/07, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Fri, Jul 27, 2007 at 10:37:43 -0400,
Jeremy Katz <katzj(a)redhat.com> wrote:
[...]
> IIRC, a file listing paths to packages should just work
already.
Do you know what option is used for that? I don't see a way to do that
described in the man page. (In particular the -f option is not for a file
with a list of rpm names, bhut rather the package(s) that own a particular
file.)
There is no option, you just pass it a text file listing the paths to
the packages as though it were a package.
10:16 a.m.
2007/7/27, Panu Matilainen <pmatilai(a)redhat.com>:
Not everybody is on rpm-maint list and we'd like to hear the
wishes of
(Fedora) developers/packagers too. So: what have you always wanted to do
with rpm, but wasn't able to? Or the other way around: what you always
wished rpm would do for you? What always annoyed you out of your mind?
Hi!
I was wondering if rpm can register aliases when it bundles external
kernel module (*.ko) like this iwl3945, so it can tell which module
(external, in it's own rpm / or internally from the kernel) is a
candidate for some specific hardware...
Maybe if it can tell more deeply, see that the module is requesting a
specific firmware as a dependency (and versionned firmwares is what
should be set as as rule, probably not only for intel firmwares ?!)
This would be a feature that beginners would appreciate!
Nicolas (kwizart)
-----------
[root@Kwizatz SOURCES]# modinfo iwl3945
filename:
/lib/modules/2.6.22.1-29.fc6/kernel/drivers/net/wireless/mac80211/iwlwifi/iwl3945.ko
license: GPL
author: Copyright(c) 2003-2007 Intel Corporation
version: 0.0.25kd
description: Intel(R) PRO/Wireless 3945ABG/BG Network Connection
driver for Linux
srcversion: C0D2ED4CF92440B1DFE3BCB
This -> alias: pci:v00008086d00004227sv*sd*bc*sc*i*
This -> alias: pci:v00008086d00004222sv*sd*bc*sc*i*
depends: mac80211
vermagic: 2.6.22.1-29.fc6 SMP mod_unload
parm: antenna:select antenna (1=Main, 2=Aux, default 0 [both]) (int)
parm: disable:manually disable the radio (default 0 [radio on]) (int)
parm: hwcrypto:using hardware crypto engine (default 0 [software])
(int)
parm: debug:debug output mask (int)
parm: disable_hw_scan:disable hardware scanning (default 0) (int)
parm: qos_enable:enable all QoS functionality (int)
parm: mode:network mode (0=BSS,1=IBSS,2=Monitor) (int)
----------------
10:27 a.m.
On Fri, 2007-07-27 at 17:16 +0200, KH KH wrote:
2007/7/27, Panu Matilainen <pmatilai(a)redhat.com>:
> Not everybody is on rpm-maint list and we'd like to hear the wishes of
> (Fedora) developers/packagers too. So: what have you always wanted to do
> with rpm, but wasn't able to? Or the other way around: what you always
> wished rpm would do for you? What always annoyed you out of your mind?
I was wondering if rpm can register aliases when it bundles external
kernel module (*.ko) like this iwl3945, so it can tell which module
(external, in it's own rpm / or internally from the kernel) is a
candidate for some specific hardware...
There's nothing that stops us from adding something to auto-add provides
based on modalias. The "problem" is mostly that it ends up adding a
substantial number of provides which bloats the amount of data that has
to be looked at, downloaded, etc
Maybe if it can tell more deeply, see that the module is requesting
a
specific firmware as a dependency (and versionned firmwares is what
should be set as as rule, probably not only for intel firmwares ?!)
This would be a feature that beginners would appreciate!
And similarly, firmware info can be extracted as long as the modules
export it. The MODULE_FIRMWARE stuff should help there as it gets used
in more modules
Jeremy
11:20 a.m.
On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
Not everybody is on rpm-maint list and we'd like to hear the
wishes of
(Fedora) developers/packagers too. So: what have you always wanted to do
with rpm, but wasn't able to? Or the other way around: what you always
wished rpm would do for you? What always annoyed you out of your mind?
Another thing I forgot: I'd love if rpm could become smart enough in
handling directories, so that we don't need to add tons of artifical
dependencies just to manually manage directory ownership.
11:42 a.m.
On Fri, 27 Jul 2007 15:40:40 +0300 (EEST)
Panu Matilainen <pmatilai(a)redhat.com> wrote:
Not everybody is on rpm-maint list and we'd like to hear the
wishes
of (Fedora) developers/packagers too. So: what have you always wanted
to do with rpm, but wasn't able to? Or the other way around: what you
always wished rpm would do for you? What always annoyed you out of
your mind?
directory -> symlink upon upgrade, and all the sort of similar fun.
--
Jesse Keating
Release Engineer: Fedora
12:55 p.m.
Evening folks,
On Fri, 27 Jul 2007, Panu Matilainen wrote:
I know I'm opening up Pandoras box here but what the heck,
it's Friday and
I'm feeling slightly bored...
looks like you've the wrong job...maybe we should switch ;-)
The more specific you can be, the better - "make it not
suck" isn't
productive. Of course there's no way everything can be done, we want the
next major release out before end of the decade... Also this is not a
voting where most votes guarantee implementation, but consider it your
chance to be heard. I'm listening... :)
when reading your ideas or how ever you're calling it, it looks as you
would like to come up with the same roadmap rpm5.org already has - but just
nearly two month later. And when reading rpm5-devel from the last two
month, you're proposing more or less the same ideas, the rpm5 team and
developers already talked about; read yourself:
- http://rpm5.org/roadmap/
- http://rpm5.org/community/rpm-devel/
But I've also one wish regarding the features of rpm.org: Let rpmrc die as
soon as possible, please. As you're also at the rpm5-devel mailing list,
you should know what I'm talking about here, don't you?
On Fri, 27 Jul 2007, dragoran wrote:
arch requires and provides ... to end the endless multilib
discussions ;)
should be automatic until the packager say Requires: foo.arch
IIRC this feature is already since beginning of May 2007 in rpm5.org, try
or e.g. look at http://rpm5.org/cvs/chngview?cn=7070.
On Fri, 27 Jul 2007, Till Maas wrote:
I am missing "soft dependencies", e.g. the possibility to
make a package
suggest which other packages may enhance it, e.g. with plugins. Afaik in
debian packages it is called "Suggests:".
AFAIK, this is part of rpm5.org since end of October 2005 as "Suggests:"
and "Enhances:", just read http://rpm5.org/cvs/chngview?cn=6089 and also
http://rpm5.org/cvs/chngview?cn=6111, PLD Linux wrote a patch to use these
features within yum, but yum upstream refuses this patch without a real
answer.
On Fri, 27 Jul 2007, Matthias Clasen wrote:
A working %posttrans or equivalent.
What is broken/not working at %posttrans?
On Fri, 27 Jul 2007, Matthias Clasen wrote:
Another thing I forgot: I'd love if rpm could become smart enough
in
handling directories, so that we don't need to add tons of artifical
dependencies just to manually manage directory ownership.
Hum? Could you give more details regarding this? Are you thinking about
auto-manage ownership of directories? I don't think, this is a good idea,
but rpm5.org is able to tell you orphaned parent directories and dangling
symlinks since April 2006. IIRC http://rpm5.org/cvs/chngview?cn=6412 or
http://rpm5.org/cvs/chngview?cn=6414.
On Fri, 27 Jul 2007, Jesse Keating wrote:
directory -> symlink upon upgrade, and all the sort of similar
fun.
I'm not sure, but I thought, this theme have been aten at rpm5.org.
My personal conclusion is, that as of the moment, many expected features
are already part of rpm5.org for a longer time. Oh, I forgot, some Red Hat
people don't like some rpm5.org team members</sarcasm>. But this are just
my 2 cents regarding this topic as rpm5.org member and Fedora user... ;-)
Greetings,
Robert
1:03 p.m.
On Fri, 2007-07-27 at 19:55 +0200, Robert Scheck wrote:
On Fri, 27 Jul 2007, Matthias Clasen wrote:
> A working %posttrans or equivalent.
What is broken/not working at %posttrans?
Read the posts further up in this thread explaining it.
On Fri, 27 Jul 2007, Matthias Clasen wrote:
> Another thing I forgot: I'd love if rpm could become smart enough in
> handling directories, so that we don't need to add tons of artifical
> dependencies just to manually manage directory ownership.
Hum? Could you give more details regarding this? Are you thinking about
auto-manage ownership of directories? I don't think, this is a good idea,
but rpm5.org is able to tell you orphaned parent directories and dangling
symlinks since April 2006. IIRC http://rpm5.org/cvs/chngview?cn=6412 or
http://rpm5.org/cvs/chngview?cn=6414.
I am talking about
- MUST: A package must own all directories that it creates. If it does
not create a directory that it uses, then it should require a package
which does create that directory. The exception to this are directories
listed explicitly in the Filesystem Hierarchy
I think it would be entirely possible for rpm to differentiate between
directories that
a) preexisted before any rpm touched them
b) were created because an rpm needs to dump a file there
c) are explicitly owned by an rpm
and manage the creation and deletion of directories accordingly.
Refcounting comes to mind...
4:35 p.m.
On Fri, 2007-07-27 at 14:03 -0400, Matthias Clasen wrote:
I think it would be entirely possible for rpm to differentiate
between
directories that
a) preexisted before any rpm touched them
b) were created because an rpm needs to dump a file there
c) are explicitly owned by an rpm
and manage the creation and deletion of directories accordingly.
Refcounting comes to mind...
Indeed, I would very much like to see rpm handle this correctly on its
own, so we can get rid of that guideline.
~spot
1:49 a.m.
On Fri, 27 Jul 2007, Robert Scheck wrote:
when reading your ideas or how ever you're calling it, it looks as you
would like to come up with the same roadmap rpm5.org already has - but just
nearly two month later. And when reading rpm5-devel from the last two
month, you're proposing more or less the same ideas, the rpm5 team and
developers already talked about; read yourself:
- http://rpm5.org/roadmap/
- http://rpm5.org/community/rpm-devel/
Yes, I'm reasonably well aware of what rpm5.org is doing. I dunno if
you've noticed but some (not all by any means) of the things happening
there have actually been triggered by rpm.org activities. Incidentally the
initial rpm.org roadmap was published two and a half months ago...
But I've also one wish regarding the features of rpm.org: Let
rpmrc die as
soon as possible, please. As you're also at the rpm5-devel mailing list,
you should know what I'm talking about here, don't you?
I haven't been following that particular discussion in any detail.
My personal conclusion is, that as of the moment, many expected
features
are already part of rpm5.org for a longer time. Oh, I forgot, some Red Hat
people don't like some rpm5.org team members</sarcasm>. But this are just
my 2 cents regarding this topic as rpm5.org member and Fedora user... ;-)
It's not exactly a big secret that rpm5.org has various fixes and
additions that make sense for rpm.org as well. There's a large amount of
shared code at the moment, and quite obviously a fair bit of common
interest areas as well between the two trees. So yes, code exchange does
happen between the trees, both ways, that's obvious to anybody who
looks at the changelogs. Still, it doesn't mean they share a common
roadmap, they actually differ quite a bit if you think about it.
- Panu -
1:12 p.m.
On 7/27/07, Panu Matilainen <pmatilai(a)redhat.com> wrote:
The more specific you can be, the better - "make it not
suck" isn't
productive. Of course there's no way everything can be done, we want the
next major release out before end of the decade... Also this is not a
voting where most votes guarantee implementation, but consider it your
chance to be heard. I'm listening... :)
If I had any ability to hack on rpm.....
Is there a way to make the rpmdb smart enough to make auto-removal of
package dependencies happen when all packages using that dep were
explicitly installed are no longer on the system.
Naively, I would think that you could mark individual packages as
explicitly installed or not in the rpmdb. So tools which interact
with the db could set that flag accordingly and such a demarcation
could be queried or used in transactions.
Examples yum install ekiga would flag ekiga but any deps pulled into
the transaction would not get flagged as explicit. yum install
libsexy would flag libsexy as explicit. The explicit mark in the db
would be used to protect marked packages from leaf vacuuming, so that
we can make common use of leaf vacuuming.
-jef"make it not not not suck!"spaleta
1:10 p.m.
On Fri, 2007-07-27 at 10:12 -0800, Jeff Spaleta wrote:
On 7/27/07, Panu Matilainen <pmatilai(a)redhat.com> wrote:
> The more specific you can be, the better - "make it not suck" isn't
> productive. Of course there's no way everything can be done, we want the
> next major release out before end of the decade... Also this is not a
> voting where most votes guarantee implementation, but consider it your
> chance to be heard. I'm listening... :)
If I had any ability to hack on rpm.....
Is there a way to make the rpmdb smart enough to make auto-removal of
package dependencies happen when all packages using that dep were
explicitly installed are no longer on the system.
Naively, I would think that you could mark individual packages as
explicitly installed or not in the rpmdb. So tools which interact
with the db could set that flag accordingly and such a demarcation
could be queried or used in transactions.
Examples yum install ekiga would flag ekiga but any deps pulled into
the transaction would not get flagged as explicit. yum install
libsexy would flag libsexy as explicit. The explicit mark in the db
would be used to protect marked packages from leaf vacuuming, so that
we can make common use of leaf vacuuming.
We've kicked around the idea of doing that in a separate db that yum
creates but it:
1. would mean that it ignores stuff not installed by yum
2. it would need to remain persistent across upgrades/etc
so, you're right doing it in rpm or having a way of labeling them in rpm
that way would make it easier.
-sv
1:26 p.m.
On 7/27/07, seth vidal <skvidal(a)linux.duke.edu> wrote:
so, you're right doing it in rpm or having a way of labeling them
in rpm
that way would make it easier.
..but is it worth doing in sane timescale? To make use of it you'd
also have to expose setting the flag to external transaction tools
like yum. And of course, some gross cmdline way to flag/unflag
packages manually for those of us who like stick our fingers into
power sockets.
-jef
1:21 p.m.
On Fri, 2007-07-27 at 10:26 -0800, Jeff Spaleta wrote:
On 7/27/07, seth vidal <skvidal(a)linux.duke.edu> wrote:
> so, you're right doing it in rpm or having a way of labeling them in rpm
> that way would make it easier.
..but is it worth doing in sane timescale? To make use of it you'd
also have to expose setting the flag to external transaction tools
like yum. And of course, some gross cmdline way to flag/unflag
packages manually for those of us who like stick our fingers into
power sockets.
given the other suggestions today on this and other lists I don't think
anyone is worried about timescale :)
-sv
1:42 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeff Spaleta wrote:
If I had any ability to hack on rpm.....
Is there a way to make the rpmdb smart enough to make auto-removal of
package dependencies happen when all packages using that dep were
explicitly installed are no longer on the system.
Couldn't this been done with reference counting, like is done with
garbage collection? It seems to me to be applicable, proven, and simple.
- --
Topher Fischer
GnuPG Fingerprint: 3597 1B8D C7A5 C5AF 2E19 EFF5 2FC3 BE99 D123 6674
javert42(a)cs.byu.edu | http://www.thetopher.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGqjx9L8O+mdEjZnQRAnSmAJ9V8OeNm7BFfP/0tuE9qosQ9fFP+gCbBuM0
CIWkvzweQbzcp1G0NGLrbRA=
=RSoz
-----END PGP SIGNATURE-----
2:19 p.m.
On 7/27/07, Topher <javert42(a)cs.byu.edu> wrote:
Couldn't this been done with reference counting, like is done
with
garbage collection? It seems to me to be applicable, proven, and simple.
Reference counting what exactly? Keeping up with the number of
dependencies on a package is not hard. In fact we already have tools
that find leaves in the tree. That's not the problem. The problem is
protecting leaves that users care about from auto-cleanup. If we just
vacuumed up leaf nodes in the packaging tree willy-nilly normal users
would see applications they care about depopulated from the menus.
Developers would see libraries and development packages they need
depopulated from their workstations. If we had a way to protect
certain leaves in the tree from auto-cleanup, then we avoid all of
these complications.
The only way we know if a user cares about a package is if it was
explicitly requested to be installed (or explicitly told the rpmdb to
protect that package from auto-cleanup if we want to get picky).
Right now the is no way to query rpmdb about whether a package was
installed explicitly or was implicitly included through depsolving.
That's the key idea here... marking the 10% or so of packages a
user/admin/trained-monkey has explicitly asked to be
installed/protected so that we can auto garbage collect we aren't
throwing out things we care about.
-jef
10:17 a.m.
Jeff Spaleta wrote:
On 7/27/07, Panu Matilainen <pmatilai(a)redhat.com> wrote:
> The more specific you can be, the better - "make it not suck" isn't
> productive. Of course there's no way everything can be done, we want the
> next major release out before end of the decade... Also this is not a
> voting where most votes guarantee implementation, but consider it your
> chance to be heard. I'm listening... :)
If I had any ability to hack on rpm.....
Is there a way to make the rpmdb smart enough to make auto-removal of
package dependencies happen when all packages using that dep were
explicitly installed are no longer on the system.
Naively, I would think that you could mark individual packages as
explicitly installed or not in the rpmdb. So tools which interact
with the db could set that flag accordingly and such a demarcation
could be queried or used in transactions.
There's a logic problem here -- how do you determine which packages are
marked which way on a fresh install? Marking them all as explicit means
you rarely remove anything. Marking them all implicit means the first
time you remove anything it destroys your system. There's no obvious
determining factor to use as middle ground, at least to me.
--
Peter
10:30 a.m.
>
> Naively, I would think that you could mark individual packages as
> explicitly installed or not in the rpmdb. So tools which interact
> with the db could set that flag accordingly and such a demarcation
> could be queried or used in transactions.
There's a logic problem here -- how do you determine which packages
are marked which way on a fresh install? Marking them all as explicit
means you rarely remove anything. Marking them all implicit means the
first time you remove anything it destroys your system. There's no
obvious determining factor to use as middle ground, at least to me.
Well, the basic installs are all supposed to propose an initial set of
selected services (a kernel, a basic running environment, OpenOffice,
editors, at least one desktop, a mailer, a browser, ....). The packages
corresponding to these services should be marked as explicit and all the
others implicit.
If this is difficult to achieve, then mark everything as explicit at
install time and this scheme will work essentially for user added
packages and their dependencies...
This still has quite some value. Believe me, the number of packages
installed just to solve dependencies is quite high once the user start
to ask for some addons.
10:59 a.m.
On Thursday 02 August 2007 17:17:50 Peter Jones wrote:
There's a logic problem here -- how do you determine which
packages are
marked which way on a fresh install? Marking them all as explicit means
You can use comps for this, everything that is enabled there or selected by
the user from comps entries can be marked explicit and all the dependecies
implicit.
Regards,
Till
11:28 a.m.
On 8/2/07, Peter Jones <pjones(a)redhat.com> wrote:
There's a logic problem here -- how do you determine which
packages are
marked which way on a fresh install? Marking them all as explicit means
you rarely remove anything. Marking them all implicit means the first
time you remove anything it destroys your system. There's no obvious
determining factor to use as middle ground, at least to me.
naively....
fresh installs.... assuming anaconda's current interface
if its got a checkbox by it... its explicit.
So if its a default item in a group and the group is select for
install its explicit
If its an option item that was explicit checked.. its explicit
Or looking at it another way, if the depsolver has to pull it in to
the transaction... its implicit.
Using this naive logic... with fresh installs break in significant
ways as packages are removed?
-jef
3:22 p.m.
Dnia 2007-07-27, o godz. 15:40:40 Panu Matilainen <pmatilai(a)redhat.com>
napisał(a):
what have you always wanted to do with rpm, but wasn't able to?
- Tell if a given package was installed by hand (rpm -i/U/F) or (if installed
by yum/apt/whatever) which repository did it come from. Some people suggested
to use "Signature:" for that, but that only tells, which repo this pakage was
first published on, and I want to know, where did I get it from in reality.
- Mark packages "immune", so that I don't have to separately set
ignore/keep
lists for every depsolver separately (I know, this is stupid, I should make my
fixes upstream, but that proved very hard with Fedora maintainers and you've
asked about my wishes for RPM...)
- Make the transaction journalled with some kind of redo log, so that it's
not a problem if some update crashes X, killing pirut/yum/rpm with it. Power
failures don't bother me, but crashes do happen upon updating the system, even
on Fedora :)
Lam
3:27 p.m.
On 7/27/07, Leszek Matok <Lam(a)lam.pl> wrote:
- Tell if a given package was installed by hand (rpm -i/U/F) or (if
installed
by yum/apt/whatever) which repository did it come from. Some people suggested
to use "Signature:" for that, but that only tells, which repo this pakage was
first published on, and I want to know, where did I get it from in reality.
Like the actual url it was pulled from, regardless of which mirror in
a dynamicly generated mirrorlist you used in that run? A
repository-wide signature/cert referenced in signed repository
metadata from the repository might be better in some ways than the
full url to a specific mirror.
-jef
8:45 p.m.
On 07/27/2007 11:27 PM, Jeff Spaleta wrote:
On 7/27/07, Leszek Matok <Lam(a)lam.pl> wrote:
> - Tell if a given package was installed by hand (rpm -i/U/F) or (if installed
> by yum/apt/whatever) which repository did it come from. Some people suggested
> to use "Signature:" for that, but that only tells, which repo this pakage
was
> first published on, and I want to know, where did I get it from in reality.
>
Like the actual url it was pulled from, regardless of which mirror in
a dynamicly generated mirrorlist you used in that run? A
repository-wide signature/cert referenced in signed repository
metadata from the repository might be better in some ways than the
full url to a specific mirror.
+1 for repository signature. Although the vendor tag
is close enough
that maybe this (coupled with the GPG key) could be used instead.
7:21 a.m.
On Fri, 27 Jul 2007, Jeff Spaleta wrote:
On 7/27/07, Leszek Matok <Lam(a)lam.pl> wrote:
> - Tell if a given package was installed by hand (rpm -i/U/F) or (if installed
> by yum/apt/whatever) which repository did it come from. Some people suggested
> to use "Signature:" for that, but that only tells, which repo this pakage
was
> first published on, and I want to know, where did I get it from in reality.
Like the actual url it was pulled from, regardless of which mirror in
a dynamicly generated mirrorlist you used in that run? A
repository-wide signature/cert referenced in signed repository
metadata from the repository might be better in some ways than the
full url to a specific mirror.
Repository signatures would have their uses, but that doesn't really work
on rpm level. You could have downloaded manually and rpm -Uvh'd into the
system, there's no trace of the package origins anywhere then. Except the
package signature which is already recorded in rpmdb.
In other words, I think the package signature is the best indicator of
package origins you can realistically get.
Making the already existing information more easily accessible and usable
is another topic :)
- Panu -
6:33 p.m.
On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
Not everybody is on rpm-maint list and we'd like to hear the
wishes of
(Fedora) developers/packagers too. So: what have you always wanted to do
with rpm, but wasn't able to? Or the other way around: what you always
wished rpm would do for you? What always annoyed you out of your mind?
I don't know if this can be done now, or if at all, and I am not a
developer or even really a packager, so this may be something way out in
left field.
BUT, upon saying all that, is there a way to create, make, or use some
sort of restore point, to get rpm back in shape if a library or
something gets out of wack? Maybe a rpm --backup option that can be
used to backup rpm at a certain point. Then somehow it can be brought
back to that state, even if it's a tar'd file, gzipped or whatever?
Reason to have it that way is due to rpm not being functional or allowed
to do anything because some library or whatever got screwed up, and you
have to reinstall the OS instead of just a quick restore.
Ok, ugh, as I got back and read what I wrote, it sounds stupid haha.
But I guess what I am trying to say, is when the rpm db or whatever
(like a library file that makes rpm unusable at all) gets borked, is
there a state that rpm can be in, or whatever, to get it back to a
working state at least until you can have rpm figure out what packages
are installed again and up to par? Maybe I am asking this in the wrong
way? I know other users have had these problems before but never really
saw a way to fix it, cept for when rpm can be used to rebuild the db,
but in this case, you can't even do that.
LOL I'll go sit in the corner and shutup, eat a chip and watch the
show :P
--
Mike Chambers
Madisonville, KY
"Best little town on Earth!"
8:41 p.m.
On 7/27/07, Mike Chambers <mike(a)miketc.com> wrote:
On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
> Not everybody is on rpm-maint list and we'd like to hear the wishes of
> (Fedora) developers/packagers too. So: what have you always wanted to do
> with rpm, but wasn't able to? Or the other way around: what you always
> wished rpm would do for you? What always annoyed you out of your mind?
I don't know if this can be done now, or if at all, and I am not a
developer or even really a packager, so this may be something way out in
left field.
BUT, upon saying all that, is there a way to create, make, or use some
sort of restore point, to get rpm back in shape if a library or
something gets out of wack?
I'm wonder if rpm could rpm -e back to a certain point, then rpm -i
--force all lib packages
--
Fedora Core 6 and proud
8:48 p.m.
On 07/28/2007 04:41 AM, Arthur Pemberton wrote:
On 7/27/07, Mike Chambers <mike(a)miketc.com> wrote:
> On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
>
>
>> Not everybody is on rpm-maint list and we'd like to hear the wishes of
>> (Fedora) developers/packagers too. So: what have you always wanted to do
>> with rpm, but wasn't able to? Or the other way around: what you always
>> wished rpm would do for you? What always annoyed you out of your mind?
>>
> I don't know if this can be done now, or if at all, and I am not a
> developer or even really a packager, so this may be something way out in
> left field.
>
> BUT, upon saying all that, is there a way to create, make, or use some
> sort of restore point, to get rpm back in shape if a library or
> something gets out of wack?
>
I'm wonder if rpm could rpm -e back to a certain point, then rpm -i
--force all lib packages
A --repackage option exists for a very log time. Life saver, sometimes...
4:59 a.m.
Hello Mike,
On Fri, 27 Jul 2007, Mike Chambers wrote:
BUT, upon saying all that, is there a way to create, make, or use
some
sort of restore point, to get rpm back in shape if a library or
something gets out of wack? Maybe a rpm --backup option that can be
used to backup rpm at a certain point. Then somehow it can be brought
back to that state, even if it's a tar'd file, gzipped or whatever?
Reason to have it that way is due to rpm not being functional or allowed
to do anything because some library or whatever got screwed up, and you
have to reinstall the OS instead of just a quick restore.
I think, you're looking for the rollback features being already part of
rpm5.org for a longer time. What does this feature do? When you're updating
or ereasing a package, it creates a package of the changed one. It's more
or less equivalent to your expected tarball or gzipped one. Please notice,
that of course this rollback rpm is not the same rpm as installed before,
it is just a copy of what was in filesystem and was covered by the package.
IIRC this feature was introduced in November 2005 at rpm5.org. You're able
to extract things from this package my the help of rpm2cpio/cpio similar to
a tarball. It's a nice feature which saved my ass in the past a couple of
times, yes.
Greetings,
Robert
12:19 p.m.
On Sat, 28 Jul 2007, Robert Scheck wrote:
Hello Mike,
On Fri, 27 Jul 2007, Mike Chambers wrote:
> BUT, upon saying all that, is there a way to create, make, or use some
> sort of restore point, to get rpm back in shape if a library or
> something gets out of wack? Maybe a rpm --backup option that can be
> used to backup rpm at a certain point. Then somehow it can be brought
> back to that state, even if it's a tar'd file, gzipped or whatever?
> Reason to have it that way is due to rpm not being functional or allowed
> to do anything because some library or whatever got screwed up, and you
> have to reinstall the OS instead of just a quick restore.
I think, you're looking for the rollback features being already part of
rpm5.org for a longer time. What does this feature do? When you're updating
or ereasing a package, it creates a package of the changed one. It's more
or less equivalent to your expected tarball or gzipped one. Please notice,
that of course this rollback rpm is not the same rpm as installed before,
it is just a copy of what was in filesystem and was covered by the package.
IIRC this feature was introduced in November 2005 at rpm5.org. You're able
to extract things from this package my the help of rpm2cpio/cpio similar to
a tarball. It's a nice feature which saved my ass in the past a couple of
times, yes.
Repackaging for rollback is an *ancient* feature of rpm, goes back all the
way to rpm 4.0.0.
- Panu -
9:56 p.m.
- Separated summary and description section
Since currently package description is mostly written in english, it's
not very friendly to non-english people.
And the rpm spec is mostly maintained by one person, for whom
maintaining i18n-summary such as Summary(zh): Summray(jp) is too hard.
Any good ideas?
--
http://hellwolf.cublog.cn
gpg --keyserver pgp.mit.edu --recv-key 0x6B174C6F
Mercury: gpm isn't a very good web browser. fix it.
9:52 a.m.
ZC Miao <hellwolf.misty <at> gmail.com> writes:
Since currently package description is mostly written in english,
it's
not very friendly to non-english people.
And the rpm spec is mostly maintained by one person, for whom
maintaining i18n-summary such as Summary(zh): Summray(jp) is too hard.
Any good ideas?
That's what specspo is supposed to be for, it just doesn't appear to be very
actively maintained.
Kevin Kofler
10:01 a.m.
Hello Kevin,
On Sat, 28 Jul 2007, Kevin Kofler wrote:
Am I the only one who things that being able to rpm -Uvh
http://....rpm
is a nice feature?
no you aren't - we're at least two guys. I hope, Panu will not rip out such
things, but use an external helper or similar. It's worse enough to see,
that openSUSE rips neon support out to replace with a 50 lines hack. Maybe
there are chances to optimize this transport.
Greetings,
Robert
10:20 a.m.
On 28.07.2007 17:01, Robert Scheck wrote:
Hello Kevin,
On Sat, 28 Jul 2007, Kevin Kofler wrote:
> Am I the only one who things that being able to rpm -Uvh http://....rpm
> is a nice feature?
no you aren't - we're at least two guys.
Well, afaics most of the other linux command line tools don't support
such stuff, so why should rpm? IOW,
$ strings http://....rpm | less"
doesn't work. But
$ wget -O - http://....rpm | strings | less
does. So
$ wget -O - http://....rpm | rpm -ivh
would match the behavior of other tools (but doesn't work afaics -- that
maybe should be fixed).
Cu
thl
2:14 p.m.
On Saturday 28 July 2007, Thorsten Leemhuis wrote:
On 28.07.2007 17:01, Robert Scheck wrote:
> Hello Kevin,
>
> On Sat, 28 Jul 2007, Kevin Kofler wrote:
>> Am I the only one who things that being able to rpm -Uvh http://....rpm
>> is a nice feature?
>
> no you aren't - we're at least two guys.
Well, afaics most of the other linux command line tools don't support
such stuff
Well, I'd actually prefer if most of them did. But (re-)implementing that
everywhere wouldn't probably make sense and not everything works with stdin
so things aren't always that easy. Here's a slightly cleaned up version of a
helper script I've had locally to help with this for some time:
$ urlwrap.sh less -- http://scop.fedorapeople.org/scripts/urlwrap.sh
$ urlwrap.sh rpm -Uvh -- http://.../1.rpm http://.../2.rpm
2:29 p.m.
Ville Skyttä <ville.skytta <at> iki.fi> writes:
Well, I'd actually prefer if most of them did. But
(re-)implementing that
everywhere wouldn't probably make sense and not everything works with stdin
so things aren't always that easy. Here's a slightly cleaned up version of a
helper script I've had locally to help with this for some time:
$ urlwrap.sh less -- http://scop.fedorapeople.org/scripts/urlwrap.sh
$ urlwrap.sh rpm -Uvh -- http://.../1.rpm http://.../2.rpm
Hint: You can also use kioexec (part of kdelibs) for this purpose.
Kevin Kofler
11:17 a.m.
Kevin Kofler escribió:
Panu Matilainen <pmatilai <at> redhat.com> writes:
> - RPM is not an ftp/http client, it's a package manager.
Am I the only one who things that being able to rpm -Uvh http://....rpm is a
nice feature?
Uhhh?? rpm does this since version 3.x, or before.
--
select 'mmarques' || '@' || 'unl.edu.ar' AS email;
---------------------------------------------------------
Martín Marqués | Programador, DBA
Centro de Telemática | Administrador
Universidad Nacional
del Litoral
---------------------------------------------------------
1:04 p.m.
Martin Marques <martin <at> bugs.unl.edu.ar> writes:
Kevin Kofler escribió:
> Panu Matilainen <pmatilai <at> redhat.com> writes:
>> - RPM is not an ftp/http client, it's a package manager.
>
> Am I the only one who [thinks] that being able to rpm -Uvh http://....rpm
> is a nice feature?
Uhhh?? rpm does this since version 3.x, or before.
But it appears like this feature is proposed to be axed.
Kevin Kofler
2:48 p.m.
On Sat, 28 Jul 2007, Kevin Kofler wrote:
Martin Marques <martin <at> bugs.unl.edu.ar> writes:
> Kevin Kofler escribió:
>> Panu Matilainen <pmatilai <at> redhat.com> writes:
>>> - RPM is not an ftp/http client, it's a package manager.
>>
>> Am I the only one who [thinks] that being able to rpm -Uvh http://....rpm
>> is a nice feature?
>
> Uhhh?? rpm does this since version 3.x, or before.
But it appears like this feature is proposed to be axed.
To get some perspective into this, look at the following bugs and ask
yourself, what does this have to do with package management?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149276
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189107
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206066
It's not the feature I want to axe, but the client code *in* rpm. There's
software designed to deal with these kind of things, let them handle the
complexities.
- Panu -
2:51 p.m.
On 7/28/07, Panu Matilainen <pmatilai(a)laiskiainen.org> wrote:
On Sat, 28 Jul 2007, Kevin Kofler wrote:
> Martin Marques <martin <at> bugs.unl.edu.ar> writes:
>> Kevin Kofler escribió:
>>> Panu Matilainen <pmatilai <at> redhat.com> writes:
>>>> - RPM is not an ftp/http client, it's a package manager.
>>>
>>> Am I the only one who [thinks] that being able to rpm -Uvh http://....rpm
>>> is a nice feature?
>>
>> Uhhh?? rpm does this since version 3.x, or before.
>
> But it appears like this feature is proposed to be axed.
To get some perspective into this, look at the following bugs and ask
yourself, what does this have to do with package management?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149276
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189107
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206066
It's not the feature I want to axe, but the client code *in* rpm. There's
software designed to deal with these kind of things, let them handle the
complexities.
From a programming standpoint, this makes a lot of sense + plus it
isn't the unix way, and if it adds even a single bug, it dosn't seem
worth it.
--
Fedora Core 6 and proud
8:37 a.m.
On Sat, 2007-07-28 at 18:46 +0200, Emmanuel Seyman wrote:
* Kevin Kofler [28/07/2007 18:41] :
>
> Am I the only one who things that being able to rpm -Uvh http://....rpm is a
> nice feature?
No but then again, I'll live with
wget http://....rpm -O foo && rpm -Uvh foo
Change that to a pipe and you've sold me:
$ wget -O - http://whatever | rpm -qpi -
On closer inspection, this almost works already, if you invoke it as
'rpm -qpi /dev/stdin'. Explicit - for stdin, or just implicit stdin
with no args, would just be gravy.
- ajax
2:05 p.m.
Dnia 2007-07-28, o godz. 14:53:49 Kevin Kofler <kevin.kofler(a)chello.at>
napisał(a):
Am I the only one who things that being able to rpm -Uvh
http://....rpm is a
nice feature?
It's nice the first time you think of it. But the first time you
actually try
it, rpm tells you it needs some other packages for dependencies and you have
to download the file again. At least it worked that way last time I've tried,
maybe it supports some caching now?
Lam
2:18 p.m.
On Sat, 2007-07-28 at 14:53 +0000, Kevin Kofler wrote:
Panu Matilainen <pmatilai <at> redhat.com> writes:
> - RPM is not an ftp/http client, it's a package manager.
Am I the only one who things that being able to rpm -Uvh http://....rpm is a
nice feature?
it's not an issue of it being a nice feature - it is an issue of whether
it is a good idea to maintain the code. Keep in mind - rpm has its own
http/ftp client included. It's not using curl or wget. All its own code.
That seems a bit much to maintain esp when the majority of people using
rpm do it through a higher level language that already has a http/ftp
client.
the best way to make rpm reliable and consistent is to strip out all
things that are unnecessary.
-sv
4:14 p.m.
On 7/28/07, seth vidal <skvidal(a)linux.duke.edu> wrote:
On Sat, 2007-07-28 at 14:53 +0000, Kevin Kofler wrote:
> Panu Matilainen <pmatilai <at> redhat.com> writes:
> > - RPM is not an ftp/http client, it's a package manager.
>
> Am I the only one who things that being able to rpm -Uvh http://....rpm is a
> nice feature?
it's not an issue of it being a nice feature - it is an issue of whether
it is a good idea to maintain the code. Keep in mind - rpm has its own
http/ftp client included. It's not using curl or wget. All its own code.
That seems a bit much to maintain esp when the majority of people using
rpm do it through a higher level language that already has a http/ftp
client.
the best way to make rpm reliable and consistent is to strip out all
things that are unnecessary.
-sv
I would imagine this opens RPM up to remote attacks too.
--
Fedora Core 6 and proud
8:51 a.m.
On Sat, 2007-07-28 at 16:14 -0500, Arthur Pemberton wrote:
On 7/28/07, seth vidal <skvidal(a)linux.duke.edu> wrote:
> On Sat, 2007-07-28 at 14:53 +0000, Kevin Kofler wrote:
> > Panu Matilainen <pmatilai <at> redhat.com> writes:
> > > - RPM is not an ftp/http client, it's a package manager.
> >
> > Am I the only one who things that being able to rpm -Uvh http://....rpm is a
> > nice feature?
>
> it's not an issue of it being a nice feature - it is an issue of whether
> it is a good idea to maintain the code. Keep in mind - rpm has its own
> http/ftp client included. It's not using curl or wget. All its own code.
> That seems a bit much to maintain esp when the majority of people using
> rpm do it through a higher level language that already has a http/ftp
> client.
>
> the best way to make rpm reliable and consistent is to strip out all
> things that are unnecessary.
>
> -sv
I would imagine this opens RPM up to remote attacks too.
I second the above.
Running HTTP/FTP client as root is -not- a god idea.
Even if HTTP is being pushed to an external plugin that's built around
wget, this plug must be executed as user/guest and not as root.
- Gilboa
11:35 a.m.
mån 2007-07-30 klockan 16:51 +0300 skrev Gilboa Davara:
I second the above.
Running HTTP/FTP client as root is -not- a god idea.
Even if HTTP is being pushed to an external plugin that's built around
wget, this plug must be executed as user/guest and not as root.
Yes, the principle of least privilege does apply here.
Though, I would worry more about the fact that rpm -ivh http://...
doesn't verify any signatures. It's a good idea to:
wget http://...
rpm -K foo.rpm
Look at the result, and then maybe:
rpm -i foo.rpm
(rpm -K && rpm -i won't do, since it'll say OK for unsigned packages,
IIRC)
Or, even:
wget http://...
yum localinstall foo.rpm
Which, in turn, might be possible to simplify?
/abo
1 p.m.
Alexander Boström <abo <at> kth.se> writes:
Or, even:
wget http://...
yum localinstall foo.rpm
Which, in turn, might be possible to simplify?
apt-get install http://... :-) (This works with apt-rpm, not with Debian apt.)
Though more often than not I end up actually having to disable the signature
check (-o RPM::GPG-Check=false) when I do this. RPMs which aren't in a
repository tend not to be signed, if they're in a repository I don't have
enabled, I don't have the key imported either.
Kevin Kofler
1:03 p.m.
On Mon, 30 Jul 2007, Alexander Boström wrote:
mån 2007-07-30 klockan 16:51 +0300 skrev Gilboa Davara:
> I second the above.
> Running HTTP/FTP client as root is -not- a god idea.
>
> Even if HTTP is being pushed to an external plugin that's built around
> wget, this plug must be executed as user/guest and not as root.
Yes, the principle of least privilege does apply here.
Though, I would worry more about the fact that rpm -ivh http://...
doesn't verify any signatures. It's a good idea to:
Actually it does verify the signature if one is present, unless you turn
it off explicitly. The problem is that rpm doesn't have a meaningful
mechanism to *prevent* installation if unsigned and/or signed but
untrusted packages are installed. Yes it's .. silly.
wget http://...
rpm -K foo.rpm
Look at the result, and then maybe:
rpm -i foo.rpm
(rpm -K && rpm -i won't do, since it'll say OK for unsigned packages,
IIRC)
Or, even:
wget http://...
yum localinstall foo.rpm
Which, in turn, might be possible to simplify?
Yum could just as well support "yum install http://..../foo.rpm" :)
Speaking of that, yum currently accesses package header before verifying
the signature, at least in the case of localinstall. I've some fuzzed
rpm's here that cause rpm to segfault if signature checking is
disabled as yum does... Dunno how exploitable that is in reality but there
is a potential vulnerability there anyway.
- Panu -
2:57 p.m.
On Mon, 2007-07-30 at 21:03 +0300, Panu Matilainen wrote:
Yum could just as well support "yum install
http://..../foo.rpm" :)
Speaking of that, yum currently accesses package header before verifying
the signature, at least in the case of localinstall. I've some fuzzed
rpm's here that cause rpm to segfault if signature checking is
disabled as yum does... Dunno how exploitable that is in reality but there
is a potential vulnerability there anyway.
1. Can I get a copy of those rpms?
2. I've heard about the aforementioned mythic case of an exploit but
never actually seen one. I could be wrong but I thought the case that
was dangerous was not if gpg signature checking was disabled but if
header checking in general was disabled. Changing yum's opener for pkgs
so it does with hdr checking enabled is pretty simple to do - however,
it'd be nice if I had a replicating case to check it out with.
Thanks,
-sv
3:21 p.m.
On Mon, 30 Jul 2007, seth vidal wrote:
On Mon, 2007-07-30 at 21:03 +0300, Panu Matilainen wrote:
> Yum could just as well support "yum install http://..../foo.rpm" :)
>
> Speaking of that, yum currently accesses package header before verifying
> the signature, at least in the case of localinstall. I've some fuzzed
> rpm's here that cause rpm to segfault if signature checking is
> disabled as yum does... Dunno how exploitable that is in reality but there
> is a potential vulnerability there anyway.
1. Can I get a copy of those rpms?
2. I've heard about the aforementioned mythic case of an exploit but
never actually seen one. I could be wrong but I thought the case that
was dangerous was not if gpg signature checking was disabled but if
header checking in general was disabled. Changing yum's opener for pkgs
so it does with hdr checking enabled is pretty simple to do - however,
it'd be nice if I had a replicating case to check it out with.
Sure, check out the crash_rpm?.rpm's from comments 1-3
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239557
You'll need to test those with rpm 4.4.2.1 as older ones crash on them
with or without signature checking.
- Panu -
4:15 p.m.
On Mon, 30 Jul 2007, seth vidal wrote:
On Mon, 2007-07-30 at 21:03 +0300, Panu Matilainen wrote:
> Yum could just as well support "yum install http://..../foo.rpm" :)
>
> Speaking of that, yum currently accesses package header before verifying
> the signature, at least in the case of localinstall. I've some fuzzed
> rpm's here that cause rpm to segfault if signature checking is
> disabled as yum does... Dunno how exploitable that is in reality but there
> is a potential vulnerability there anyway.
1. Can I get a copy of those rpms?
2. I've heard about the aforementioned mythic case of an exploit but
never actually seen one. I could be wrong but I thought the case that
was dangerous was not if gpg signature checking was disabled but if
header checking in general was disabled. Changing yum's opener for pkgs
so it does with hdr checking enabled is pretty simple to do - however,
it'd be nice if I had a replicating case to check it out with.
BTW if it's of any comfort, apt is guilty of the same thing. Doh :)
- Panu -
1:16 p.m.
On Mon, 30 Jul 2007, Gilboa Davara wrote:
On Sat, 2007-07-28 at 16:14 -0500, Arthur Pemberton wrote:
> On 7/28/07, seth vidal <skvidal(a)linux.duke.edu> wrote:
>> On Sat, 2007-07-28 at 14:53 +0000, Kevin Kofler wrote:
>>> Panu Matilainen <pmatilai <at> redhat.com> writes:
>>>> - RPM is not an ftp/http client, it's a package manager.
>>>
>>> Am I the only one who things that being able to rpm -Uvh http://....rpm is a
>>> nice feature?
>>
>> it's not an issue of it being a nice feature - it is an issue of whether
>> it is a good idea to maintain the code. Keep in mind - rpm has its own
>> http/ftp client included. It's not using curl or wget. All its own code.
>> That seems a bit much to maintain esp when the majority of people using
>> rpm do it through a higher level language that already has a http/ftp
>> client.
>>
>> the best way to make rpm reliable and consistent is to strip out all
>> things that are unnecessary.
>>
>> -sv
>
> I would imagine this opens RPM up to remote attacks too.
I second the above.
Running HTTP/FTP client as root is -not- a god idea.
Yet that's how all our depsolvers and the associated tools work...
- Panu -
2 p.m.
Evening,
On Mon, 30 Jul 2007, Panu Matilainen wrote:
>>> the best way to make rpm reliable and consistent is to
strip out all
>>> things that are unnecessary.
hm. Looking forward to pyrpm and pyyum or however it is called, is it
necessary to keep rpm and yum at all? Neither pyrpm nor the pyyum depend on
rpmlib somehow. Isn't it overkill to have two implementations of the same?
Guessing a python rpm (written only in that script language) would make
many Red Hat people happy, because python is the Red Hat in-house defacto
standard, isn't it?
>> I would imagine this opens RPM up to remote attacks too.
>
> I second the above.
> Running HTTP/FTP client as root is -not- a god idea.
Yet that's how all our depsolvers and the associated tools work...
Well. Seen from this point, we should download *all* files in yum and (...)
with an unprivileged account, check somehow and afterwards install as root.
Eggdrop for example avoids to be executed as root, but when you're hacking
this into wget...it's better not to complete this sentence.
Finally, having Neon support in RPM is IMHO just the same high or less risk
as having Neon support in Subversion. Why to castrate RPM at all? It looks
like just to get other non-named tools more deeply involved. And if this is
reason, there's from my POV no need to keep RPM in the current form. And a
stupid python hack could replace everything and should be written fast; can
somebody agree with me or am I already stamped as mailing list clown?
Greetings,
Robert
2:08 p.m.
Robert Scheck wrote:
Evening,
On Mon, 30 Jul 2007, Panu Matilainen wrote:
>>>> the best way to make rpm reliable and consistent is to strip out all
>>>> things that are unnecessary.
hm. Looking forward to pyrpm and pyyum or however it is called, is it
necessary to keep rpm and yum at all? Neither pyrpm nor the pyyum depend on
rpmlib somehow. Isn't it overkill to have two implementations of the same?
Pyrpm is described as "PyRPM is an experimental project to look at rpm
package management". It is a prototyping tool. Not a implementation
meant to be used by users currently unlike Yum (which I think is what
you are referring to as pyyum).
Rahul
2:24 p.m.
Hello Rahul,
On Tue, 31 Jul 2007, Rahul Sundaram wrote:
Pyrpm is described as "PyRPM is an experimental project to look
at rpm
package management". It is a prototyping tool. Not a implementation meant
to be used by users currently unlike Yum (which I think is what you are
referring to as pyyum).
okay, you did never use PyRPM. I played with pyrpm and it looks acceptable
for different actions and unfortunately I played just less with pyyum which
is included there (sorry, I'm to lazy to verifiy whether it's really called
pyyum) and it also could be an interesting way. Reading this and reading
further on at the list, it already sounds a bit as there's no interest to
walk *really* a new and radical way regarding RPM. Why? What is preventing?
When looking back e.g. to soft dependencies, I remember that they just were
refused for obivious reasons by individuals having the right position at
Fedora (or Red Hat). You maybe treat this as flame, but this is what the
feedback from that time looked like.
The end of the song normally is: Everybody wants new features, nobody wants
to implement them or when they're getting implemented nothing should break
or change because the packaging management system is very basic, everything
has to be 100% backward compatible but in the same way; it should be legacy
free as well on the other hand. Wrong world. Maybe you can see, what the
real problem behind the doors is. Otherwise, please try to open your eyes.
Greetings,
Robert
2:50 p.m.
Robert Scheck wrote:
Hello Rahul,
On Tue, 31 Jul 2007, Rahul Sundaram wrote:
> Pyrpm is described as "PyRPM is an experimental project to look at rpm
> package management". It is a prototyping tool. Not a implementation meant
> to be used by users currently unlike Yum (which I think is what you are
> referring to as pyyum).
okay, you did never use PyRPM.
I don't know why you want to assume that. My use is irrelvant to your
question on whether pyrpm duplicates yum and RPM. Answer: No. it
doesn't. pyrpm is clearly described as a experimental prototype in it's
homepage at http://www.jur-linux.org/pyrpm/. That's the first hit in
google btw.
I played with pyrpm and it looks acceptable
for different actions and unfortunately I played just less with pyyum
which
is included there (sorry, I'm to lazy to verifiy whether it's really called
pyyum) and it also could be an interesting way.
It is called yum and not pyyum which would a redundant name since the
only existing implementation of Yum is in python. If you are a Fedora
user, the fact the name is yum should have been obvious.
Reading this and reading
further on at the list, it already sounds a bit as there's no
interest to
walk *really* a new and radical way regarding RPM. Why? What is preventing?
A fork did occur because people have different opinions on the right
path. Distributions will eventually decide one way or the other and we
can all hopefully have what we wanted.
When looking back e.g. to soft dependencies, I remember that they
just were
refused for obivious reasons by individuals having the right position at
Fedora (or Red Hat). You maybe treat this as flame, but this is what the
feedback from that time looked like.
Panu did mention that he was considering soft dependencies in rpm-maint
list.
https://lists.dulug.duke.edu/pipermail/rpm-maint/2007-June/000330.html
Many people both Red Hat and non-Red Hat folks have been expressing some
concerns over soft dependencies.
Rahul
3:01 a.m.
On Tue, 31 Jul 2007, Rahul Sundaram wrote:
Robert Scheck wrote:
> When looking back e.g. to soft dependencies, I remember that they just were
> refused for obivious reasons by individuals having the right position at
> Fedora (or Red Hat). You maybe treat this as flame, but this is what the
> feedback from that time looked like.
Panu did mention that he was considering soft dependencies in rpm-maint list.
https://lists.dulug.duke.edu/pipermail/rpm-maint/2007-June/000330.html
Many people both Red Hat and non-Red Hat folks have been expressing some
concerns over soft dependencies.
Various Red Hat folks have indeed been very much against soft
dependencies, but if rpm.org is to have any "independent upstream"
credibility like it's supposed to be, we got to remember RPM is not just
for Red Hat.
Whether rpm.org support soft dependencies and whether Fedora allows using
them are two different questions.
- Panu -
6:58 a.m.
Rahul Sundaram wrote:
Robert Scheck wrote:
> Hello Rahul,
>
> On Tue, 31 Jul 2007, Rahul Sundaram wrote:
>> Pyrpm is described as "PyRPM is an experimental project to look at
>> rpm package management". It is a prototyping tool. Not a
>> implementation meant to be used by users currently unlike Yum (which
>> I think is what you are referring to as pyyum).
>
> okay, you did never use PyRPM.
I don't know why you want to assume that. My use is irrelvant to your
question on whether pyrpm duplicates yum and RPM. Answer: No. it
doesn't. pyrpm is clearly described as a experimental prototype in it's
homepage at http://www.jur-linux.org/pyrpm/. That's the first hit in
google btw.
Your use is relevant when it comes to the question if your opinion is in any
way better founded than that of google.
It is called yum and not pyyum which would a redundant name since the
only existing implementation of Yum is in python. If you are a Fedora
user, the fact the name is yum should have been obvious.
The PyRPM suite includes pyrpm - a rpm replacement in pure Python, pyrpmyum
- a yum reimplementation build on top of the pyrpm libs, pyrpmkickstart -
a tool for doing kickstart installations from within a running system into
hard drives or disk images. There are also a number of test scripts for
checking rpm based distributions for various problems.
The whole software suite is written from scratch in pure Python. This was
done to be independent from upstream projects (rpm, yum) and to be a rapid
prototyping testbed for experimental and/or new features/modifications. It
also provides a basis for various large scale tests that were either too
complicated or simply not doable with the existing tools.
It was (and to some extend still is) experimental in the sense of
1. Developing/using advanced techniques not (yet) found in rpm and yum. This
includes better multilib handling, auto eraser, better depsolving, high
performance and low memory foot print. I am just now porting the first
lessons learned there to yum.
2. Not having a large enough user base to be considered as stable. Due to a
large number of tests we have done with that codebase we're now quite
confident that we have at least reached a similar stability as the current
version of yum.
I hope that makes things more clear.
Florian
1:50 p.m.
Panu Matilainen wrote:
Hey all,
I know I'm opening up Pandoras box here but what the heck, it's Friday
and I'm feeling slightly bored...
With RPM 4.4.2.1 fresh out and 4.4.x branched off to maintenance mode,
time to start looking forward to next major release. While the focus
will be largely in cleaning up and streamlining the codebase, it can't
realistically be all about just that
User (as opposed to administrator) installs in their home directories. I
could run say Mozilla Firefox extracted from a tarball but having a
similar capability in RPM itself would be nice.
RPM should also recognize and use library files I have installed through
other means.
Rahul
3:09 p.m.
On Sun, 2007-07-29 at 00:20 +0530, Rahul Sundaram wrote:
Panu Matilainen wrote:
>
> Hey all,
>
> I know I'm opening up Pandoras box here but what the heck, it's Friday
> and I'm feeling slightly bored...
>
> With RPM 4.4.2.1 fresh out and 4.4.x branched off to maintenance mode,
> time to start looking forward to next major release. While the focus
> will be largely in cleaning up and streamlining the codebase, it can't
> realistically be all about just that
User (as opposed to administrator) installs in their home directories. I
could run say Mozilla Firefox extracted from a tarball but having a
similar capability in RPM itself would be nice.
RPM should also recognize and use library files I have installed through
other means.
-ENOTSANE
It does not make sense to have rpm chase down paths which may or may not
be available at any given time. Let alone be able to maintain and verify
them. (think security updates)
If it is not in the rpmdb then rpm doesn't know about it. I like that
rule, it's hard, it's fast and it's simple to understand.
If the problem is making it possible for users to install more software
then we can pursue other ways to do that.
-sv
11:29 a.m.
seth vidal wrote:
On Sun, 2007-07-29 at 00:20 +0530, Rahul Sundaram wrote:
> User (as opposed to administrator) installs in their home directories. I
> could run say Mozilla Firefox extracted from a tarball but having a
> similar capability in RPM itself would be nice.
>
> RPM should also recognize and use library files I have installed through
> other means.
-ENOTSANE
It does not make sense to have rpm chase down paths which may or may not
be available at any given time. Let alone be able to maintain and verify
them. (think security updates)
It's worse than that. If you look carefully at his example, firefox,
you'll notice this:
$ eu-readelf -d /usr/lib/firefox-2.0.0.3/firefox-bin | grep RPATH
RPATH Library rpath: [/usr/lib/firefox-2.0.0.3]
Which means if you want it installed in a home directory, you have to
modify all the binaries to look in a different path than they normally
would -- rpath would need to point at something like
~pjones/usr/lib/firefox-2.0.0.3 .
If we're want to support something like this, the way to do it would be
something like per-user unionfs namespaces. We'd still need some rpm
help (it'd need to remap file ownership during installation, at the very
least), but mostly the work isn't within rpm's scope.
--
Peter
4:41 a.m.
On 28.07.2007 20:50, Rahul Sundaram wrote:
Panu Matilainen wrote:
> I know I'm opening up Pandoras box here but what the heck, it's Friday
> and I'm feeling slightly bored...
>
> With RPM 4.4.2.1 fresh out and 4.4.x branched off to maintenance mode,
> time to start looking forward to next major release. While the focus
> will be largely in cleaning up and streamlining the codebase, it can't
> realistically be all about just that
User (as opposed to administrator) installs in their home directories. I
could run say Mozilla Firefox extracted from a tarball but having a
similar capability in RPM itself would be nice. [...]
+1 -- I think that's something that would be really nice to have. But
it's likely a "to big" project/idea for now, but maybe something people
could keep in mind when designing next generation's rpm, so maybe it's
then possible a bit easier with a later generation of rpm.
Just my 2 cent (¹)
CU
knurd
(¹) -- I get yelled at by my girlfirends now and then when I install
some experimental stuff for tests on the machine she uses and break her
Firefox/Thunderbird/whatever accidentally without noticing...
4:35 p.m.
On Friday 27 July 2007 14:40:40 Panu Matilainen wrote:
with rpm, but wasn't able to? Or the other way around: what you
always
wished rpm would do for you? What always annoyed you out of your mind?
rpmbuild could implement itself all the stuff that is the same in Fedora's
specs:
- a sane default buildroot definition
- Cleaning $RPM_BUILD_ROOT itself in %install (and without any race condition)
- A default %clean section with rm -rf $RPM_BUILD_ROOT
- %defattr(-,root,root,-) per default in %files
This would save at least 5 lines in nearly every spec of Fedora.
Regards,
Till
5:52 p.m.
On Sat, 2007-07-28 at 23:35 +0200, Till Maas wrote:
rpmbuild could implement itself all the stuff that is the same in Fedora's
specs:
- a sane default buildroot definition
- Cleaning $RPM_BUILD_ROOT itself in %install (and without any race condition)
- A default %clean section with rm -rf $RPM_BUILD_ROOT
- %defattr(-,root,root,-) per default in %files
This would save at least 5 lines in nearly every spec of Fedora.
It's not a matter of saving space, but this is a conceptual problem
too -- why should the .spec file know and set the $RPM_BUILD_ROOT?
And why should it do the default 'rm -rf $RPM_BUILD_ROOT'???
This _feels_ very, very wrong. It is a clear layering violation
that is confusing and counterproductive. rpmbuild should create
the root and pass it into the .spec, taking care of cleaning it
when appropriate.
My proposal is to implement this where it belongs (in rpmbuild),
and issue warnings (and ignore) any attempt to set the build root
or to rm -rf it from within the spec.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
11:26 p.m.
>>>> "DP" == Dimi Paun <dimi(a)lattica.com>
writes:
DP> My proposal is to implement this where it belongs (in rpmbuild),
I can't disagree with that.
DP> and issue warnings (and ignore) any attempt to set the build root
DP> or to rm -rf it from within the spec.
I must disagree with that; these statements will be required for
compatibility with old versions of RPM (see EPEL4) for many years to
come. I don't particularly want to fork a different version of my
specfiles when there's no need.
- J<
11:56 p.m.
On 28 Jul 2007 23:26:18 -0500, Jason L Tibbitts III <tibbs(a)math.uh.edu> wrote:
>>>>> "DP" == Dimi Paun
<dimi(a)lattica.com> writes:
DP> My proposal is to implement this where it belongs (in rpmbuild),
I can't disagree with that.
DP> and issue warnings (and ignore) any attempt to set the build root
DP> or to rm -rf it from within the spec.
I must disagree with that; these statements will be required for
compatibility with old versions of RPM (see EPEL4) for many years to
come. I don't particularly want to fork a different version of my
specfiles when there's no need.
What is the difference between ignoring it and doing it by default in
rpmbuild and what happens now?
--
Fedora Core 6 and proud
3:17 a.m.
On Sun, 28 Jul 2007, Jason L Tibbitts III wrote:
>>>>> "DP" == Dimi Paun
<dimi(a)lattica.com> writes:
DP> My proposal is to implement this where it belongs (in rpmbuild),
I can't disagree with that.
DP> and issue warnings (and ignore) any attempt to set the build root
DP> or to rm -rf it from within the spec.
I must disagree with that; these statements will be required for
compatibility with old versions of RPM (see EPEL4) for many years to
come. I don't particularly want to fork a different version of my
specfiles when there's no need.
Welcome to world of rpm: people want progress but no change.
See the discussion regarding setting a sane default buildroot:
https://lists.dulug.duke.edu/pipermail/rpm-maint/2007-February/000162.html
Lots of talk, no real consensus was reached because changing it one way or
the other breaks compatibility for somebody.
Maybe these things would need a new incompatible "spec 2" format (one that
actually has defined grammar etc) that fixes various insanities in the
current non-format and forces people to fork the specs for good :)
- Panu -
4:07 a.m.
Panu Matilainen wrote:
Maybe these things would need a new incompatible "spec 2"
format (one
that actually has defined grammar etc) that fixes various insanities in
the current non-format and forces people to fork the specs for good :)
That would require a major new version of RPM probably parallel
installable since we are going to be dealing with the current format for
a long time to come anyway.
Rahul
12:18 p.m.
On Sun, 2007-07-29 at 11:56 -0500, Jason L Tibbitts III wrote:
I don't think that's productive. All I said was "do it
but don't warn
about it by default".
True, but that's a minor point anyway. We could enable the warning
only with a flag (-Wall or somesuch). Automatic handling of buildroot
in rpmbuild is an obvious fix. We can certainly do something about
these small concerns.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
3:05 a.m.
On Sun, 29 Jul 2007, Jason L Tibbitts III wrote:
>>>>> "PM" == Panu Matilainen
<pmatilai(a)laiskiainen.org> writes:
PM> Welcome to world of rpm: people want progress but no change.
I don't think that's productive. All I said was "do it but don't warn
about it by default".
No, it's certainly not productive. Wasn't targeted at you personally,
just a generic comment on how these discussions tend to go...
- Panu -
6:15 a.m.
Hello Till,
On Sat, 28 Jul 2007, Till Maas wrote:
- a sane default buildroot definition
- Cleaning $RPM_BUILD_ROOT itself in %install (and without any race condition)
- A default %clean section with rm -rf $RPM_BUILD_ROOT
- %defattr(-,root,root,-) per default in %files
This would save at least 5 lines in nearly every spec of Fedora.
ever looked to /usr/lib/rpm/redhat/macros or /usr/lib/rpm/macros and asked
on the lists why this is not done by obvious reasons like backward compat
etc.? IIRC there already was such a discussion maybe half or a year ago...
FYI: Currently you can't do a "rm -rf $RPM_BUILD_ROOT" in
"%install"
automagically, because it breaks rebuilding of the kernel package, looks
somebody were to lazy to write something sane. I tried to enable this
feature on my rpm5.org installation, but IIRC there is at least one further
failure, too.
Conclusion: Some Fedora Packaging Maintainers should write sane spec files
first, there are other packaging issues, too (e.g. orphaned directories,
dangling symlinks).
Greetings,
Robert
11:13 a.m.
On Sunday 29 July 2007 13:15:05 Robert Scheck wrote:
ever looked to /usr/lib/rpm/redhat/macros or /usr/lib/rpm/macros and
asked
on the lists why this is not done by obvious reasons like backward compat
etc.? IIRC there already was such a discussion maybe half or a year ago...
Iirc the problem for too many people with fixing/changing this only in fedora
was, that they could not use the spec for other rpm based distributions
without using the fedora macros. But when rpm itself gets fixed, there is no
need fo these fedora macros. I hope I understood you correctly here,
otherwise please explain what you meant.
FYI: Currently you can't do a "rm -rf $RPM_BUILD_ROOT"
in "%install"
automagically, because it breaks rebuilding of the kernel package, looks
somebody were to lazy to write something sane. I tried to enable this
feature on my rpm5.org installation, but IIRC there is at least one further
failure, too.
I hope the kernel.spec can be fixed to work with this rm invocation, but in
case this is not the case, then %install could be defined in such a way that
%install --no-clean-buildroot
would not clean the buildroot in %install.
Conclusion: Some Fedora Packaging Maintainers should write sane spec
files
first, there are other packaging issues, too (e.g. orphaned directories,
dangling symlinks).
Is there any technical reason why a package system cannot determine the
ownership of directories by itself? Imho a package management system should
make it as easy as possible to create a package, i.e. do as much as possible
by itself. But what does this have to do with my improvement suggestions?
And what insane spec files produce dangling symlinks? Is there a common
mistake that creates them?
Regards,
Till
5:10 p.m.
On Sun, 29 Jul 2007 18:13:32 +0200
Till Maas <opensource(a)till.name> wrote:
And what insane spec files produce dangling symlinks?
A large amount of -devel packages have .so symlinks that are dangling
within the -devel package itself. However rpm is smart enough to
figure out where that link is pointing to and add a hard requires to
that file.
--
Jesse Keating
Release Engineer: Fedora
1:14 a.m.
Moin Jesse,
On Sun, 29 Jul 2007, Jesse Keating wrote:
A large amount of -devel packages have .so symlinks that are
dangling
within the -devel package itself. However rpm is smart enough to
figure out where that link is pointing to and add a hard requires to
that file.
not only. I was focussed to the point, that there are packaged symlinks
pointing to files which are not packaged. A very good example for such ugly
things was the docbook-dtds package for a long time. IIRC about one month
ago, somebody took care of bug #193475 (just took another year). Finally,
this issue was detected by a rpm5.org rpm - like other package insanities.
Greetings,
Robert
11:45 a.m.
Jesse Keating wrote:
On Sun, 29 Jul 2007 18:13:32 +0200
Till Maas <opensource(a)till.name> wrote:
> And what insane spec files produce dangling symlinks?
A large amount of -devel packages have .so symlinks that are dangling
within the -devel package itself. However rpm is smart enough to
figure out where that link is pointing to and add a hard requires to
that file.
Speaking of which, handling library paths better would be nice. Right
now if you say "provides: libxpcom.so" you'll satisfy dependencies for
things, whether that library is in the linker path or not.
Kindof complicated to get right, unfortunately.
--
Peter
12:31 a.m.
* Rollback and Repair feature (in the idea of Windows Restore,
assuming that works)
* Easier/clear database repair
* installation type status (installed as a dependency, or not) - would
make streamlining an installation easier
* (this one may exist in some form, i don't know) some way to tag a
package as a library, headers, server, client, standalone, so I could
essentially yum list servers at some point
12:42 a.m.
- What about sandbox support?
Currently rpmbuild can destroy data outside $RPM_BUILD_ROOT, /tmp, etc.
As in gentoo portage system, ebuild runs in a sandbox, which hacked the
glibc open/read/write routine and makes incarefully-written-programs(not
malice) unable to destroy other data.
--
http://hellwolf.cublog.cn
gpg --keyserver pgp.mit.edu --recv-key 0x6B174C6F
Showing up is 80% of life.
-- Woody Allen
1:20 a.m.
Dnia 2007-07-29, o godz. 13:42:02 ZC Miao <hellwolf.misty(a)gmail.com>
napisał(a):
- What about sandbox support?
Currently rpmbuild can destroy data outside $RPM_BUILD_ROOT, /tmp, etc.
That's
why it's always been required to not run rpmbuild as root. We have
rpmdev-setuptree exactly for making the sandbox quickly. You can't destroy
other users' files in tmp/ if you're not root, you know?
OTOH, making /usr/src/redhat owned by an rpmbuild user and setuid()ing to that
account automatically would make things simpler for you, but do you really
need it?
Lam
8:24 a.m.
ZC Miao <hellwolf.misty <at> gmail.com> writes:
- What about sandbox support?
That's what mock is for.
Of course, the gain in security from any such sandboxing is relative, because
the installation has to be as root anyway, so someone could just trojan the
actual programs and/or the post/postun scriptlets instead.
Kevin Kofler
10:53 a.m.
On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
* Unix philosophy - do just one thing and do it well:
- RPM is not a GPG key manager but a package manager.
- RPM is not an ftp/http client, it's a package manager.
... While I agree with the general UNIX philosophy, RPM's HTTP/FTP
support is very useful.
How about creating an external plug-in interface that will handle
non-standard file URLs instead of doing it in the main code?
- Gilboa
2:42 p.m.
On 7/29/07, Gilboa Davara <gilboad(a)gmail.com> wrote:
On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
> * Unix philosophy - do just one thing and do it well:
> - RPM is not a GPG key manager but a package manager.
> - RPM is not an ftp/http client, it's a package manager.
>
... While I agree with the general UNIX philosophy, RPM's HTTP/FTP
support is very useful.
How about creating an external plug-in interface that will handle
non-standard file URLs instead of doing it in the main code?
- Gilboa
Seems to me, removal of the code doesn't necessarily mean removal of
the feature. Future RPM might just depend on wget.
--
Fedora Core 6 and proud
5:47 a.m.
On Sun, 2007-07-29 at 14:42 -0500, Arthur Pemberton wrote:
On 7/29/07, Gilboa Davara <gilboad(a)gmail.com> wrote:
> On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
> > * Unix philosophy - do just one thing and do it well:
> > - RPM is not a GPG key manager but a package manager.
> > - RPM is not an ftp/http client, it's a package manager.
> >
>
> ... While I agree with the general UNIX philosophy, RPM's HTTP/FTP
> support is very useful.
> How about creating an external plug-in interface that will handle
> non-standard file URLs instead of doing it in the main code?
>
> - Gilboa
Seems to me, removal of the code doesn't necessarily mean removal of
the feature. Future RPM might just depend on wget.
/+1. Wget is a sound option.
- Gilboa
7:17 a.m.
On 7/30/07, Gilboa Davara <gilboad(a)gmail.com> wrote:
/+1. Wget is a sound option.
I'm sure that the rpm developers originally considered using an
external program but decided that it would be better to have an
internal http/ftp client.
If we start stripping out various bits of RPM and replacing them with
external libraries, we are making bootstrapping a headache. RPM is
used to install wget and other external libraries in the first place,
so having rpm depend on them makes things messy.
Maybe instead of removing the features, they could be left in, but
when an external program or library that does the job better is
installed, rpm detects it at runtime and uses it instead.
This way there is the best of both worlds:
- Basic support for x (eg, http) is provided in rpm, allowing you to
use x before a more complete implementation is installed.
- The code for x can be simplified, since it should no longer be
necessary to build in a full x implementation and handle corner cases.
- Once a better implementation is installed, rpm uses it by default,
and the inbuilt code for it is never executed.
n0dalus.
8:29 a.m.
On Mon, 30 Jul 2007 21:47:19 +0930
n0dalus <n0dalus+redhat(a)gmail.com> wrote:
If we start stripping out various bits of RPM and replacing them
with
external libraries, we are making bootstrapping a headache. RPM is
used to install wget and other external libraries in the first place,
so having rpm depend on them makes things messy.
Rescue environments with tools on disk that allow you to add/remove
content from your root via chroot. I see no reason why rpm has to
carry the web suite internal.
--
Jesse Keating
Release Engineer: Fedora
8:43 a.m.
On Mon, 2007-07-30 at 21:47 +0930, n0dalus wrote:
On 7/30/07, Gilboa Davara <gilboad(a)gmail.com> wrote:
>
> /+1. Wget is a sound option.
>
I'm sure that the rpm developers originally considered using an
external program but decided that it would be better to have an
internal http/ftp client.
If we start stripping out various bits of RPM and replacing them with
external libraries, we are making bootstrapping a headache. RPM is
used to install wget and other external libraries in the first place,
so having rpm depend on them makes things messy.
n0dalus.
By using a plug-in like system, you don't carry extra dependencies when
your boot-strapping (or when you're low on resources/storage), you just
lose non-critical features. (such as built-in http/ftp client)
- Gilboa
9:21 a.m.
n0dalus <n0dalus+redhat(a)gmail.com> wrote:
On 7/30/07, Gilboa Davara <gilboad(a)gmail.com> wrote:
>
> /+1. Wget is a sound option.
[...]
Maybe instead of removing the features, they could be left in, but
when an external program or library that does the job better is
installed, rpm detects it at runtime and uses it instead.
Sort of. Better if you ask for http://...rpm, and wget/curl/... aren't
there, just error out.
This way there is the best of both worlds:
- Basic support for x (eg, http) is provided in rpm, allowing you to
use x before a more complete implementation is installed.
No need, as the downloading when installing can be handled by external
tools (our you are installing from CD/DVD/local disk
- The code for x can be simplified, since it should no longer be
necessary to build in a full x implementation and handle corner cases.
And the security problems stay... for exploiting on partially installed
systems (i.e., the most vulnerable). Plus "Why should I install <foo>
just to use URLs with rpm, they work fine without it"... and you are
back at square one.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
4:25 a.m.
Panu Matilainen wrote :
[...] So: what have you always wanted to do
with rpm, but wasn't able to? Or the other way around: what you always
wished rpm would do for you? What always annoyed you out of your mind?
After reading some of the other posts, I remembered something that has
often come up, which I would use extensively if it existed :
Some automatic cache/copies of all %config files installed, with all
untouched versions always available. This would be very useful with
some simple tool to diff the current files(s) wit the backup(s), as
well as list all locally changed %config files. A sysadmin's dream come
true :-)
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora release 7 (Moonshine) - Linux kernel 2.6.22.1-27.fc7
Load : 0.34 0.47 0.68
4:38 a.m.
On 7/30/07, Matthias Saou
<thias(a)spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net>
wrote:
Panu Matilainen wrote :
> [...] So: what have you always wanted to do
> with rpm, but wasn't able to? Or the other way around: what you always
> wished rpm would do for you? What always annoyed you out of your mind?
After reading some of the other posts, I remembered something that has
often come up, which I would use extensively if it existed :
Some automatic cache/copies of all %config files installed, with all
untouched versions always available. This would be very useful with
some simple tool to diff the current files(s) wit the backup(s), as
well as list all locally changed %config files. A sysadmin's dream come
true :-)
Matthias
To be clear, are you thinking of a something like
cp *.conf /etc/backupconfs?
--
Fedora Core 6 and proud
4:51 a.m.
/me would like something like this as well, so I'm jumping in here
On 30.07.2007 11:38, Arthur Pemberton wrote:
On 7/30/07, Matthias Saou
<thias(a)spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net>
wrote:
> Panu Matilainen wrote :
>> [...] So: what have you always wanted to do
>> with rpm, but wasn't able to? Or the other way around: what you always
>> wished rpm would do for you? What always annoyed you out of your mind?
> After reading some of the other posts, I remembered something that has
> often come up, which I would use extensively if it existed :
>
> Some automatic cache/copies of all %config files installed, with all
> untouched versions always available. This would be very useful with
> some simple tool to diff the current files(s) wit the backup(s), as
> well as list all locally changed %config files. A sysadmin's dream come
> true :-)
To be clear, are you thinking of a something like
cp *.conf /etc/backupconfs?
For me the proper solution would be: (1) let RPM (or the packages
itself) ship a copy of all %config files somewhere in a place where they
are safe and don't get modified. (2) When the user edited a %config file
then let rpm on package update make a copy of the %config file from the
*old* package into another save place
Why that you ask? Simple, that way I can diff my current config file
against the modified one it is based on (the one created in (2) above).
Then I can take the current config file (the one from (1) above), copy
it in place and (manually) apply the diff I created earlier.
CU
knurd
5:14 a.m.
On 7/30/07, Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
/me would like something like this as well, so I'm jumping in
here
On 30.07.2007 11:38, Arthur Pemberton wrote:
> On 7/30/07, Matthias Saou
> <thias(a)spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net>
> wrote:
>> Panu Matilainen wrote :
>>> [...] So: what have you always wanted to do
>>> with rpm, but wasn't able to? Or the other way around: what you always
>>> wished rpm would do for you? What always annoyed you out of your mind?
>> After reading some of the other posts, I remembered something that has
>> often come up, which I would use extensively if it existed :
>>
>> Some automatic cache/copies of all %config files installed, with all
>> untouched versions always available. This would be very useful with
>> some simple tool to diff the current files(s) wit the backup(s), as
>> well as list all locally changed %config files. A sysadmin's dream come
>> true :-)
> To be clear, are you thinking of a something like
>
> cp *.conf /etc/backupconfs?
For me the proper solution would be: (1) let RPM (or the packages
itself) ship a copy of all %config files somewhere in a place where they
are safe and don't get modified. (2) When the user edited a %config file
then let rpm on package update make a copy of the %config file from the
*old* package into another save place
Why that you ask? Simple, that way I can diff my current config file
against the modified one it is based on (the one created in (2) above).
Then I can take the current config file (the one from (1) above), copy
it in place and (manually) apply the diff I created earlier.
CU
knurd
Seems like a good idea to me. But considering that config files are
relatively small, this would be best if done automatically.
--
Fedora Core 6 and proud
6:31 a.m.
Arthur Pemberton wrote:
On 7/30/07, Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
> /me would like something like this as well, so I'm jumping in here
>
> On 30.07.2007 11:38, Arthur Pemberton wrote:
>
>> On 7/30/07, Matthias Saou
>> <thias(a)spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net>
>> wrote:
>>
>>> Panu Matilainen wrote :
>>>
>>>> [...] So: what have you always wanted to do
>>>> with rpm, but wasn't able to? Or the other way around: what you
always
>>>> wished rpm would do for you? What always annoyed you out of your mind?
>>>>
>>> After reading some of the other posts, I remembered something that has
>>> often come up, which I would use extensively if it existed :
>>>
>>> Some automatic cache/copies of all %config files installed, with all
>>> untouched versions always available. This would be very useful with
>>> some simple tool to diff the current files(s) wit the backup(s), as
>>> well as list all locally changed %config files. A sysadmin's dream come
>>> true :-)
>>>
>> To be clear, are you thinking of a something like
>>
>> cp *.conf /etc/backupconfs?
>>
> For me the proper solution would be: (1) let RPM (or the packages
> itself) ship a copy of all %config files somewhere in a place where they
> are safe and don't get modified. (2) When the user edited a %config file
> then let rpm on package update make a copy of the %config file from the
> *old* package into another save place
>
> Why that you ask? Simple, that way I can diff my current config file
> against the modified one it is based on (the one created in (2) above).
> Then I can take the current config file (the one from (1) above), copy
> it in place and (manually) apply the diff I created earlier.
>
> CU
> knurd
>
Seems like a good idea to me. But considering that config files are
relatively small, this would be best if done automatically.
Why not directly putting all the config files under a version control
system...
1:01 p.m.
On 7/30/07, Theodore Papadopoulo <Theodore.Papadopoulo(a)sophia.inria.fr> wrote:
Why not directly putting all the config files under a version
control
system...
Having the clean config files make it easier to manage them with
version control. They can be used for doing a three-way merge or for
making the vendor branch.
Instead of having rpm do the copy, it might make sense to have a hook.
The default hook would copy the files but somebody could have it call
a version control system.
- Ian
9:50 a.m.
Ian Burrell wrote:
Having the clean config files make it easier to manage them with
version control. They can be used for doing a three-way merge or for
making the vendor branch.
Instead of having rpm do the copy, it might make sense to have a hook.
The default hook would copy the files but somebody could have it call
a version control system.
Considering config files and orthogonally to the version control
proposal, a feature I would like to have is a way for
a rpm package to override some config files. I'm not sure if it is at
all feasible or even whether there is not
a tricky way to do it currently.
The use case is the "customisation" using rpms of a group of machine for
which it is needed to modify some config files
belonging to some other rpm. A maybe not too good example would be to
modify /etc/yum.repos.d/fedora*
to add eg some local mirror. Right now, this is impossible as those
files belong to the redhat-release package (as of FC5), so
pushing such a modification requires creating a new version of this
package, which is definitely not clean.
The attribute %config(noreplace) is of no use in such a case.
The idea would be something like this. Assume that package A.rpm owns a
config file A.conf. Extend
rpm so that it is possible to create a special package B.rpm (modifiers
rpms or overriders rpms ??) that just contains
modifiers or overriders of A.conf. A.conf remains owned by A.rpm. B.rpm
obviously should depend on A.rpm.
- If A.rpm is removed that means that B.rpm has to be removed.
- If A.rpm is updated, there should be a policy of how B.rpm should be
managed. The most flexible way would be
to allow the spec to decide among various options (block the upgrade,
reapply a patch, re-override the config file
or keep the new config file, remove B.rpm and emit a warning).
I do not know if this is at all feasible in a sensible way, but
something allowing the configuration of multiple machines
would really be helpful.
Theo.
11 a.m.
On 31/07/07, Theodore Papadopoulo <Theodore.Papadopoulo(a)sophia.inria.fr> wrote:
The use case is the "customisation" using rpms of a group
of machine for
which it is needed to modify some config files
belonging to some other rpm. A maybe not too good example would be to
modify /etc/yum.repos.d/fedora*
to add eg some local mirror. Right now, this is impossible as those
files belong to the redhat-release package (as of FC5), so
pushing such a modification requires creating a new version of this
package, which is definitely not clean.
This is a good use-case for basically replacing redhat-release with
your own locally-rolled config package (and presumably you'd have to
Provides: redhat-release = whatever).
The attribute %config(noreplace) is of no use in such a case.
It's good if you have it used in the package that provides an original
config that you then modify. The best option is of course a search
path for files, like the old XFILESEARCHPATH that libXt uses to find
app-defaults files and so on.
I do not know if this is at all feasible in a sensible way, but
something allowing the configuration of multiple machines
would really be helpful.
I do think you might look at repackaging some of the packages which
have files you want to override (basically adding a new Source[n] or
Patch[n] to the .spec and rebuild). However, what you're proposing
sounds pretty useful too.
Theo.
11:26 a.m.
* Theodore Papadopoulo [31/07/2007 18:05] :
Considering config files and orthogonally to the version control
proposal, a feature I would like to have is a way for
a rpm package to override some config files. I'm not sure if it is at
all feasible or even whether there is not
a tricky way to do it currently.
If the only use case is that of overwriting configuration files,
I'ld look into using SOAP or tools like cfengine to centralize policy.
Heck, CVS or Subversion will probably be up to the job.
The use case is the "customisation" using rpms of a group
of machine for
which it is needed to modify some config files
belonging to some other rpm. A maybe not too good example would be to
modify /etc/yum.repos.d/fedora*
to add eg some local mirror. Right now, this is impossible as those
files belong to the redhat-release package (as of FC5), so
pushing such a modification requires creating a new version of this
package, which is definitely not clean.
How is this not clean ?
Grab the .src.rpm, apply your changes, update the EVR, rebuild and put
the binary rpm in your private repo. I did this for years without any
problems.
It's a lot cleaner then the other solution which is to make
mirrors.fedoraproject.org point to an internal mirror through DNS
or /etc/hosts.
Emmanuel
7:02 a.m.
On Mon, 2007-07-30 at 11:25 +0200, Matthias Saou wrote:
Some automatic cache/copies of all %config files installed, with all
untouched versions always available. This would be very useful with
some simple tool to diff the current files(s) wit the backup(s), as
well as list all locally changed %config files. A sysadmin's dream
come true :-)
Well, this is exactly what I proposed as my second point in my
initial post on the subject:
https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01543.html
But since I got very little to it, I was afraid I was the only one
who sees the obvious advantage of having something like this built
into rpm.
Not only does it look amazingly useful, it also doesn't seem all
that complicated to implement. What I had in mind is say for any
%config file /a/path/to/the/file.cfg, a copy of the pristine file
should be made in /var/lib/rpm/backups/a/path/to/the/file.cfg or
something similar. If we have that, the rest is trivial to automate.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
11:05 a.m.
On 7/30/07, Matthias Saou
Some automatic cache/copies of all %config files installed, with all
untouched versions always available. This would be very useful with
some simple tool to diff the current files(s) wit the backup(s), as
well as list all locally changed %config files. A sysadmin's dream come
true :-)
actually.. now that i think about it... just having a centralized
lookup for rpmsave and rpmnew files rpm created for me as part of
transaction information would be keen. I hate having to troll the
filesystem just to build my own record of these files for later
archiving or garbage collecting.
-jef
3:14 p.m.
At 11:25 AM +0200 7/30/07, Matthias Saou wrote:
Panu Matilainen wrote :
> [...] So: what have you always wanted to do
> with rpm, but wasn't able to? Or the other way around: what you always
> wished rpm would do for you? What always annoyed you out of your mind?
After reading some of the other posts, I remembered something that has
often come up, which I would use extensively if it existed :
Some automatic cache/copies of all %config files installed, with all
untouched versions always available. This would be very useful with
some simple tool to diff the current files(s) wit the backup(s), as
well as list all locally changed %config files. A sysadmin's dream come
true :-)
As a sloppy sysadmin myself, I don't always remember to back up config
files before editing, so an automatic %config backup on RPM install /
upgrade would help me, and, I think, most other Linux users. On package
upgrade, I'd like the previous / original config file to be kept as well if
a .rpmnew file will be created for the actual config file (and the .rpmnew
file should not be created if the files are identical, though that is a
known tricky issue).
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
7:10 a.m.
Hi!
Small behavior change for obsoletes:
Issue an error if to be installed pkgs are obsoleted by already installed
pkgs. As obsoleting pkgs are logically newer "--oldpackage" should be
required to install the obsoleted pkg IMHO. Right now obsoleted pkgs are
happily installed.
Florian
12:07 p.m.
Florian Festi wrote:
Hi!
Small behavior change for obsoletes:
Issue an error if to be installed pkgs are obsoleted by already
installed pkgs. As obsoleting pkgs are logically newer "--oldpackage"
should be required to install the obsoleted pkg IMHO. Right now
obsoleted pkgs are happily installed.
There's an issue here, caused by the fact that obsoletes is not only
used to rename a package when the old one is going away forever (think
fileutils -> coreutils), but also to give a hint of package discovery
when the repo is replacing one package with a different work to provide
the same functionality.
The canonical concrete example here is routing daemons. Once upon a
time we shipped gated. Then it didn't get maintained very well, and
zebra came along. So zebra got "obsoletes: gated". Then zebra didn't
get it's share of maintenance upstream, but gated did. So gated got an
obsoletes on zebra. And now there's a loop.
If the obsoletes don't have version information in them (which is
generally preferred for the rename case), then there's a loop that your
criteria above can't solve.
This is part of why Conary puts packages in revision trees.
--
Peter
2:38 a.m.
Yes, I am aware of obsolete cycles and yes, they are a problem. But they are
a problem for yum and all other updating tools. For rpm the situation is
quite clear:
pkgs that are obsoleted by to be installed pkgs are silently removed. So the
circle - and the obsoleting pkg - are gone. Yum on the other side should
avoid that the two packages are exchanged on every "yum update" call
(package ping pong). But this is unrelated to be proposed behavior change as
it can only happen when there is no obsolete circle.
Florian
6:33 p.m.
One more thing that would be nice to take into consideration for rpm is
support for language packs or some way to install a limited set of
locales. We have traditionally kept our head in the sand, and said
rpm does not support this, disks are getting bigger anyway. But for
making useful live cds, something like this is pretty much indispensable
(considering that OOo with all locales is already bigger than one cd).
The existing %lang tag support might be almost good enough.
6:49 a.m.
On Sun, 5 Aug 2007, Matthias Clasen wrote:
One more thing that would be nice to take into consideration for rpm
is
support for language packs or some way to install a limited set of
locales. We have traditionally kept our head in the sand, and said
rpm does not support this, disks are getting bigger anyway. But for
making useful live cds, something like this is pretty much indispensable
(considering that OOo with all locales is already bigger than one cd).
The existing %lang tag support might be almost good enough.
Actually rpm does already support installing only a limited set of locales
via %{_install_langs} macro setting, and I think anaconda even set that to
match the selected languages at some point. It's just not that useful
since there's no way (apart from reinstalling with --force) to get back
any of the skipped languages.
Creating sub-packages for different locales doesn't suffer from that
problem but causes package (metadata) bloat...
- Panu -
7:55 a.m.
Panu Matilainen (pmatilai(a)redhat.com) said:
Actually rpm does already support installing only a limited set of
locales
via %{_install_langs} macro setting, and I think anaconda even set that to
match the selected languages at some point. It's just not that useful since
there's no way (apart from reinstalling with --force) to get back any of
the skipped languages.
Creating sub-packages for different locales doesn't suffer from that
problem but causes package (metadata) bloat...
Not just metadata bloat, there's manual maintenance on the metatdata
required, and requires wiring bits into every single installing tool to
handle them in any sort of sane manner.
Bill
8:11 a.m.
On Tue, 2007-08-07 at 14:49 +0300, Panu Matilainen wrote:
On Sun, 5 Aug 2007, Matthias Clasen wrote:
> One more thing that would be nice to take into consideration for rpm is
> support for language packs or some way to install a limited set of
> locales. We have traditionally kept our head in the sand, and said
> rpm does not support this, disks are getting bigger anyway. But for
> making useful live cds, something like this is pretty much indispensable
> (considering that OOo with all locales is already bigger than one cd).
>
> The existing %lang tag support might be almost good enough.
Actually rpm does already support installing only a limited set of locales
via %{_install_langs} macro setting, and I think anaconda even set that to
match the selected languages at some point. It's just not that useful
since there's no way (apart from reinstalling with --force) to get back
any of the skipped languages.
Thats what I meant with the existing support. What it is missing is that
rpm needs to track the installed and skipped locales per-package, and
some smart way to reinstall the relevant subset of packages when a new
locale is added to the system.
Creating sub-packages for different locales doesn't suffer from
that
problem but causes package (metadata) bloat...
Yeah, that is going to make the package database explode. Out of
interest, does the rpm database contain the %lang(<locale>) information
from the file lists, currently ?
8:33 a.m.
On Tue, 7 Aug 2007, Matthias Clasen wrote:
On Tue, 2007-08-07 at 14:49 +0300, Panu Matilainen wrote:
> On Sun, 5 Aug 2007, Matthias Clasen wrote:
>
>> One more thing that would be nice to take into consideration for rpm is
>> support for language packs or some way to install a limited set of
>> locales. We have traditionally kept our head in the sand, and said
>> rpm does not support this, disks are getting bigger anyway. But for
>> making useful live cds, something like this is pretty much indispensable
>> (considering that OOo with all locales is already bigger than one cd).
>>
>> The existing %lang tag support might be almost good enough.
>
> Actually rpm does already support installing only a limited set of locales
> via %{_install_langs} macro setting, and I think anaconda even set that to
> match the selected languages at some point. It's just not that useful
> since there's no way (apart from reinstalling with --force) to get back
> any of the skipped languages.
Thats what I meant with the existing support. What it is missing is that
rpm needs to track the installed and skipped locales per-package, and
some smart way to reinstall the relevant subset of packages when a new
locale is added to the system.
Yup.
> Creating sub-packages for different locales doesn't suffer
from that
> problem but causes package (metadata) bloat...
Yeah, that is going to make the package database explode. Out of
interest, does the rpm database contain the %lang(<locale>) information
from the file lists, currently ?
Sure - how else could it support the above to the extent it currently
does? :)
Something like this can be used to extract the info:
rpm -q --qf '[%{FILENAMES}\t%{FILELANGS}\n]' <package>
- Panu -
9:02 a.m.
On Tue, 2007-08-07 at 16:33 +0300, Panu Matilainen wrote:
On Tue, 7 Aug 2007, Matthias Clasen wrote:
> On Tue, 2007-08-07 at 14:49 +0300, Panu Matilainen wrote:
>> Actually rpm does already support installing only a limited set of locales
>> via %{_install_langs} macro setting, and I think anaconda even set that to
>> match the selected languages at some point. It's just not that useful
>> since there's no way (apart from reinstalling with --force) to get back
>> any of the skipped languages.
>
> Thats what I meant with the existing support. What it is missing is that
> rpm needs to track the installed and skipped locales per-package, and
> some smart way to reinstall the relevant subset of packages when a new
> locale is added to the system.
Yup.
>> Creating sub-packages for different locales doesn't suffer from that
>> problem but causes package (metadata) bloat...
>
> Yeah, that is going to make the package database explode. Out of
> interest, does the rpm database contain the %lang(<locale>) information
> from the file lists, currently ?
Sure - how else could it support the above to the extent it currently
does? :)
Something like this can be used to extract the info:
rpm -q --qf '[%{FILENAMES}\t%{FILELANGS}\n]' <package>
- Panu -
Just a heads up that deltarpm only works if the *whole* rpm is
installed. If any files are missing from the old rpm (i.e. anaconda's
excluded them because they're not the user's language), deltarpm will be
unable to rebuild the new rpm from the drpm, and yum will have to
download the full new rpm.
Jonathan
9:08 a.m.
On Tue, 2007-08-07 at 17:02 +0300, Jonathan Dieter wrote:
On Tue, 2007-08-07 at 16:33 +0300, Panu Matilainen wrote:
> On Tue, 7 Aug 2007, Matthias Clasen wrote:
> > On Tue, 2007-08-07 at 14:49 +0300, Panu Matilainen wrote:
> >> Actually rpm does already support installing only a limited set of locales
> >> via %{_install_langs} macro setting, and I think anaconda even set that to
> >> match the selected languages at some point. It's just not that useful
> >> since there's no way (apart from reinstalling with --force) to get
back
> >> any of the skipped languages.
> >
> > Thats what I meant with the existing support. What it is missing is that
> > rpm needs to track the installed and skipped locales per-package, and
> > some smart way to reinstall the relevant subset of packages when a new
> > locale is added to the system.
>
> Yup.
>
> >> Creating sub-packages for different locales doesn't suffer from that
> >> problem but causes package (metadata) bloat...
> >
> > Yeah, that is going to make the package database explode. Out of
> > interest, does the rpm database contain the %lang(<locale>) information
> > from the file lists, currently ?
>
> Sure - how else could it support the above to the extent it currently
> does? :)
>
> Something like this can be used to extract the info:
> rpm -q --qf '[%{FILENAMES}\t%{FILELANGS}\n]' <package>
>
> - Panu -
Just a heads up that deltarpm only works if the *whole* rpm is
installed. If any files are missing from the old rpm (i.e. anaconda's
excluded them because they're not the user's language), deltarpm will be
unable to rebuild the new rpm from the drpm, and yum will have to
download the full new rpm.
Technically, yes.
But if you have excluded language X from your installation, what are the
chance that you are interested in the delta for language X ? rpm will
still have enough information to construct the correct contents except
for the part that the user explicitly chose not to install...
9:26 a.m.
On Tue, 2007-08-07 at 10:08 -0400, Matthias Clasen wrote:
On Tue, 2007-08-07 at 17:02 +0300, Jonathan Dieter wrote:
> Just a heads up that deltarpm only works if the *whole* rpm is
> installed. If any files are missing from the old rpm (i.e. anaconda's
> excluded them because they're not the user's language), deltarpm will be
> unable to rebuild the new rpm from the drpm, and yum will have to
> download the full new rpm.
Technically, yes.
But if you have excluded language X from your installation, what are the
chance that you are interested in the delta for language X ? rpm will
still have enough information to construct the correct contents except
for the part that the user explicitly chose not to install...
Except that now you don't have the full RPM so you have no way to verify
that the package hasn't been tampered with
Jeremy
9:33 a.m.
On Tue, 2007-08-07 at 10:26 -0400, Jeremy Katz wrote:
On Tue, 2007-08-07 at 10:08 -0400, Matthias Clasen wrote:
> On Tue, 2007-08-07 at 17:02 +0300, Jonathan Dieter wrote:
> > Just a heads up that deltarpm only works if the *whole* rpm is
> > installed. If any files are missing from the old rpm (i.e. anaconda's
> > excluded them because they're not the user's language), deltarpm will
be
> > unable to rebuild the new rpm from the drpm, and yum will have to
> > download the full new rpm.
>
> Technically, yes.
> But if you have excluded language X from your installation, what are the
> chance that you are interested in the delta for language X ? rpm will
> still have enough information to construct the correct contents except
> for the part that the user explicitly chose not to install...
Except that now you don't have the full RPM so you have no way to verify
that the package hasn't been tampered with
Yeah, problems. But I'm sure we have the engineers to solve them...
10:34 a.m.
On Tue, 2007-08-07 at 10:33 -0400, Matthias Clasen wrote:
On Tue, 2007-08-07 at 10:26 -0400, Jeremy Katz wrote:
> On Tue, 2007-08-07 at 10:08 -0400, Matthias Clasen wrote:
> > On Tue, 2007-08-07 at 17:02 +0300, Jonathan Dieter wrote:
> > > Just a heads up that deltarpm only works if the *whole* rpm is
> > > installed. If any files are missing from the old rpm (i.e.
anaconda's
> > > excluded them because they're not the user's language), deltarpm
will be
> > > unable to rebuild the new rpm from the drpm, and yum will have to
> > > download the full new rpm.
> >
> > Technically, yes.
> > But if you have excluded language X from your installation, what are the
> > chance that you are interested in the delta for language X ? rpm will
> > still have enough information to construct the correct contents except
> > for the part that the user explicitly chose not to install...
>
> Except that now you don't have the full RPM so you have no way to verify
> that the package hasn't been tampered with
Yeah, problems. But I'm sure we have the engineers to solve them...
One way this could be done is to only gpg sign the rpm metadata. Where
metadata includes md5/sha sums of the files and the
ownership/permissions of the files.
Then rpm could have a switch to allow certain file types to be missing
from the archive (%lang, %doc).
-Toshio
11:21 a.m.
Toshio Kuratomi (a.badger(a)gmail.com) said:
One way this could be done is to only gpg sign the rpm metadata.
Where
metadata includes md5/sha sums of the files and the
ownership/permissions of the files.
Then rpm could have a switch to allow certain file types to be missing
from the archive (%lang, %doc).
Owwww.... that would seriously bloat the metadata. Not sure how much
you'd save if filelists suddenly becomes 100M.
Bill
9:24 a.m.
On Tue, 2007-08-07 at 09:11 -0400, Matthias Clasen wrote:
On Tue, 2007-08-07 at 14:49 +0300, Panu Matilainen wrote:
> On Sun, 5 Aug 2007, Matthias Clasen wrote:
>
> > One more thing that would be nice to take into consideration for rpm is
> > support for language packs or some way to install a limited set of
> > locales. We have traditionally kept our head in the sand, and said
> > rpm does not support this, disks are getting bigger anyway. But for
> > making useful live cds, something like this is pretty much indispensable
> > (considering that OOo with all locales is already bigger than one cd).
> >
> > The existing %lang tag support might be almost good enough.
>
> Actually rpm does already support installing only a limited set of locales
> via %{_install_langs} macro setting, and I think anaconda even set that to
> match the selected languages at some point. It's just not that useful
> since there's no way (apart from reinstalling with --force) to get back
> any of the skipped languages.
Thats what I meant with the existing support. What it is missing is that
rpm needs to track the installed and skipped locales per-package, and
some smart way to reinstall the relevant subset of packages when a new
locale is added to the system.
This isn't the painful part (it mostly worked the last time I tried) --
the painful part is that you now have to redownload the full package to
just add, eg, the German mo file. Without the full package, you can't
actually do any sort of sane verification that your download was correct
Jeremy
9:22 a.m.
On Fri, Jul 27, 2007 at 03:40:40PM +0300, Panu Matilainen wrote:
Not everybody is on rpm-maint list and we'd like to hear the
wishes of
(Fedora) developers/packagers too. So: what have you always wanted to do
with rpm, but wasn't able to? Or the other way around: what you always
wished rpm would do for you? What always annoyed you out of your mind?
I'd like to be able to really setup chroot w/o any root
privilegdes. This already works at 99% using
fakeroot/fakechroot. There is some code in rpm that didn't swallow the
fake environment. It didn't look too difficult to fix. :)
The application is very important: Currently any submitter can take
over any builder by placing some code in %post*/%pre* scripts and
making this package a BR of another package. Being root makes it easy
to escape the chroot and perform root operations at the builder level
(unless the builders are properly selinux protected).
A secondary benefit of fakeroot/fakechroot support would be that any
random student on any random Linux system could deploy a build system
under his account and produce nice rpm packages w/o the need for root
priviledges on these systems.
--
Axel.Thimm at ATrpms.net
9:26 a.m.
On Mon, 30 Jul 2007 16:22:08 +0200
Axel Thimm <Axel.Thimm(a)ATrpms.net> wrote:
I'd like to be able to really setup chroot w/o any root
privilegdes. This already works at 99% using
fakeroot/fakechroot. There is some code in rpm that didn't swallow the
fake environment. It didn't look too difficult to fix. :)
The application is very important: Currently any submitter can take
over any builder by placing some code in %post*/%pre* scripts and
making this package a BR of another package. Being root makes it easy
to escape the chroot and perform root operations at the builder level
(unless the builders are properly selinux protected).
A secondary benefit of fakeroot/fakechroot support would be that any
random student on any random Linux system could deploy a build system
under his account and produce nice rpm packages w/o the need for root
priviledges on these systems.
We'd like something like this for Koji as well (:
--
Jesse Keating
Release Engineer: Fedora
2:41 a.m.
On Mon, 30 Jul 2007, Axel Thimm wrote:
On Fri, Jul 27, 2007 at 03:40:40PM +0300, Panu Matilainen wrote:
> Not everybody is on rpm-maint list and we'd like to hear the wishes of
> (Fedora) developers/packagers too. So: what have you always wanted to do
> with rpm, but wasn't able to? Or the other way around: what you always
> wished rpm would do for you? What always annoyed you out of your mind?
I'd like to be able to really setup chroot w/o any root
privilegdes. This already works at 99% using
fakeroot/fakechroot. There is some code in rpm that didn't swallow the
fake environment. It didn't look too difficult to fix. :)
Got a reproducer case for this? (I'm just lazy and would like to avoid
having to re-investigate your findings from scratch :)
- Panu -
12:59 p.m.
It would be nice if rpmbuild could make noarch sub-packages when the
main package has an architecture. This would be useful for games and
other programs that have large data files in a single source archive.
If the data files are not arch-dependent, they could be put in a
noarch subpackage which would save space on the repositories.
Currently doing this requires building the subpackage from separate
source package.
- Ian
1:12 p.m.
On Fri, 27 Jul 2007 15:40:40 +0300 (EEST)
Panu Matilainen <pmatilai(a)redhat.com> wrote:
The more specific you can be, the better - "make it not
suck" isn't
productive. Of course there's no way everything can be done, we want
the next major release out before end of the decade... Also this is
not a voting where most votes guarantee implementation, but consider
it your chance to be heard. I'm listening... :)
Please allow ExcludeArch and ExclusiveArch to propagate into noarch
rpms. We have a multitude of noarch rpms (like python scripts and
such) that just plain won't work on some arches, but are themselves not
binary. We have ExcludeArch and ExclusiveArch in the spec file to
prevent them from being built in an arch where their BR or R wouldn't
be met, and we have compose tools that scrape this information out of
srpms at compose time, as the noarch rpm doesn't have this
information. If it were in the rpm itself it would be much easier for
compose tools to deal with.
--
Jesse Keating
Release Engineer: Fedora
1:29 p.m.
On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
The more specific you can be, the better - "make it not
suck" isn't
productive. Of course there's no way everything can be done, we want the
next major release out before end of the decade... Also this is not a
voting where most votes guarantee implementation, but consider it your
chance to be heard. I'm listening... :)
I would love the rpm header to be compressed. Some of the deltarpms
we've created have a large part of their filesize being the header
(think OOo with a release bump for a minor change); it would be nice if
it could be reduced some.
Jonathan
2:42 p.m.
Dnia 2007-07-27, o godz. 15:40:40 Panu Matilainen <pmatilai(a)redhat.com>
napisał(a):
What always annoyed you out of your mind?
Oh, two more things!
Let RPM forget about changelogs of packages, please. Let the changelog stay in
the spec, let yum/apt handle fetching it from some special file in the
repo, but keep it from being included in the binary package header and stored
in my system's rpmdb. For some people it's really a big waste of bandwidth and
disk space.
And the last annoyance - rpm really likes to become unusable, hanging forever
(repeating futex calls) on every run, but starting to work again when I remove
those /var/lib/rpm/__db.00* files. I've seen it so many times on so many
systems that I almost think it's meant to work that way.
Lam
7:27 a.m.
On Mon, 2007-07-30 at 21:42 +0200, Leszek Matok wrote:
Dnia 2007-07-27, o godz. 15:40:40 Panu Matilainen
<pmatilai(a)redhat.com>
napisał(a):
[...]
And the last annoyance - rpm really likes to become unusable, hanging
forever
(repeating futex calls) on every run, but starting to work again when I remove
those /var/lib/rpm/__db.00* files. I've seen it so many times on so many
systems that I almost think it's meant to work that way.
/+1.
- Gilboa
9:46 a.m.
On 8/1/07, Gilboa Davara <gilboad(a)gmail.com> wrote:
On Mon, 2007-07-30 at 21:42 +0200, Leszek Matok wrote:
> Dnia 2007-07-27, o godz. 15:40:40 Panu Matilainen <pmatilai(a)redhat.com>
> napisał(a):
>
[...]
> And the last annoyance - rpm really likes to become unusable, hanging forever
> (repeating futex calls) on every run, but starting to work again when I remove
> those /var/lib/rpm/__db.00* files. I've seen it so many times on so many
> systems that I almost think it's meant to work that way.
>
/+1.
For some reason, this seems to happen to me most often when I _don't_
use yum (and RPM by extension) often.
--
Fedora Core 6 and proud
1:49 a.m.
On 7/27/07, Panu Matilainen <pmatilai(a)redhat.com> wrote:
Hey all,
I know I'm opening up Pandoras box here but what the heck, it's Friday and
I'm feeling slightly bored...
Not sure if you've been keeping track, but I've attempted to build a
list of ideas brought forth. A few quick points
* I do not claim any authority over this list
* I do no claim this list to be complete
* there are a few suggestions I simply couldn't understand enough to
transfer to the list
* there are a few suggestions that were subjectively argued down and
so are not on the list
The wiki page is here:
http://fedoraproject.org/wiki/Tools/RPMForward
Feel free to edit, and I'll attempt to continue following this thread.
Peace
--
Fedora Core 6 and proud
2:32 a.m.
On Tue, 31 Jul 2007, Arthur Pemberton wrote:
On 7/27/07, Panu Matilainen <pmatilai(a)redhat.com> wrote:
>
> Hey all,
>
> I know I'm opening up Pandoras box here but what the heck, it's Friday and
> I'm feeling slightly bored...
Not sure if you've been keeping track, but I've attempted to build a
list of ideas brought forth. A few quick points
* I do not claim any authority over this list
* I do no claim this list to be complete
* there are a few suggestions I simply couldn't understand enough to
transfer to the list
* there are a few suggestions that were subjectively argued down and
so are not on the list
The wiki page is here:
http://fedoraproject.org/wiki/Tools/RPMForward
Feel free to edit, and I'll attempt to continue following this thread.
I intended to collect the items once the thread quietens, otherwise I'd
just forget at least half the suggestions in a week :) Seems you did at
least half the work for me already, thank you! I'll fill in details where
necessary...
- Panu -
2:59 a.m.
On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
Hey all,
I know I'm opening up Pandoras box here but what the heck, it's Friday and
I'm feeling slightly bored...
Not everybody is on rpm-maint list and we'd like to hear the
wishes of
(Fedora) developers/packagers too. So: what have you always wanted to do
with rpm, but wasn't able to? Or the other way around: what you always
wished rpm would do for you? What always annoyed you out of your mind?
* A usable c/c++-API.
The current one is scattered with anachronisms and historic artifacts.
* Usable API docs.
The current ones don't qualify as such.
* Buildable rpm sources.
I don't know if you meanwhile cleaned up the rpm.org repo, but last time
I checked, it was not even close to be buildable.
Ralf
3:20 a.m.
On Tue, 31 Jul 2007, Ralf Corsepius wrote:
On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
> Hey all,
>
> I know I'm opening up Pandoras box here but what the heck, it's Friday and
> I'm feeling slightly bored...
> Not everybody is on rpm-maint list and we'd like to hear the wishes of
> (Fedora) developers/packagers too. So: what have you always wanted to do
> with rpm, but wasn't able to? Or the other way around: what you always
> wished rpm would do for you? What always annoyed you out of your mind?
* A usable c/c++-API.
The current one is scattered with anachronisms and historic artifacts.
Heh, no s*** :) To quote Jeff (from memory so exact wording may differ):
"There are (at least) three ways to open rpmdb, none of which take path as
argument. RPM API is so baroque..."
And yes, cleaning up the API is one of rpm.org roadmap items, has been
from the start.
* Usable API docs.
The current ones don't qualify as such.
Yup. And what's actually useful in the current ones gets lost in the noise
of historic junk that's not supposed to be used etc...
* Buildable rpm sources.
I don't know if you meanwhile cleaned up the rpm.org repo, but last time
I checked, it was not even close to be buildable.
A fair bit of work has gone to cleaning up the build, practically all of
the compiler warnings (no less than ~650 of them when I started) from core
rpm code are gone and the auto*stuff has seen a bit of work too: "make
distcheck" now works and rpm itself can now be built with using %configure
macro. Lots of work remains before the build can be called "clean" though.
BTW Ralf, if you have any interest at all, your auto*tool expertise
would be very, very much appreciated at rpm.org.
- Panu -
3:52 a.m.
I'm not sure if this really has to do with RPM, but I'll put it out
subject to correction:
Is there currently any way for the end user to get a summary of what
the install scripts of an RPM actually do?
For example, is there any way to know that the mysql-server package:
* installs the mysql server, all necessary files, and helper applications
* installs basic documentation
* setups basic configuration
* setups mysql server for manual startup
* needs to have mysql admin password setup manually
Nothing to wordy, but something that a user could choose to view post
install (or maybe even pre) so they have a better idea of what's going
on.
--
Fedora Core 6 and proud
4:48 a.m.
On Tuesday 31 July 2007 10:52:03 Arthur Pemberton wrote:
Is there currently any way for the end user to get a summary of what
the install scripts of an RPM actually do?
Nothing to wordy, but something that a user could choose to view
post
install (or maybe even pre) so they have a better idea of what's going
on.
Is this what you want?
Post Install:
rpm --scripts -q mysql-server
Pre Install:
rpm --scripts -qp mysql-server*rpm
Regards,
Till
11:36 a.m.
On 7/31/07, Till Maas <opensource(a)till.name> wrote:
On Tuesday 31 July 2007 10:52:03 Arthur Pemberton wrote:
> Is there currently any way for the end user to get a summary of what
> the install scripts of an RPM actually do?
> Nothing to wordy, but something that a user could choose to view post
> install (or maybe even pre) so they have a better idea of what's going
> on.
Is this what you want?
Post Install:
rpm --scripts -q mysql-server
Pre Install:
rpm --scripts -qp mysql-server*rpm
Regards,
Till
Nice, but this wouldn't mean much to an end user, and aside from
chkconfig, I'm not sure how reliably we could covert it to written
language.
--
Fedora Core 6 and proud
4:41 a.m.
On Tue, 31 Jul 2007 11:25:40 +0200, dragoran wrote:
Panu Matilainen wrote:
>
>
> The more specific you can be, the better - "make it not suck" isn't
> productive.
what about not requiring the Buildrequires to be installed when doing
rpmbuild -bs ?
rpmbuild --nodeps -bs is available already
5:42 a.m.
Michael Schwendt wrote:
On Tue, 31 Jul 2007 11:25:40 +0200, dragoran wrote:
> Panu Matilainen wrote:
>
>>
>>
>> The more specific you can be, the better - "make it not suck" isn't
>> productive.
>>
> what about not requiring the Buildrequires to be installed when doing
> rpmbuild -bs ?
>
rpmbuild --nodeps -bs is available already
ok, thx didn't know that rpmbuild accepts --nodeps
2:38 p.m.
On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
I know I'm opening up Pandoras box here but what the heck,
it's Friday and
I'm feeling slightly bored...
I can't recall this having been brought up yet, but sometimes my memory
is spotty and it seems that the mail client's search function doesn't
work properly...
Anyway, if we're talking about huge changes in RPM, I'd like the 2GB
payload barrier to be gone. This will most probably mean having to get
rid of cpio as the underlying archive format as even with fixes in the
code, cpio can't handle more than 4GB (some 32bit integers used in the
format AFAIK). We have other archive formats that don't have this
limitation, so (ignoring compatibility issues of old RPM version with a
new format) I can't see compelling reasons why this shouldn't be
feasible.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little
Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
2:59 p.m.
On 8/1/07, Nils Philippsen <nphilipp(a)redhat.com> wrote:
Anyway, if we're talking about huge changes in RPM, I'd like
the 2GB
payload barrier to be gone.
Awesome, I'd love to just rebuild a fedora-universe package that
includes the equivalent of an everything install in one easy to use
rpm.
-jef"one rpm for the whole repository,is a much cleaner solution to
repeated scriplet actions than the post-tranaction garbage collection
concept. All of our users have gigabit fiber to a mirror
right?"spaleta
3:06 p.m.
On 8/1/07, Nils Philippsen <nphilipp(a)redhat.com> wrote:
On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote:
> I know I'm opening up Pandoras box here but what the heck, it's Friday and
> I'm feeling slightly bored...
I can't recall this having been brought up yet, but sometimes my memory
is spotty and it seems that the mail client's search function doesn't
work properly...
Anyway, if we're talking about huge changes in RPM, I'd like the 2GB
payload barrier to be gone. This will most probably mean having to get
rid of cpio as the underlying archive format as even with fixes in the
code, cpio can't handle more than 4GB (some 32bit integers used in the
format AFAIK). We have other archive formats that don't have this
limitation, so (ignoring compatibility issues of old RPM version with a
new format) I can't see compelling reasons why this shouldn't be
feasible.
Nils
Since someone started this, can someone brief me on the choice of cpio
vs. gz, bz2, etc?
I'm assuming it wasn't a random choice, and there was/is some
technical reason for it.
--
Fedora Core 6 and proud
3:17 p.m.
Arthur Pemberton <pemboa(a)gmail.com> wrote:
[...]
Since someone started this, can someone brief me on the choice of
cpio
vs. gz, bz2, etc?
I'm assuming it wasn't a random choice, and there was/is some
technical reason for it.
cpio is a real standard archive format (there are something like a half
dozen _different_ tar formats around) plus it is very simple.
gz, bz2, etc are file compression standards, that is completely
orthogonal to the packing. And yes, if we are looking for new RPM
features, perhaps a look at better compression would be in order...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
3:26 p.m.
Horst H. von Brand (vonbrand(a)inf.utfsm.cl) said:
cpio is a real standard archive format (there are something like a
half
dozen _different_ tar formats around) plus it is very simple.
gz, bz2, etc are file compression standards, that is completely
orthogonal to the packing. And yes, if we are looking for new RPM
features, perhaps a look at better compression would be in order...
bz2 makes things somewhat smaller, with a significant increase in
cpu time and memory usage; unknown how much that is worth it. rpm
already gzips the payload.
Bill
3:34 p.m.
Bill Nottingham wrote:
Horst H. von Brand (vonbrand(a)inf.utfsm.cl) said:
> cpio is a real standard archive format (there are something like a half
> dozen _different_ tar formats around) plus it is very simple.
>
> gz, bz2, etc are file compression standards, that is completely
> orthogonal to the packing. And yes, if we are looking for new RPM
> features, perhaps a look at better compression would be in order...
bz2 makes things somewhat smaller, with a significant increase in
cpu time and memory usage; unknown how much that is worth it.
I think someone from SUSE said it has not been worth the trouble to them
here previously.
Rahul
4:14 p.m.
On Wednesday 01 August 2007 22:26:36 Bill Nottingham wrote:
bz2 makes things somewhat smaller, with a significant increase in
cpu time and memory usage; unknown how much that is worth it. rpm
already gzips the payload.
LZMA[1], implemented in 7zip, seems to be a better choice than bzip2, but I
don't know, how high the benefits compared to gzip are.
Regards,
Till
[1] http://en.wikipedia.org/wiki/LZMA
4:29 p.m.
ons, 01 08 2007 kl. 23:14 +0200, skrev Till Maas:
On Wednesday 01 August 2007 22:26:36 Bill Nottingham wrote:
> bz2 makes things somewhat smaller, with a significant increase in
> cpu time and memory usage; unknown how much that is worth it. rpm
> already gzips the payload.
LZMA[1], implemented in 7zip, seems to be a better choice than bzip2, but I
don't know, how high the benefits compared to gzip are.
We can turn to our friends in the Ubuntu community for numbers as they
actually tested this a while back.
https://wiki.ubuntu.com/Dpkg7Zip
- David
4:36 p.m.
David Nielsen wrote:
ons, 01 08 2007 kl. 23:14 +0200, skrev Till Maas:
> LZMA[1], implemented in 7zip, seems to be a better choice than bzip2, but I
> don't know, how high the benefits compared to gzip are.
We can turn to our friends in the Ubuntu community for numbers as they
actually tested this a while back.
https://wiki.ubuntu.com/Dpkg7Zip
Although we ought to do our own testing. Ubuntu also said they saved a
ton of time by switching from bash to dash for initscripts, but our
testing showed no improvement.
4:46 p.m.
On Wed, 2007-08-01 at 16:26 -0400, Bill Nottingham wrote:
bz2 makes things somewhat smaller, with a significant increase in
cpu time and memory usage; unknown how much that is worth it. rpm
already gzips the payload.
bz2 is orders of magnitude slower than gzip. It tends to be worth it
with source tarballs, where bz2's compression is especially effective,
the bandwidth savings outweigh the slowness and you're usually not
dealing with gigabytes of data.
Now, installing an entire 4-6-10gb Fedora distro from bz2 will likely
stretch your install time to days on a mediocre machine, and weeks on a
slow one. Not worth it.
Other options are LZMA (http://tukaani.org/lzma/) which claims to be
compress better than bzip2, without being as slow. At least at
decompression.
LZO (http://www.oberhumer.com/opensource/lzo/) is specifically designed
for fast decompression speed, but it sounds like it doesn't beat
zip/DEFLATE's compression ratio.
And there's even an improved DEFLATE compressor from 7zip around,
(http://advancemame.sourceforge.net/comp-readme.html) now if someone
could just make it a drop in zlib replacement...
12:23 p.m.
Callum Lerwick wrote:
On Wed, 2007-08-01 at 16:26 -0400, Bill Nottingham wrote:
> bz2 makes things somewhat smaller, with a significant increase in
> cpu time and memory usage; unknown how much that is worth it. rpm
> already gzips the payload.
bz2 is orders of magnitude slower than gzip. It tends to be worth it
with source tarballs, where bz2's compression is especially effective,
the bandwidth savings outweigh the slowness and you're usually not
dealing with gigabytes of data.
Now, installing an entire 4-6-10gb Fedora distro from bz2 will likely
stretch your install time to days on a mediocre machine, and weeks on a
slow one. Not worth it.
I don't think you're right. For package (or whole OS) installation
we're mostly I/O bound, with some latency added by scriptlets. Some of
the scriptlets are cpu bound, but that doesn't matter in this context
since we're not decompressing things while the scriptlets run. In the
package installation scenario, rpm is basically piping the output of the
decompression into cpio -di . CPU time isn't really an issue; the
output is being limited by disk i/o. You're basically not going to be
cpu bound unless your target media is *extremely* fast. If you're in a
situation where that's the case, you're still going to get a faster
install than most users, so the decompression isn't really a point of pain.
--
Peter
2:17 a.m.
On Thu, 2007-08-02 at 13:23 -0400, Peter Jones wrote:
CPU time isn't really an issue; the
output is being limited by disk i/o. You're basically not going to be
cpu bound unless your target media is *extremely* fast.
... Have you ever used bzip2? It really is *that* slow. It can not keep
up with disk IO on any machine I've ever used.
2:36 a.m.
On Fri, 3 Aug 2007, Callum Lerwick wrote:
On Thu, 2007-08-02 at 13:23 -0400, Peter Jones wrote:
> CPU time isn't really an issue; the
> output is being limited by disk i/o. You're basically not going to be
> cpu bound unless your target media is *extremely* fast.
... Have you ever used bzip2? It really is *that* slow. It can not keep
up with disk IO on any machine I've ever used.
bzip2 also uses quite a bit more memory than gzip, might be an issue in
the somewhat constrained installer environment.
- Panu -
5:04 p.m.
On Wed, 2007-08-01 at 16:17 -0400, Horst H. von Brand wrote:
Arthur Pemberton <pemboa(a)gmail.com> wrote:
[...]
> Since someone started this, can someone brief me on the choice of cpio
> vs. gz, bz2, etc?
>
> I'm assuming it wasn't a random choice, and there was/is some
> technical reason for it.
cpio is a real standard archive format (there are something like a half
dozen _different_ tar formats around) plus it is very simple.
At the time only cpio was standardized. POSIX 2001 tar is probably
quite adequate by now. Certainly it's widely deployed on linux.
There are, of course, people who think using the same package manager
across multiple operating systems is an interesting exercise; those
people are insane.
- ajax
5:44 p.m.
Once upon a time, Adam Jackson <ajackson(a)redhat.com> said:
There are, of course, people who think using the same package
manager
across multiple operating systems is an interesting exercise; those
people are insane.
Hey, I still use rpm on Tru64 and Solaris!
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:23 p.m.
Once upon a time, Jesse Keating <jkeating(a)redhat.com> said:
On Wed, 1 Aug 2007 17:44:00 -0500
Chris Adams <cmadams(a)hiwaay.net> wrote:
> Hey, I still use rpm on Tru64 and Solaris!
Thus proving the point.
Me insane? That's unpossible!
Basically, since I build a bunch of my packages myself, it is a lot
easier to use one package tool (that I already know) rather than learn
two new ones. For a few packages (that I use in multiple places), I
build from the same SRPM on Linux, Tru64, and Solaris. About the only
OS-specific thing in the spec file is location of init scripts.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:23 a.m.
On Wed, Aug 01, 2007 at 06:04:07PM -0400, Adam Jackson wrote:
> cpio is a real standard archive format (there are something like
a half
> dozen _different_ tar formats around) plus it is very simple.
At the time only cpio was standardized. POSIX 2001 tar is probably
quite adequate by now. Certainly it's widely deployed on linux.
POSIX 2001 tar is an ugly horrible hack. What you have to understand
is that cpio is a really elegant archive format attached to a truely
braindead application (/bin/cpio) while tar is a mass of ugly multi-layered
hacks heaped on each other with a nice application.
For RPM the fact the internal format is cpio is a huge win for simple and
clean code (remember the archive parser is security sensitive), and it has no
weird padding issues to mess up signing. Erik picked cpio for the original
rpm package manager for very good reasons.
There are, of course, people who think using the same package
manager
across multiple operating systems is an interesting exercise; those
people are insane.
Well some of them are insane, successful and profitable in that case. Package
management is a fairly portable problem for the most part.
Alan
8:43 a.m.
Alan Cox wrote:
On Wed, Aug 01, 2007 at 06:04:07PM -0400, Adam Jackson wrote:
>> cpio is a real standard archive format (there are something like a half
>> dozen _different_ tar formats around) plus it is very simple.
> At the time only cpio was standardized. POSIX 2001 tar is probably
> quite adequate by now. Certainly it's widely deployed on linux.
POSIX 2001 tar is an ugly horrible hack. What you have to understand
is that cpio is a really elegant archive format attached to a truely
braindead application (/bin/cpio) while tar is a mass of ugly multi-layered
hacks heaped on each other with a nice application.
I'm pretty sure I remember a sysv version of cpio that produced archives
that other versions couldn't read (something about the maximum values of
device numbers), so I wouldn't say its design was perfect either.
--
Les Mikesell
lesmikesell(a)gmail.com
8:53 a.m.
On Thu, 2007-08-02 at 09:23 -0400, Alan Cox wrote:
POSIX 2001 tar is an ugly horrible hack. What you have to understand
is that cpio is a really elegant archive format attached to a truely
braindead application (/bin/cpio) while tar is a mass of ugly multi-layered
hacks heaped on each other with a nice application.
For RPM the fact the internal format is cpio is a huge win for simple and
clean code (remember the archive parser is security sensitive), and it has no
weird padding issues to mess up signing. Erik picked cpio for the original
rpm package manager for very good reasons.
What about extending the cpio format? Something called cpio2, perhaps.
The main problem with using cpio is that individual files have a limit
of 2GB (which isn't a problem in most cases, but it is a limit). Why
not push a newer cpio format that changes all 16-bit and 32-bit records
to 64-bit (along with specifying endienness)?
Put that together with a command-line program that actually makes sense
(I spent more time learning how to use the stupid cpio application than
any other single task when working with deltarpms), and we may have
something that maintains the simplicity of the cpio format without the
limitations.
I don't mind putting the application (and possibly a library) together
if there's some chance rpm will use it.
Jonathan
9:19 a.m.
Hi.
On Thu, 02 Aug 2007 16:53:43 +0300, Jonathan Dieter wrote:
The main problem with using cpio is that individual files have a
limit
of 2GB (which isn't a problem in most cases, but it is a limit). Why
not push a newer cpio format that changes all 16-bit and 32-bit
records to 64-bit (along with specifying endienness)?
What exactly is the use case of files larger than 2GB wrt RPM?
I just do not see the need for this.
9:43 a.m.
On Thu, 2007-08-02 at 16:19 +0200, Ralf Ertzinger wrote:
On Thu, 02 Aug 2007 16:53:43 +0300, Jonathan Dieter wrote:
> The main problem with using cpio is that individual files have a limit
> of 2GB (which isn't a problem in most cases, but it is a limit). Why
> not push a newer cpio format that changes all 16-bit and 32-bit
> records to 64-bit (along with specifying endienness)?
What exactly is the use case of files larger than 2GB wrt RPM?
I just do not see the need for this.
I work in a school that is planning on moving all of its desktops to
Fedora 7 by the beginning of the upcoming school year. There are
occasional times that another operating system may be needed, so we've
decided to use qemu-kvm to run this other operating system.
It would be quite convenient for us to package a virtual hard drive into
an rpm so that we can deploy it along with a .desktop file inserted into
the menu as needed on the Fedora systems.
Packaging it as an rpm would also help in keeping track of what
"version" of the virtual hard drive is on each real machine. If we
decide to add a new program to the virtual hard drive, we could bump the
version and rebuild the rpm. All systems with the old rpm would get the
new one during their nightly yum update.
Granted, it's not a common use case, but it is a use case.
Jonathan
10:26 a.m.
Hi.
On Thu, 02 Aug 2007 17:43:29 +0300, Jonathan Dieter wrote:
Packaging it as an rpm would also help in keeping track of what
"version" of the virtual hard drive is on each real machine. If we
decide to add a new program to the virtual hard drive, we could bump
the version and rebuild the rpm. All systems with the old rpm would
get the new one during their nightly yum update.
Especially since the virtual machines modify the drive image, thus
an update kills all modifications to the image.
10:50 a.m.
On Thu, 2007-08-02 at 17:26 +0200, Ralf Ertzinger wrote:
Hi.
On Thu, 02 Aug 2007 17:43:29 +0300, Jonathan Dieter wrote:
> Packaging it as an rpm would also help in keeping track of what
> "version" of the virtual hard drive is on each real machine. If we
> decide to add a new program to the virtual hard drive, we could bump
> the version and rebuild the rpm. All systems with the old rpm would
> get the new one during their nightly yum update.
Especially since the virtual machines modify the drive image, thus
an update kills all modifications to the image.
The hard drive images are read-only; all data is stored on a network
drive.
Jonathan
10:52 a.m.
On Thu, 2007-08-02 at 17:26 +0200, Ralf Ertzinger wrote:
Hi.
On Thu, 02 Aug 2007 17:43:29 +0300, Jonathan Dieter wrote:
> Packaging it as an rpm would also help in keeping track of what
> "version" of the virtual hard drive is on each real machine. If we
> decide to add a new program to the virtual hard drive, we could bump
> the version and rebuild the rpm. All systems with the old rpm would
> get the new one during their nightly yum update.
Especially since the virtual machines modify the drive image, thus
an update kills all modifications to the image.
I should probably clarify my previous post. The hard drive images are
readonly, and we use qemu-kvm -snapshot, so all changes are lost when
the machine is shut down anyway.
Jonathan
12:09 p.m.
On 8/2/07, Ralf Ertzinger <fedora(a)camperquake.de> wrote:
Hi.
On Thu, 02 Aug 2007 16:53:43 +0300, Jonathan Dieter wrote:
> The main problem with using cpio is that individual files have a limit
> of 2GB (which isn't a problem in most cases, but it is a limit). Why
> not push a newer cpio format that changes all 16-bit and 32-bit
> records to 64-bit (along with specifying endienness)?
What exactly is the use case of files larger than 2GB wrt RPM?
I just do not see the need for this.
Seems like computer history has taught us that this is a bad reason to
not extend something.
--
Fedora Core 6 and proud
1:57 p.m.
Arthur Pemberton wrote:
On 8/2/07, Ralf Ertzinger <fedora(a)camperquake.de> wrote:
> Hi.
>
> On Thu, 02 Aug 2007 16:53:43 +0300, Jonathan Dieter wrote:
>
>> The main problem with using cpio is that individual files have a limit
>> of 2GB (which isn't a problem in most cases, but it is a limit). Why
>> not push a newer cpio format that changes all 16-bit and 32-bit
>> records to 64-bit (along with specifying endienness)?
> What exactly is the use case of files larger than 2GB wrt RPM?
>
> I just do not see the need for this.
Seems like computer history has taught us that this is a bad reason to
not extend something.
Exactly! Did you ever wonder what unix would have been like if it only
supported the operations where Ken Thompson had been given a use case?
"Rule of Extensibility: Design for the future, because it will be here
sooner than you think"
--
Les Mikesell
lesmikesell(a)gmail.com
12:37 p.m.
Ralf Ertzinger wrote:
Hi.
On Thu, 02 Aug 2007 16:53:43 +0300, Jonathan Dieter wrote:
> The main problem with using cpio is that individual files have a limit
> of 2GB (which isn't a problem in most cases, but it is a limit). Why
> not push a newer cpio format that changes all 16-bit and 32-bit
> records to 64-bit (along with specifying endienness)?
What exactly is the use case of files larger than 2GB wrt RPM?
Believe it or not, I know of one piece of software with a 3GB (compiled)
regular expression automaton. Though it'll never be a candidate for a
package in Fedora, it'd still be nice if the vendor could package it in
rpm. The same is true for large datasets.
Frankly, it's useful for all the same reasons as having support for >2GB
files *at all* in the OS.
--
Peter
1:14 p.m.
Peter Jones wrote:
Ralf Ertzinger wrote:
> Hi.
>
> On Thu, 02 Aug 2007 16:53:43 +0300, Jonathan Dieter wrote:
>
>> The main problem with using cpio is that individual files have a limit
>> of 2GB (which isn't a problem in most cases, but it is a limit). Why
>> not push a newer cpio format that changes all 16-bit and 32-bit
>> records to 64-bit (along with specifying endienness)?
>
> What exactly is the use case of files larger than 2GB wrt RPM?
Believe it or not, I know of one piece of software with a 3GB (compiled)
regular expression automaton. Though it'll never be a candidate for a
package in Fedora, it'd still be nice if the vendor could package it in
rpm. The same is true for large datasets.
I could see this being useful at some point in the future with something like
nasa whirlwind and large sat imagery databases. Currently I suspect such users
of massive datasets are quite happy managing their own multi terabyte
collections of various data provided from various sources. But I suppose if you
keep in mind the 1.44MB floppy -> $10 1GB microsd-usb path, you also should keep
in mind that we aren't so far away from a 10T laptop, perhaps holding 1T of
public sat imagery displayable via whirlwind, just because it's cool and free.
(except for cheney's house of course). And probably by that time, if possible,
people would enjoy managing their various sat imagery layers with the same
package management tool as the rest of their system.
And of course then their are video games with datasets that large, or perhaps
just depending on the ubiquitous free nasa whirlwind datasets.
But of course then someone will make a video game that simulates terrorism, or
even global thermonuclear war, and the feds will have to crack down on this new
'virtual terrorism training ground' ;)
-dmc
Frankly, it's useful for all the same reasons as having support
for >2GB
files *at all* in the OS.
9:20 a.m.
On Thu, Aug 02, 2007 at 04:53:43PM +0300, Jonathan Dieter wrote:
What about extending the cpio format? Something called cpio2,
perhaps.
The main problem with using cpio is that individual files have a limit
of 2GB (which isn't a problem in most cases, but it is a limit). Why
not push a newer cpio format that changes all 16-bit and 32-bit records
to 64-bit (along with specifying endienness)?
Actually the cpio format used in rpm is 'newc', which encodes
all values as 8 ASCII bytes of hex. So it's a 4 GB size limit.
But, as already said, it's not just the cpio format you'd have
to extend, it's also rpm's header data.
Cheers,
Michael.
--
Michael Schroeder mls(a)suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
9:48 a.m.
On Thu, 2007-08-02 at 16:20 +0200, Michael Schroeder wrote:
On Thu, Aug 02, 2007 at 04:53:43PM +0300, Jonathan Dieter wrote:
> What about extending the cpio format? Something called cpio2, perhaps.
>
> The main problem with using cpio is that individual files have a limit
> of 2GB (which isn't a problem in most cases, but it is a limit). Why
> not push a newer cpio format that changes all 16-bit and 32-bit records
> to 64-bit (along with specifying endienness)?
Actually the cpio format used in rpm is 'newc', which encodes
all values as 8 ASCII bytes of hex. So it's a 4 GB size limit.
But, as already said, it's not just the cpio format you'd have
to extend, it's also rpm's header data.
Cheers,
Michael.
Fair enough, though 4 GB may not be large enough when we're talking
virtual hard drives (see message just posted a minute ago).
And, yes, there wouldn't be much point in extending the cpio format if
we didn't fix the rpm header as well. But I wouldn't see much point in
extending the cpio format if rpm wasn't going to use it.
Jonathan
12:38 p.m.
Michael Schroeder wrote:
On Thu, Aug 02, 2007 at 04:53:43PM +0300, Jonathan Dieter wrote:
> What about extending the cpio format? Something called cpio2, perhaps.
>
> The main problem with using cpio is that individual files have a limit
> of 2GB (which isn't a problem in most cases, but it is a limit). Why
> not push a newer cpio format that changes all 16-bit and 32-bit records
> to 64-bit (along with specifying endienness)?
Actually the cpio format used in rpm is 'newc', which encodes
all values as 8 ASCII bytes of hex. So it's a 4 GB size limit.
But, as already said, it's not just the cpio format you'd have
to extend, it's also rpm's header data.
Extending the header data is a quite solvable; I don't think it's even
all that difficult. There was discussion about it more than a year ago,
with several options proposed. One was even backward compatible.
--
Peter
5:17 a.m.
On Wed, Aug 01, 2007 at 09:38:28PM +0200, Nils Philippsen wrote:
Anyway, if we're talking about huge changes in RPM, I'd like
the 2GB
payload barrier to be gone. This will most probably mean having to get
rid of cpio as the underlying archive format as even with fixes in the
code, cpio can't handle more than 4GB (some 32bit integers used in the
format AFAIK).
It's the size of single files that is limited in cpio. The archive
size is unlimited, as cpio just concatenates single file entries.
OTOH, rpm uses a couple of header elements like RPMSIGTAG_SIZE and
RPMSIGTAG_PAYLOADSIZE which are 32bit integers.
Cheers,
Michael.
--
Michael Schroeder mls(a)suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
9:12 a.m.
Another thought:
It would be nice if subpackages were permitted to be noarch, while the
main package is not.
~spot
9:45 a.m.
Panu Matilainen wrote:
Not everybody is on rpm-maint list and we'd like to hear the
wishes of
(Fedora) developers/packagers too. So: what have you always wanted to do
with rpm, but wasn't able to? Or the other way around: what you always
wished rpm would do for you? What always annoyed you out of your mind?
This came up yesterday, so it's fresh in my mind. It'd be nice to have
a mechanism for ordering constraints that didn't double as a package
discovery mechanism. That is, "Antecedent: foo" rather than "Requires:
foo", where the the former is only used by tsort, and if the package is
absent the ts will still pass a dep check.
The specific case is the ordering during installation; if you're using
e.g. iscsi, then we need this (fragment) install ordering:
iscsi-initiator-utils
mkinitrd
kernel
But we don't want mkinitrd to actually depend on iscsi-initiator-utils;
it shouldn't normally get installed unless you're actually using it.
--
Peter
9:47 a.m.
Panu Matilainen (pmatilai(a)redhat.com) said:
The more specific you can be, the better - "make it not
suck" isn't
productive. Of course there's no way everything can be done, we want the
next major release out before end of the decade... Also this is not a
voting where most votes guarantee implementation, but consider it your
chance to be heard. I'm listening... :)
Multiple concurrent database writers!
Bill
11:14 a.m.
Panu Matilainen wrote:
Not everybody is on rpm-maint list and we'd like to hear the
wishes of
(Fedora) developers/packagers too. So: what have you always wanted to do
with rpm, but wasn't able to? Or the other way around: what you always
wished rpm would do for you? What always annoyed you out of your mind?
It'd be nice to move away from signatures on packages, towards
certificates which are signed and contain a cryptographic sum and a data
blob. That would allow for multiple signatures that specify their
purpose directly, rather than inferring multiple purposes from a
signature that merely specifies that the contents haven't changed.
--
Peter
4:46 a.m.
On Fr Juli 27 2007, Panu Matilainen wrote:
Not everybody is on rpm-maint list and we'd like to hear the
wishes of
(Fedora) developers/packagers too. So: what have you always wanted to do
with rpm, but wasn't able to? Or the other way around: what you always
wished rpm would do for you? What always annoyed you out of your mind?
Another nice feature would be to have all Scriptlets from
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets that are used in
other distros, too, to be available in rpm directly. E.g. instead of having
to copy the code from there, rpm could automatically detect whether or not an
desktop, mimeinfo, shared library, font, icon or texinfo file was installed
or removed and run the appropiate scriptlet. Also having macros that can be
used in %file, that work like %doc for documentation, but for the some of the
filetypes above would be nice, too.
E.g.
%desktopfile %SOURCE1
would copy %SOURCE1 where desktopfiles belong, rename it to %name.desktop and
run the needed scriptlets. For icons and maybe mimeinfo, this may be useful,
too. And also for selinux files, so that they are installed and updated
correctly.
Also it would be nice when there would be some macro that expands to
$RPM_BUILD_ROOT%{_libdir} but is shorter or even better when %{_libdir}
expands to $RPM_BUILD_ROOT%{_libdir} in %install but to %{_libdir} everywhere
else.
Regards,
Till
9:52 a.m.
Le vendredi 27 juillet 2007 à 15:40 +0300, Panu Matilainen a écrit :
So: what have you always wanted to do
with rpm, but wasn't able to?
True strong dependency versionning, including actual version ranges
( [A;B[ not ]-∞;B[ and [A;+∞[ ), arch-specific contraints, and working
on virtual provides.
Ability to declare noarch subpackages for doc and noarch resources
Regards,
--
Nicolas Mailhot
6099
days inactive
6115
days old
223 comments
67 participants
participants (67)
-
Adam Jackson -
Alan Cox -
Alexander Boström -
Arthur Pemberton -
Axel Thimm -
Bill Crawford -
Bill Nottingham -
Bruno Wolff III -
Callum Lerwick -
Chris Adams -
Christopher Aillon -
Colin Walters -
David Malcolm -
David Nielsen -
David Woodhouse -
Dimi Paun -
Douglas McClendon -
drago01 -
Emmanuel Seyman -
Erich Zigler -
Florian Festi -
Gilboa Davara -
Horst H. von Brand -
Ian Burrell -
Jason L Tibbitts III -
Jef Spaleta -
Jeremy Katz -
Jeremy Sanders -
Jesse Keating -
Jonathan Dieter -
Kevin Kofler -
Lennert Buytenhek -
Les Mikesell -
Leszek Matok -
Manuel Wolfshant -
Martin Marques -
Matthew Miller -
Matthias Clasen -
Matthias Saou -
Michael DeHaan -
Michael Schroeder -
Michael Schwendt -
Mike Chambers -
n0dalus -
Nicolas Chauvet -
Nicolas Mailhot -
Nils Philippsen -
Owen Taylor -
Panu Matilainen -
Panu Matilainen -
Peter Jones -
Rahul Sundaram -
Ralf Corsepius -
Ralf Ertzinger -
Rex Dieter -
Robert Scheck -
seth vidal -
Theodore Papadopoulo -
Thorsten Leemhuis -
Till Maas -
Tom Callaway -
Tony Nelson -
Topher -
Toshio Kuratomi -
Ville Skyttä -
Will Woods -
ZC Miao