[Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference
Thorsten Leemhuis
fedora at leemhuis.info
Wed Aug 16 14:18:28 UTC 2006
Ville Skyttä schrieb:
> On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote:
> and that the
> scope of the discussion needs to be limited to whether uname-r gets
> moved to the packages' names and its direct unavoidable consequences --
> the only real technical design issue.
I agree that this is the only "only real technical design issue" of the
current standard. But I'd don't think that we hastily should change this
detail. Two weeks should be enough to look at this precise problem
closer and work out and test the solutions (one solution of course is
uname-r, but I *currently* think it's not the best one -- especially not
for RHEL, where the uname -r might be confusing). I roughly another way
how this might be fixed in
https://www.redhat.com/archives/fedora-packaging/2006-August/msg00086.html
already.
> Everything else in the "kmdl"
> proposal is more or less cosmetics and implementation details, and
> adopting it would mean throwing away quite a bit of
s/a bit/a lot of/ IMHO -- it were probably around 15 to 20 IRC meetings
IIRC (probably even more) and a lot of traffic on the mailinglists where
FESCo (including jeremy and spot) discussed each and every detail in
depth. We even evaluated most of the stuff that's made different in the
kmdl scheme during that phase. We for example looked at a debuginfo
solution similar to the one in Axels kmdls and chose not to use it; we
looked at a one srpm approach for both userland and kernel-module and
decided to split. That are -- as scop outlined above -- implementation
details that are already used in some packages in Extras, under Review
for Extras and another repo that's using the same scheme. We IMHO
shouldn't change them without a good reason.
> work (reinventing
> the wheel from the POV of the current scheme and its adopters) from
> several parties for questionable gain.
Otherwise I'm strongly in agreement with that paragraph.
[...]
CU
thl
More information about the Fedora-packaging
mailing list