From bugs.michael at gmx.net Mon Oct 2 08:58:09 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 2 Oct 2006 10:58:09 +0200 Subject: [Fedora-packaging] libtool(.la) archive policy proposal In-Reply-To: <45194CF5.3090509@math.unl.edu> References: <45194CF5.3090509@math.unl.edu> Message-ID: <20061002105809.953ca213.bugs.michael@gmx.net> On Tue, 26 Sep 2006 10:53:25 -0500, Rex Dieter wrote: > See > http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives > > Comments? Better. Originally we just didn't take the time to cover and explain corner-cases, because the longer it gets, the less easy it becomes for new contributors. As a strict "MUST NOT" it is still insufficient, as it may happen that an application still uses an old libtool ltdl to link libtool archives at run-time. You simply cannot avoid the lengthy discussion about the pitfalls of including linkable libtool archives (as outlined in the foot-note) and the consequences of exluding them or removing them when it's too late. It's similar to the "*.so -> devel" problem, which is not understood widely yet either and cannot be covered sufficiently with a one-line policy. /lib is included in run-time linker's standard search path, too, btw. From Axel.Thimm at ATrpms.net Mon Oct 2 10:32:12 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 2 Oct 2006 12:32:12 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <45194CF5.3090509@math.unl.edu> References: <45194CF5.3090509@math.unl.edu> Message-ID: <20061002103212.GK28594@neu.nirvana> On Tue, Sep 26, 2006 at 10:53:25AM -0500, Rex Dieter wrote: > See > http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives > > Comments? > > -- Rex > | Here's a crazy-but-not-too-far-from-reality example: Build shared-lib | pkg 'b' which links against 'a'. b's .la files now include references | to 'liba.la' (so now depends on it). Build shared-lib pkg 'c' which | links against 'b', whose own libc.la file includes | references(+dependancy) on libb.la. Rinse, lather, repeat. You'll end | up with a pkg z, and a libz.la, which, when all is said and done, | | * will have a direct dependancy upon y's liby.la | * and because of liby.la file references/dependances, will have | (indirect) dependancies upon liba.la, libb.la, ..., libx.la | | When, generally, *none* of these are really required nor desired. I'm not sure about that, but maybe I understand something wrongly: - If -la was needed for building libb, then there exists a real dependency between liba and libb and libb.la is correct about that. - If -la was unneccessary in building libb, libb.la will indeed contain an unneccessary reference to liba. But that should be considered a bug in the build of libb, or not? Fixing that bug may also ease on the BuildRequires, so we should really be interested in fixing such bugs. In this simplistic view, *.la's are either in order, or there's a bug that we'd like to remove anyway. From a different view: *.la files aren't much different than *.pc files, in fact they contain a subset of their information. One wouldn't argue to remove all *.pc files because some may contain too many references to libs. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Mon Oct 2 11:31:04 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 2 Oct 2006 13:31:04 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061002103212.GK28594@neu.nirvana> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> Message-ID: <20061002133104.a9332604.bugs.michael@gmx.net> On Mon, 2 Oct 2006 12:32:12 +0200, Axel Thimm wrote: > | Here's a crazy-but-not-too-far-from-reality example: Build shared-lib > | pkg 'b' which links against 'a'. b's .la files now include references > | to 'liba.la' (so now depends on it). Build shared-lib pkg 'c' which > | links against 'b', whose own libc.la file includes > | references(+dependancy) on libb.la. Rinse, lather, repeat. You'll end > | up with a pkg z, and a libz.la, which, when all is said and done, > | > | * will have a direct dependancy upon y's liby.la > | * and because of liby.la file references/dependances, will have > | (indirect) dependancies upon liba.la, libb.la, ..., libx.la > | > | When, generally, *none* of these are really required nor desired. > > I'm not sure about that, but maybe I understand something wrongly: > > - If -la was needed for building libb, then there exists a real > dependency between liba and libb and libb.la is correct about that. So far so good. But here, mixing of build-time and run-time dependencies starts. Run-time deps enter the build-time dep-chain. Add Rex's "c" to the set. "c", which needs just "b" at build-time, sees the indirect dep on "a" (=> liba.la) through libb.la. libb-devel needs to "Requires: liba-devel" just because of a .la dependency. At build-time, shared-lib "c", which only requires libb, links via libb.la, which in turn needs liba.la (because libb.la lists it as a dependency). And it creates in libfoo.la the more complex libb.la -> liba.la dep-chain. Application "foo", which needs only libfoo, now also needs libb.la + liba.la when the linking is done via libfoo.la instead of just -lfoo. The BuildRequires pile up -- unless the packagers fix them bottom-up because they examine the new .la file(s). If they don't, wrong BR move up in the dep-chain. Guess what happens if libfoo is upgraded and now build-requires libd.la. This requires additional BR in "foo", although "foo" doesn't depend on libd directly. Worse, libtool inter-library dependencies often are hardcoded as absolute paths, e.g. /usr/lib/liba.la. Removal of any .la from the entire dep-chain bears a very big risk of requiring a rebuild of the entire dep-chain bottom-up plus pruning the spec BR/Reqs, also bottom-up. > From a different view: *.la files aren't much different than *.pc > files, in fact they contain a subset of their information. One > wouldn't argue to remove all *.pc files because some may contain too > many references to libs. These are broken and partially have their origin in "extreme static linking". (For static linking you need the full chain of -lfoo arguments, as everything else would result in missing symbols). pkgconfig "Requires" in libfoo.pc should list the options that are needed to build with libfoo, NOT the options that were used to build libfoo. With sane linking, the shared libfoo has a run-time dep already on any other libs it needs and is linked against, e.g. liba and libb, so adding -la -lb and so on is not needed when linking shared against -lfoo. From rc040203 at freenet.de Mon Oct 2 10:35:05 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 02 Oct 2006 12:35:05 +0200 Subject: [Fedora-packaging] libtool(.la) archive policy proposal In-Reply-To: <45194CF5.3090509@math.unl.edu> References: <45194CF5.3090509@math.unl.edu> Message-ID: <1159785305.13363.218.camel@mccallum.corsepiu.local> On Tue, 2006-09-26 at 10:53 -0500, Rex Dieter wrote: > See > http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives > > Comments? -INF It's a fault to remove *.la's. Ralf From enrico.scholz at informatik.tu-chemnitz.de Mon Oct 2 12:11:58 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 02 Oct 2006 14:11:58 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061002103212.GK28594@neu.nirvana> (Axel Thimm's message of "Mon, 2 Oct 2006 12:32:12 +0200") References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> Message-ID: <87ven2q5m9.fsf@kosh.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: > | Here's a crazy-but-not-too-far-from-reality example: Build shared-lib > | pkg 'b' which links against 'a'. b's .la files now include references > | to 'liba.la' (so now depends on it). Build shared-lib pkg 'c' which > | links against 'b', whose own libc.la file includes > | references(+dependancy) on libb.la. Rinse, lather, repeat. You'll end > | up with a pkg z, and a libz.la, which, when all is said and done, > | > | * will have a direct dependancy upon y's liby.la > | * and because of liby.la file references/dependances, will have > | (indirect) dependancies upon liba.la, libb.la, ..., libx.la > | > | When, generally, *none* of these are really required nor desired. > > I'm not sure about that, but maybe I understand something wrongly: > > - If -la was needed for building libb, then there exists a real > dependency between liba and libb and libb.la is correct about that. No, this dependency does not need to be handled explicitly with dynamic libraries. E.g. a dep-tree of liba.so -> libb.so -> libc.so -> app would suffice. Having the '-la' in libb.la and '-lb' in libc.la would cause a tree like --------------------------- / ,---------------- \ / / `v v liba.so -> libb.so -> libc.so -> app \ ^ `----------------' Unfortunately, widely used tools like 'libtool' or 'cmake' are creating such trees (at least when the libs and apps are in the same project). For 'cmake' there is a workaround to put '-Wl,--as-needed' into the linker flags but for 'libtool' you have to patch ltmain. A good check to verify cleaness of libraries/binaries is | ldd -u -r This should neither output undefined symbols nor unused direct dependencies. > From a different view: *.la files aren't much different than *.pc > files, in fact they contain a subset of their information. ACK. Often, 'pkgconfig' is used wrongly and contains superflous Requires: resulting into a tree like above. 'pkgconfig' might make sense in providing certain C(PP)FLAGS; but .la files are completely superflous (at least for for dynamic linking). Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Oct 2 12:37:03 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 2 Oct 2006 14:37:03 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <87ven2q5m9.fsf@kosh.bigo.ensc.de> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> Message-ID: <20061002123703.GA13434@neu.nirvana> On Mon, Oct 02, 2006 at 02:11:58PM +0200, Enrico Scholz wrote: > Axel.Thimm at ATrpms.net (Axel Thimm) writes: > > > | Here's a crazy-but-not-too-far-from-reality example: Build shared-lib > > | pkg 'b' which links against 'a'. b's .la files now include references > > | to 'liba.la' (so now depends on it). Build shared-lib pkg 'c' which > > | links against 'b', whose own libc.la file includes > > | references(+dependancy) on libb.la. Rinse, lather, repeat. You'll end > > | up with a pkg z, and a libz.la, which, when all is said and done, > > | > > | * will have a direct dependancy upon y's liby.la > > | * and because of liby.la file references/dependances, will have > > | (indirect) dependancies upon liba.la, libb.la, ..., libx.la > > | > > | When, generally, *none* of these are really required nor desired. > > > > I'm not sure about that, but maybe I understand something wrongly: > > > > - If -la was needed for building libb, then there exists a real > > dependency between liba and libb and libb.la is correct about that. > > No, this dependency does not need to be handled explicitly with dynamic > libraries. > > E.g. a dep-tree of > > liba.so -> libb.so -> libc.so -> app > > would suffice. Having the '-la' in libb.la and '-lb' in libc.la would > cause a tree like > > --------------------------- > / ,---------------- \ > / / `v v > liba.so -> libb.so -> libc.so -> app > \ ^ > `----------------' > > > Unfortunately, widely used tools like 'libtool' or 'cmake' are creating > such trees (at least when the libs and apps are in the same project). For > 'cmake' there is a workaround to put '-Wl,--as-needed' into the linker > flags but for 'libtool' you have to patch ltmain. E.g. you argue that this is a bug in libtool. So, if libtool were to simply ignore dependency_libs when building against shared libs wouldn't that solve all issues? If so the patch looks almost trivial and is far better than to setup workflows on whether removing some *.la files and still have some false positives/negatives. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Oct 2 12:50:15 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 02 Oct 2006 07:50:15 -0500 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061002133104.a9332604.bugs.michael@gmx.net> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <20061002133104.a9332604.bugs.michael@gmx.net> Message-ID: <45210B07.5040305@math.unl.edu> Michael Schwendt wrote: > On Mon, 2 Oct 2006 12:32:12 +0200, Axel Thimm wrote: >> From a different view: *.la files aren't much different than *.pc >> files, in fact they contain a subset of their information. One >> wouldn't argue to remove all *.pc files because some may contain too >> many references to libs. > > These are broken and partially have their origin in "extreme static > linking". (For static linking you need the full chain of -lfoo arguments, > as everything else would result in missing symbols). > > pkgconfig "Requires" in libfoo.pc should list the options that are needed > to build with libfoo, NOT the options that were used to build libfoo. With > sane linking, the shared libfoo has a run-time dep already on any other > libs it needs and is linked against, e.g. liba and libb, so adding -la -lb > and so on is not needed when linking shared against -lfoo. Thankfully, pkgconfig has both Libs: Libs.private: The former for *real* lib dependencies, the latter for private/static ones. Unfortunately, not many developers are aware-of or use Libs.private, but it least the feature is there. I'm not aware of any similar functionality for libtool (yet). -- Rex From rdieter at math.unl.edu Mon Oct 2 12:51:24 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 02 Oct 2006 07:51:24 -0500 Subject: [Fedora-packaging] libtool(.la) archive policy proposal In-Reply-To: <1159785305.13363.218.camel@mccallum.corsepiu.local> References: <45194CF5.3090509@math.unl.edu> <1159785305.13363.218.camel@mccallum.corsepiu.local> Message-ID: <45210B4C.8070204@math.unl.edu> Ralf Corsepius wrote: > On Tue, 2006-09-26 at 10:53 -0500, Rex Dieter wrote: >> See >> http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives >> Comments? > It's a fault to remove *.la's. Thanks so much for the constructive input. -- Rex From rdieter at math.unl.edu Mon Oct 2 12:59:14 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 02 Oct 2006 07:59:14 -0500 Subject: [Fedora-packaging] libtool(.la) archive policy proposal In-Reply-To: <45210B4C.8070204@math.unl.edu> References: <45194CF5.3090509@math.unl.edu> <1159785305.13363.218.camel@mccallum.corsepiu.local> <45210B4C.8070204@math.unl.edu> Message-ID: <45210D22.4090007@math.unl.edu> Rex Dieter wrote: > Ralf Corsepius wrote: >> On Tue, 2006-09-26 at 10:53 -0500, Rex Dieter wrote: >>> See >>> http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives >>> Comments? > >> It's a fault to remove *.la's. > > Thanks so much for the constructive input. Or put another way, do you have any better suggestions to workaround the problems introduced by not omitting .la files? -- Rex From enrico.scholz at informatik.tu-chemnitz.de Mon Oct 2 13:34:09 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 02 Oct 2006 15:34:09 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061002123703.GA13434@neu.nirvana> (Axel Thimm's message of "Mon, 2 Oct 2006 14:37:03 +0200") References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> Message-ID: <87r6xqq1ta.fsf@kosh.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: >> E.g. a dep-tree of >> >> liba.so -> libb.so -> libc.so -> app >> >> would suffice. Having the '-la' in libb.la and '-lb' in libc.la would >> cause a tree like >> >> --------------------------- >> / ,---------------- \ >> / / `v v >> liba.so -> libb.so -> libc.so -> app >> \ ^ >> `----------------' >> >> >> Unfortunately, widely used tools like 'libtool' or 'cmake' are creating >> such trees (at least when the libs and apps are in the same project). For >> 'cmake' there is a workaround to put '-Wl,--as-needed' into the linker >> flags but for 'libtool' you have to patch ltmain. > > E.g. you argue that this is a bug in libtool. > > So, if libtool were to simply ignore dependency_libs when building > against shared libs wouldn't that solve all issues? I do not know whether it would solve all issues, but the bad library-deps should be solved. But how shall such a fix be applied in practice? 1. somebody has to write a patch against ltmain.sh and probably libtool.m4. Quick look into ltmain.sh indicates that this is not a trivial job (some archs do not support indirect linking and need a graph like above). 2. somebody has to convince libtool people to apply this patch. Does not seem to be trivial either (look at the more or less trivial multilib patch in the Red Hat libtool-package which is still not applied). Because this change is more an improvement than a bugfix and changes behavior significantly, it will be a candidate for upcoming libtool-2 but not for current libtool-1.5. 3. Most upstream authors will not use a beta versions of libtool. Hence, a huge amount of packages will need a 'libtoolize' (or 'autoreconf') against the patched libtool. This is heavily discouraged. It seems to be much easier to omit *.la files completely because they do not offer anything (which might be relevant for dynamic linking). > If so the patch looks almost trivial and is far better than to setup > workflows on whether removing some *.la files and still have some > false positives/negatives. I do not see which workflows are affected. *.la files are an holdover of the last millennium. No recent system requires them. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Oct 2 13:45:31 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 2 Oct 2006 15:45:31 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <87r6xqq1ta.fsf@kosh.bigo.ensc.de> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> <87r6xqq1ta.fsf@kosh.bigo.ensc.de> Message-ID: <20061002134531.GG13434@neu.nirvana> On Mon, Oct 02, 2006 at 03:34:09PM +0200, Enrico Scholz wrote: > Axel.Thimm at ATrpms.net (Axel Thimm) writes: > > >> E.g. a dep-tree of > >> > >> liba.so -> libb.so -> libc.so -> app > >> > >> would suffice. Having the '-la' in libb.la and '-lb' in libc.la would > >> cause a tree like > >> > >> --------------------------- > >> / ,---------------- \ > >> / / `v v > >> liba.so -> libb.so -> libc.so -> app > >> \ ^ > >> `----------------' > >> > >> > >> Unfortunately, widely used tools like 'libtool' or 'cmake' are creating > >> such trees (at least when the libs and apps are in the same project). For > >> 'cmake' there is a workaround to put '-Wl,--as-needed' into the linker > >> flags but for 'libtool' you have to patch ltmain. > > > > E.g. you argue that this is a bug in libtool. > > > > So, if libtool were to simply ignore dependency_libs when building > > against shared libs wouldn't that solve all issues? > > I do not know whether it would solve all issues, but the bad library-deps > should be solved. But how shall such a fix be applied in practice? > > 1. somebody has to write a patch against ltmain.sh and probably > libtool.m4. Quick look into ltmain.sh indicates that this is not > a trivial job (some archs do not support indirect linking and > need a graph like above). We currently care about Linux, so we'd need that patch for Linux at the beginning. More platforms could add themselves to the whitelist as they see fit. > 2. somebody has to convince libtool people to apply this patch. Does not > seem to be trivial either (look at the more or less trivial multilib > patch in the Red Hat libtool-package which is still not applied). I wouldn't derive from one patch to another. What you perhaps consider trivial and acceptable may be different for the upstream authors and vice versa. I also didn't notice any discussion about the multilib patch on the libtool list, so perhaps this wasn't even submitted? > Because this change is more an improvement than a bugfix and changes > behavior significantly, it will be a candidate for upcoming libtool-2 > but not for current libtool-1.5. > > 3. Most upstream authors will not use a beta versions of libtool. Hence, > a huge amount of packages will need a 'libtoolize' (or 'autoreconf') > against the patched libtool. This is heavily discouraged. This is just our policy. If we decide it serves us better, then it will be changed. > It seems to be much easier to omit *.la files completely because they do > not offer anything (which might be relevant for dynamic linking). > > > > If so the patch looks almost trivial and is far better than to setup > > workflows on whether removing some *.la files and still have some > > false positives/negatives. > > I do not see which workflows are affected. *.la files are an holdover of > the last millennium. No recent system requires them. You missed the beginning of this discussion: There *are* packages of this millenium that break when *.la files are blindly removed. Therefore Rex is trying to setup a workflow of when to omit or not *.la files. Better fix something than deal with broken stuff after the fact is my opinion. Even if *.la files would had turned out to be completely unneccessary - which they are not, but let's suppose - then it would be better to had libtool patched up. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Mon Oct 2 17:36:48 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 02 Oct 2006 19:36:48 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061002133104.a9332604.bugs.michael@gmx.net> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <20061002133104.a9332604.bugs.michael@gmx.net> Message-ID: <1159810608.13363.231.camel@mccallum.corsepiu.local> On Mon, 2006-10-02 at 13:31 +0200, Michael Schwendt wrote: > On Mon, 2 Oct 2006 12:32:12 +0200, Axel Thimm wrote: > > > | Here's a crazy-but-not-too-far-from-reality example: Build shared-lib > > | pkg 'b' which links against 'a'. b's .la files now include references > > | to 'liba.la' (so now depends on it). Build shared-lib pkg 'c' which > > | links against 'b', whose own libc.la file includes > > | references(+dependancy) on libb.la. Rinse, lather, repeat. You'll end > > | up with a pkg z, and a libz.la, which, when all is said and done, > > | > > | * will have a direct dependancy upon y's liby.la > > | * and because of liby.la file references/dependances, will have > > | (indirect) dependancies upon liba.la, libb.la, ..., libx.la > > | > > | When, generally, *none* of these are really required nor desired. > > > > I'm not sure about that, but maybe I understand something wrongly: > > > > - If -la was needed for building libb, then there exists a real > > dependency between liba and libb and libb.la is correct about that. > > So far so good. But here, mixing of build-time and run-time dependencies > starts. Run-time deps enter the build-time dep-chain. Add Rex's "c" to the > set. "c", which needs just "b" at build-time, sees the indirect dep on "a" > (=> liba.la) through libb.la. libb-devel needs to "Requires: liba-devel" > just because of a .la dependency. Yes, because libtool aims at portability. What you call "indirect deps" is non-portable, therefore libtool keeps this info around. > The BuildRequires pile up -- unless the packagers fix them bottom-up > because they examine the new .la file(s). If they don't, wrong BR move up > in the dep-chain. Guess what happens if libfoo is upgraded and now > build-requires libd.la. This requires additional BR in "foo", although > "foo" doesn't depend on libd directly. > > Worse, libtool inter-library dependencies often are hardcoded as > absolute paths, e.g. /usr/lib/liba.la. And what is the problem? Outside of the linux world, shared-libs are non-relocatible. > Removal of any .la from the entire dep-chain bears a very big risk of > requiring a rebuild of the entire dep-chain bottom-up plus pruning the > spec BR/Reqs, also bottom-up. This is not a risk - this is a feature. > > From a different view: *.la files aren't much different than *.pc > > files, in fact they contain a subset of their information. One > > wouldn't argue to remove all *.pc files because some may contain too > > many references to libs. > > These are broken and partially have their origin in "extreme static > linking". (For static linking you need the full chain of -lfoo arguments, > as everything else would result in missing symbols). Wrong: They have their origin in portability. Only fully linking is portable. Packages aiming at portability can not and must not avoid these deps. > pkgconfig "Requires" in libfoo.pc should list the options that are needed > to build with libfoo, NOT the options that were used to build libfoo. With > sane linking, the shared libfoo has a run-time dep already on any other > libs it needs and is linked against, e.g. liba and libb, so adding -la -lb > and so on is not needed when linking shared against -lfoo. >From a libtool focused perspective, *.la's and *.pc aim share some aspects, that's all. *.la's provide features, *.pc provide others. The main disadvantage of *.pc's is them not being automatically generated which enables users to outsmart themselves by "presuming portability on proprietary features" (Very common bug in linux sources). Ralf From rc040203 at freenet.de Mon Oct 2 17:40:25 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 02 Oct 2006 19:40:25 +0200 Subject: [Fedora-packaging] libtool(.la) archive policy proposal In-Reply-To: <45210B4C.8070204@math.unl.edu> References: <45194CF5.3090509@math.unl.edu> <1159785305.13363.218.camel@mccallum.corsepiu.local> <45210B4C.8070204@math.unl.edu> Message-ID: <1159810825.13363.235.camel@mccallum.corsepiu.local> On Mon, 2006-10-02 at 07:51 -0500, Rex Dieter wrote: > Ralf Corsepius wrote: > > On Tue, 2006-09-26 at 10:53 -0500, Rex Dieter wrote: > >> See > >> http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives > >> Comments? > > > It's a fault to remove *.la's. > > Thanks so much for the constructive input. What do you expect as an answer to somebody who has been and is spreading FUD on libtool for a very long time, has a web page called "libtool sucks" and despite the fact he is agitating against libtool, has NEVER EVER shown up on any libtool list, nor reported a bug? If you have got something to say against libtool, report it upstream or stop this foul propaganda. Ralf From enrico.scholz at informatik.tu-chemnitz.de Mon Oct 2 19:01:34 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 02 Oct 2006 21:01:34 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061002134531.GG13434@neu.nirvana> (Axel Thimm's message of "Mon, 2 Oct 2006 15:45:31 +0200") References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> <87r6xqq1ta.fsf@kosh.bigo.ensc.de> <20061002134531.GG13434@neu.nirvana> Message-ID: <87mz8epmnl.fsf@kosh.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: >> 1. somebody has to write a patch against ltmain.sh and probably >> libtool.m4. Quick look into ltmain.sh indicates that this is not >> a trivial job (some archs do not support indirect linking and >> need a graph like above). > > We currently care about Linux, so we'd need that patch for Linux at > the beginning. More platforms could add themselves to the whitelist as > they see fit. Defining and evaluating a 'whitelist' in ltmain.sh might be a problem... >> 2. somebody has to convince libtool people to apply this patch. Does not >> seem to be trivial either (look at the more or less trivial multilib >> patch in the Red Hat libtool-package which is still not applied). > > I wouldn't derive from one patch to another. What you perhaps consider > trivial and acceptable may be different for the upstream authors and > vice versa. I also didn't notice any discussion about the multilib > patch on the libtool list, so perhaps this wasn't even submitted? Dunno; patch exists for 4 years already so I would wonder when it was never submitted. I thought, RH packagers were active in libtool development but I might be wrong here. >> I do not see which workflows are affected. *.la files are an holdover of >> the last millennium. No recent system requires them. > > You missed the beginning of this discussion: There *are* packages of > this millenium that break when *.la files are blindly removed. Ok; there are some projects from the last millenium which are still requiring .la files. But it should be really trivial to fix them by writing | lt_dlopenext("libfoo"); instead of | lt_dlopen("libfoo.la"); > Therefore Rex is trying to setup a workflow of when to omit or not > *.la files. .la files do not make sense nowadays and cause harm. E.g. look at '/usr/lib/kde3/textthumbnail.la': |dependency_libs='... /usr/lib/libidn.la' What would happen when libidn switches to another buildsystem not producing .la files anymore? RPM deps on libidn.so.11 would be still correct but plugin would suddenly stop to work. Then: .la files MUST NOT be shipped in the -devel package but in the main one. Else, module loading will fail. I would not like such a rule... Therefore: remove .la as far as possible and keep them only when they are needed. Rex's rules (no .la files in LD_LIBRARY_PATH) are ok, but I would see them more as a guideline to decide whether a .la file is really required than as a strict MUST rule. > Better fix something libtool is unfixable broken; adding features like correct RPATHs, linker flags at proper place (e.g. '-Wl,--as-needed' before libs) or omitting linking of indirect libs would require heavy changes in code which might change the current behavior and break lot of other projects. Adding a 200k sized bash wrapper around gcc does not seem to be a clever idea either. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Oct 2 19:42:45 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 02 Oct 2006 14:42:45 -0500 Subject: [Fedora-packaging] libtool(.la) archive policy proposal In-Reply-To: <1159810825.13363.235.camel@mccallum.corsepiu.local> References: <45194CF5.3090509@math.unl.edu> <1159785305.13363.218.camel@mccallum.corsepiu.local> <45210B4C.8070204@math.unl.edu> <1159810825.13363.235.camel@mccallum.corsepiu.local> Message-ID: <45216BB5.6090206@math.unl.edu> Ralf Corsepius wrote: > On Mon, 2006-10-02 at 07:51 -0500, Rex Dieter wrote: >> Ralf Corsepius wrote: >>> On Tue, 2006-09-26 at 10:53 -0500, Rex Dieter wrote: >>>> See >>>> http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives >>>> Comments? >>> It's a fault to remove *.la's. >> Thanks so much for the constructive input. > > What do you expect as an answer to somebody who has been and is > spreading FUD on libtool for a very long time, has a web page called > "libtool sucks" ... So, if I retitled the webpage "libtool rocks! (except when dealing with .la files in rpm packaging)" would that help? (Hmm... sounds good, I think I'll do that anyway) Regardless, there are *real* problems outlined and addressed in this proposal and said webpage. If I've made errors/omissions, please point them out, but jumping on a soapbox and yelling "FUD!" isn't helping anyone. -- Rex From Axel.Thimm at ATrpms.net Mon Oct 2 19:43:26 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 2 Oct 2006 21:43:26 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <87mz8epmnl.fsf@kosh.bigo.ensc.de> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> <87r6xqq1ta.fsf@kosh.bigo.ensc.de> <20061002134531.GG13434@neu.nirvana> <87mz8epmnl.fsf@kosh.bigo.ensc.de> Message-ID: <20061002194326.GA21324@neu.nirvana> On Mon, Oct 02, 2006 at 09:01:34PM +0200, Enrico Scholz wrote: > Axel.Thimm at ATrpms.net (Axel Thimm) writes: > > >> 1. somebody has to write a patch against ltmain.sh and probably > >> libtool.m4. Quick look into ltmain.sh indicates that this is not > >> a trivial job (some archs do not support indirect linking and > >> need a graph like above). > > > > We currently care about Linux, so we'd need that patch for Linux at > > the beginning. More platforms could add themselves to the whitelist as > > they see fit. > > Defining and evaluating a 'whitelist' in ltmain.sh might be a problem... Wow, looks like there already exists such a patch and that this patch only changes about a dozen lines. So much for a non-trivial job. ... http://people.debian.org/~keybuk/keybuk-linux-deplibs.patch I raised this up on the libtool list, which is probably better than guessing around. Looks like Debian is using this patch for some time now. I was told that this is still not the best way to slice bread, and am waiting for further details. > >> 2. somebody has to convince libtool people to apply this patch. Does not > >> seem to be trivial either (look at the more or less trivial multilib > >> patch in the Red Hat libtool-package which is still not applied). > > > > I wouldn't derive from one patch to another. What you perhaps consider > > trivial and acceptable may be different for the upstream authors and > > vice versa. I also didn't notice any discussion about the multilib > > patch on the libtool list, so perhaps this wasn't even submitted? > > Dunno; patch exists for 4 years already so I would wonder when it was never > submitted. I thought, RH packagers were active in libtool development but I > might be wrong here. Did you take a look at the multilib patch? It breaks other Linux distributions, which is why it was never submitted to libtool-patches. Let's not blame upstream for that. libtool has just received no love at all in Red Hat land for whatever reason. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Mon Oct 2 23:56:46 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 3 Oct 2006 01:56:46 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <1159810608.13363.231.camel@mccallum.corsepiu.local> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <20061002133104.a9332604.bugs.michael@gmx.net> <1159810608.13363.231.camel@mccallum.corsepiu.local> Message-ID: <20061003015646.b2626b9c.bugs.michael@gmx.net> On Mon, 02 Oct 2006 19:36:48 +0200, Ralf Corsepius wrote: > Yes, because libtool aims at portability. What you call "indirect deps" > is non-portable, therefore libtool keeps this info around. > > > The BuildRequires pile up -- unless the packagers fix them bottom-up > > because they examine the new .la file(s). If they don't, wrong BR move up > > in the dep-chain. Guess what happens if libfoo is upgraded and now > > build-requires libd.la. This requires additional BR in "foo", although > > "foo" doesn't depend on libd directly. > > > > Worse, libtool inter-library dependencies often are hardcoded as > > absolute paths, e.g. /usr/lib/liba.la. > > And what is the problem? Outside of the linux world, shared-libs are > non-relocatible. We're not "outside of the linux world". You make a big thing out of "features", which we don't need, because they increase the trouble. They also add the possibility of "feature abuse". Source tarball vendors who hack "stuff" into libtool files to make the end-product work even less good. > > Removal of any .la from the entire dep-chain bears a very big risk of > > requiring a rebuild of the entire dep-chain bottom-up plus pruning the > > spec BR/Reqs, also bottom-up. > > This is not a risk - this is a feature. So what? It means: increased maintenance requirements that sucks. > > > From a different view: *.la files aren't much different than *.pc > > > files, in fact they contain a subset of their information. One > > > wouldn't argue to remove all *.pc files because some may contain too > > > many references to libs. > > > > These are broken and partially have their origin in "extreme static > > linking". (For static linking you need the full chain of -lfoo arguments, > > as everything else would result in missing symbols). > > Wrong: They have their origin in portability. Only fully linking is > portable. Packages aiming at portability can not and must not avoid > these deps. Insert comment from above here, too. It's fine from the perspective of the vendor of the source tarball. I've made good use of libtool long ago. Still the "feature bloat" is a hindrance at the RPM packaging level the longer the inter-library dependency-chain becomes. From a.badger at gmail.com Tue Oct 3 01:19:35 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 02 Oct 2006 18:19:35 -0700 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <87mz8epmnl.fsf@kosh.bigo.ensc.de> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> <87r6xqq1ta.fsf@kosh.bigo.ensc.de> <20061002134531.GG13434@neu.nirvana> <87mz8epmnl.fsf@kosh.bigo.ensc.de> Message-ID: <1159838375.2866.35.camel@localhost> On Mon, 2006-10-02 at 21:01 +0200, Enrico Scholz wrote: > Axel.Thimm at ATrpms.net (Axel Thimm) writes: > > You missed the beginning of this discussion: There *are* packages of > > this millenium that break when *.la files are blindly removed. > > Ok; there are some projects from the last millenium which are still > requiring .la files. But it should be really trivial to fix them by > writing > > | lt_dlopenext("libfoo"); > > instead of > > | lt_dlopen("libfoo.la"); > > arts is an example of a program so broken. I'm attaching a patch that fixes it. It is a little more involved than I'd hoped as arts (and apparently other kde packages) include an older version of libtool with some broken .m4 files for detecting the shared object extension (The first half of this bug: http://bugs.kde.org/show_bug.cgi?id=93359 ) Explanation of patch: *.mcopclass: These files have the name of the module that needs to be loaded. Due to the use of lt_dlopen(), they use libfoo.la. With the switch to lt_dlopenext() these can safely become libfoo. extensionloader.cc: Here's where we switch from lt_dlopen() to lt_dlopenext(). acinclude.m4, ltdl.m4: Probably only ltdl.m4 needs to be changed here. Basically I replaced the erroroneous detection with the simple check of newer libtools. This step is needed because arts includes its own, somewhat dated, copy of libltdl. Do we want to get rid of that anyway (because we want to use system libraries whenever possible)? Or does arts need this specific version of libltdl for some reason? With this patch, I am able to build an artsd that doesn't segfault when running other KDE apps that generate sound. It's possible that there are other issues beyond this as I don't normally run KDE. Rex, if you can throw me some problem packages I'll be happy to look into what is causing things to break. Note that this is not a vote for or against removing .la files when they are used as loadable modules. It's just a patch that demonstrates what has to be done to fix the code to not require .la files. Also note that according to the wording of the proposed draft, arts would still be in violation even though the shared objects are loadable modules rather than libraries intended for linking. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: arts-1.5.4-dlopenext.patch Type: text/x-patch Size: 4294 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Tue Oct 3 06:00:28 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 03 Oct 2006 08:00:28 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061002194326.GA21324@neu.nirvana> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> <87r6xqq1ta.fsf@kosh.bigo.ensc.de> <20061002134531.GG13434@neu.nirvana> <87mz8epmnl.fsf@kosh.bigo.ensc.de> <20061002194326.GA21324@neu.nirvana> Message-ID: <1159855229.13363.251.camel@mccallum.corsepiu.local> On Mon, 2006-10-02 at 21:43 +0200, Axel Thimm wrote: > On Mon, Oct 02, 2006 at 09:01:34PM +0200, Enrico Scholz wrote: > > Axel.Thimm at ATrpms.net (Axel Thimm) writes: > > >> 2. somebody has to convince libtool people to apply this patch. Does not > > >> seem to be trivial either (look at the more or less trivial multilib > > >> patch in the Red Hat libtool-package which is still not applied). > > > > > > I wouldn't derive from one patch to another. What you perhaps consider > > > trivial and acceptable may be different for the upstream authors and > > > vice versa. I also didn't notice any discussion about the multilib > > > patch on the libtool list, so perhaps this wasn't even submitted? > > > > Dunno; patch exists for 4 years already so I would wonder when it was never > > submitted. I recall an initial version had been submitted several years ago. Due to lack of generality it had never been applied. The RH dev never showed up again afterwards. Seemingly he didn't like what he had got to hear and resorted to "worksforme". > > I thought, RH packagers were active in libtool development but I > > might be wrong here. Though libtool to a large extend is a RH invention (Alex O. had been one of its key developers), RH devs had been more or less absent in libtool development for many years. > Did you take a look at the multilib patch? It breaks other Linux > distributions, which is why it was never submitted to > libtool-patches. Let's not blame upstream for that. > > libtool has just received no love at all in Red Hat land for whatever > reason. I guess everybody agrees that libtool is mess, but ... it's still the best we've currently got, when it comes to portably building shared libs ;) Ralf From Axel.Thimm at ATrpms.net Tue Oct 3 09:09:53 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 3 Oct 2006 11:09:53 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <1159855229.13363.251.camel@mccallum.corsepiu.local> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> <87r6xqq1ta.fsf@kosh.bigo.ensc.de> <20061002134531.GG13434@neu.nirvana> <87mz8epmnl.fsf@kosh.bigo.ensc.de> <20061002194326.GA21324@neu.nirvana> <1159855229.13363.251.camel@mccallum.corsepiu.local> Message-ID: <20061003090953.GA19958@neu.nirvana> On Tue, Oct 03, 2006 at 08:00:28AM +0200, Ralf Corsepius wrote: > On Mon, 2006-10-02 at 21:43 +0200, Axel Thimm wrote: > > On Mon, Oct 02, 2006 at 09:01:34PM +0200, Enrico Scholz wrote: > > > Axel.Thimm at ATrpms.net (Axel Thimm) writes: > > > > >> 2. somebody has to convince libtool people to apply this patch. Does not > > > >> seem to be trivial either (look at the more or less trivial multilib > > > >> patch in the Red Hat libtool-package which is still not applied). > > > > > > > > I wouldn't derive from one patch to another. What you perhaps consider > > > > trivial and acceptable may be different for the upstream authors and > > > > vice versa. I also didn't notice any discussion about the multilib > > > > patch on the libtool list, so perhaps this wasn't even submitted? > > > > > > Dunno; patch exists for 4 years already so I would wonder when it was never > > > submitted. > I recall an initial version had been submitted several years ago. > Due to lack of generality it had never been applied. The RH dev never > showed up again afterwards. Seemingly he didn't like what he had got to > hear and resorted to "worksforme". He only posted a first attempt on the list and explicitely mentioned that this is not ready for patch submission yet himself. There was no rejection or similar, there was just no momentum to push it further. > > > I thought, RH packagers were active in libtool development but I > > > might be wrong here. > Though libtool to a large extend is a RH invention (Alex O. had been one > of its key developers), RH devs had been more or less absent in libtool > development for many years. To be honest all people from RH that have worked on libtool did so before entering RH, comapring the dates of employment and their activity in libtool one might even assume the contrary ;) (in reality these people were pulled into different tasks like Alexandre going gcc and having to leave libtool behind). > > Did you take a look at the multilib patch? It breaks other Linux > > distributions, which is why it was never submitted to > > libtool-patches. Let's not blame upstream for that. > > > > libtool has just received no love at all in Red Hat land for whatever > > reason. > > I guess everybody agrees that libtool is mess, but ... it's still the > best we've currently got, when it comes to portably building shared > libs ;) And it is the best upstream has, so the argument "on Linux we need no libtool" doesn't carry (not that Ralf says so, I'm just extending his argument). Projects will continue to use libtool and if we want to do something then it's fixing aspects of libtool instead of flaming it. But as I already said to someone here in PM: Personally I'm not interested in another crusade against windmills, I'm curious about how to improve stuff, but I'm not investing in brain-washing people anymore. ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Oct 3 19:49:51 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 03 Oct 2006 14:49:51 -0500 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <1159838375.2866.35.camel@localhost> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> <87r6xqq1ta.fsf@kosh.bigo.ensc.de> <20061002134531.GG13434@neu.nirvana> <87mz8epmnl.fsf@kosh.bigo.ensc.de> <1159838375.2866.35.camel@localhost> Message-ID: <4522BEDF.9000003@math.unl.edu> Toshio Kuratomi wrote: > Explanation of patch: ... > acinclude.m4, ltdl.m4: Probably only ltdl.m4 needs to be changed here. > Basically I replaced the erroroneous detection with the simple check of > newer libtools. This step is needed because arts includes its own, > somewhat dated, copy of libltdl. Do we want to get rid of that anyway > (because we want to use system libraries whenever possible)? Or does > arts need this specific version of libltdl for some reason? How's the best way to use a newer/different libltdl? (Naively?) replace arts' libltdl/ with that from /usr/share/libtool/libltdl? > With this patch, I am able to build an artsd that doesn't segfault when > running other KDE apps that generate sound. It's possible that there > are other issues beyond this as I don't normally run KDE. Rex, if you > can throw me some problem packages I'll be happy to look into what is > causing things to break. Install kdemultimedia-extras and try using 'juk' to play audio/music files. Or just login/use kde and all system sounds will use arts as well. -- Rex From rdieter at math.unl.edu Tue Oct 3 19:54:38 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 03 Oct 2006 14:54:38 -0500 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <4522BEDF.9000003@math.unl.edu> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> <87r6xqq1ta.fsf@kosh.bigo.ensc.de> <20061002134531.GG13434@neu.nirvana> <87mz8epmnl.fsf@kosh.bigo.ensc.de> <1159838375.2866.35.camel@localhost> <4522BEDF.9000003@math.unl.edu> Message-ID: <4522BFFE.7090302@math.unl.edu> Rex Dieter wrote: > Toshio Kuratomi wrote: > >> Explanation of patch: > ... >> acinclude.m4, ltdl.m4: Probably only ltdl.m4 needs to be changed here. >> Basically I replaced the erroroneous detection with the simple check of >> newer libtools. This step is needed because arts includes its own, >> somewhat dated, copy of libltdl. Do we want to get rid of that anyway >> (because we want to use system libraries whenever possible)? Or does >> arts need this specific version of libltdl for some reason? > > How's the best way to use a newer/different libltdl? (Naively?) replace > arts' libltdl/ with that from /usr/share/libtool/libltdl? Or just: $ libtoolize --ltdl --force ? (: -- Rex From rc040203 at freenet.de Wed Oct 4 04:25:33 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Oct 2006 06:25:33 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061003015646.b2626b9c.bugs.michael@gmx.net> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <20061002133104.a9332604.bugs.michael@gmx.net> <1159810608.13363.231.camel@mccallum.corsepiu.local> <20061003015646.b2626b9c.bugs.michael@gmx.net> Message-ID: <1159935934.13363.291.camel@mccallum.corsepiu.local> On Tue, 2006-10-03 at 01:56 +0200, Michael Schwendt wrote: > On Mon, 02 Oct 2006 19:36:48 +0200, Ralf Corsepius wrote: > > > Yes, because libtool aims at portability. What you call "indirect deps" > > is non-portable, therefore libtool keeps this info around. > > > > > The BuildRequires pile up -- unless the packagers fix them bottom-up > > > because they examine the new .la file(s). If they don't, wrong BR move up > > > in the dep-chain. Guess what happens if libfoo is upgraded and now > > > build-requires libd.la. This requires additional BR in "foo", although > > > "foo" doesn't depend on libd directly. > > > > > > Worse, libtool inter-library dependencies often are hardcoded as > > > absolute paths, e.g. /usr/lib/liba.la. > > > > And what is the problem? Outside of the linux world, shared-libs are > > non-relocatible. > > We're not "outside of the linux world". Yes, I sense certain circles around here are striving for "living on the island of RH/Fedora" ;) > You make a big thing out of > "features", which we don't need, That's the point we both repeatedly have clashed: You are ignoring the API aspect of *.la's - *.la's are meant to be a (semi-standardized) portability layer on top of library implementation details, such as library names, versions, rpath etc. > > > Removal of any .la from the entire dep-chain bears a very big risk of > > > requiring a rebuild of the entire dep-chain bottom-up plus pruning the > > > spec BR/Reqs, also bottom-up. > > > > This is not a risk - this is a feature. > > So what? It means: increased maintenance requirements that sucks. I beg to differ. Install libs outside of /usr/lib and in parallel to those in /usr/lib and you'll probably pretty soon notice, why RH/Fedora's habits/conventions are troublesome. > > > > From a different view: *.la files aren't much different than *.pc > > > > files, in fact they contain a subset of their information. One > > > > wouldn't argue to remove all *.pc files because some may contain too > > > > many references to libs. > > > > > > These are broken and partially have their origin in "extreme static > > > linking". (For static linking you need the full chain of -lfoo arguments, > > > as everything else would result in missing symbols). > > > > Wrong: They have their origin in portability. Only fully linking is > > portable. Packages aiming at portability can not and must not avoid > > these deps. > > Insert comment from above here, too. It's fine from the perspective of the > vendor of the source tarball. I've made good use of libtool long ago. > Still the "feature bloat" is a hindrance at the RPM packaging level the > longer the inter-library dependency-chain becomes. And? There is a lot of (low quality) SW around, which simply ignore the defacto existing implications of inter-library dependencies on other OSes, and expect other OS to provide the same functionalities as Linux does. libtool only propagates some amount of these packages' bad designs to Linux, you'd be facing almost anywhere else outside of Linux. That's why I consider Fedora's conventions on "removing *.la's" NOT to be HELPFUL. Also consider: Any package using libtool by default installs *.la's, any package's author (Note: author, not Fedora package maintainer) has the liberty of removing them upon installation as part of his package's "installation step", if he thinks they are harmful/not useful. >From a practical POV, I can live with package maintainer's removing *.la's on Fedora, because they are rarely useful on the "island of Fedora", but changing this into "MUST REMOVE", to me is going waaaay too far. >From a developer's POV, if YOU think libtool on Linux's behavior must be changed to not installing *.la's, I'd propose you to come up with a proposal on the libtool lists and try to have libtool changed in general. Ralf From a.badger at gmail.com Wed Oct 4 05:05:02 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 03 Oct 2006 22:05:02 -0700 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <4522BFFE.7090302@math.unl.edu> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> <87r6xqq1ta.fsf@kosh.bigo.ensc.de> <20061002134531.GG13434@neu.nirvana> <87mz8epmnl.fsf@kosh.bigo.ensc.de> <1159838375.2866.35.camel@localhost> <4522BEDF.9000003@math.unl.edu> <4522BFFE.7090302@math.unl.edu> Message-ID: <1159938302.2630.12.camel@localhost> On Tue, 2006-10-03 at 14:54 -0500, Rex Dieter wrote: > Rex Dieter wrote: > > Toshio Kuratomi wrote: > > > >> Explanation of patch: > > ... > >> acinclude.m4, ltdl.m4: Probably only ltdl.m4 needs to be changed here. > >> Basically I replaced the erroroneous detection with the simple check of > >> newer libtools. This step is needed because arts includes its own, > >> somewhat dated, copy of libltdl. Do we want to get rid of that anyway > >> (because we want to use system libraries whenever possible)? Or does > >> arts need this specific version of libltdl for some reason? > > > > How's the best way to use a newer/different libltdl? (Naively?) replace > > arts' libltdl/ with that from /usr/share/libtool/libltdl? > > Or just: > $ libtoolize --ltdl --force > ? (: My recommendation for best is to use what's installed by the system libtool-ltdl(-devel). Without knowing why KDE packages are including a local copy of ltdl in the first place, though, I don't know whether this would be a change welcomed or refused by upstream. (If rejected, your other suggestions would work as well.) -Toshio P.S. I'll try out juk later this week. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Wed Oct 4 05:16:57 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 03 Oct 2006 22:16:57 -0700 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <1159935934.13363.291.camel@mccallum.corsepiu.local> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <20061002133104.a9332604.bugs.michael@gmx.net> <1159810608.13363.231.camel@mccallum.corsepiu.local> <20061003015646.b2626b9c.bugs.michael@gmx.net> <1159935934.13363.291.camel@mccallum.corsepiu.local> Message-ID: <1159939017.2630.25.camel@localhost> On Wed, 2006-10-04 at 06:25 +0200, Ralf Corsepius wrote: > Also consider: Any package using libtool by default installs *.la's, any > package's author (Note: author, not Fedora package maintainer) has the > liberty of removing them upon installation as part of his package's > "installation step", if he thinks they are harmful/not useful. You're wrong. *.la's provides benefit to upstream. It does not always provide benefits to downstream. Therefore it is downstream which must make the decision whether to remove the .la files. *.la's guarantee that upstream will get a certain set of features when people try to link against their library and provide a means of portably implementing loadable modules with libltdl. In Fedora these are provided without the *.la files present (as long as the application doesn't explicitly ask for the *.la's which, if the purpose is portability, they shouldn't.) *.la's might make some sense when linking statically, but if our general Fedora Policy is to remove static libraries then our general *.la policy should be removal as well. If you know of a feature that *.la's provide on Fedora that otherwise is not present, feel free to share it so we can refine the Guidelines to do the right thing. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Wed Oct 4 05:54:47 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Oct 2006 07:54:47 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <1159939017.2630.25.camel@localhost> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <20061002133104.a9332604.bugs.michael@gmx.net> <1159810608.13363.231.camel@mccallum.corsepiu.local> <20061003015646.b2626b9c.bugs.michael@gmx.net> <1159935934.13363.291.camel@mccallum.corsepiu.local> <1159939017.2630.25.camel@localhost> Message-ID: <1159941287.13363.297.camel@mccallum.corsepiu.local> On Tue, 2006-10-03 at 22:16 -0700, Toshio Kuratomi wrote: > On Wed, 2006-10-04 at 06:25 +0200, Ralf Corsepius wrote: > > Also consider: Any package using libtool by default installs *.la's, any > > package's author (Note: author, not Fedora package maintainer) has the > > liberty of removing them upon installation as part of his package's > > "installation step", if he thinks they are harmful/not useful. > > You're wrong. *.la's provides benefit to upstream. It does not always > provide benefits to downstream. Therefore it is downstream which must > make the decision whether to remove the .la files. > If you know of a feature that *.la's provide on Fedora that otherwise is > not present, * library dependencies. * rpath (consider parallel installed package, e.g. openmotif in parallel to lesscrap) * redundancy - Remember: Conflicts between *.la's, *.pc's, ld.so.conf and rpm deps not always are libtool's fault. Esp. *.pc's are MANUALLY written. * Inconsistent flags: Remember *.pc's are manually written. Some people tend to abuse CFlags in *.pcs. Ralf From a.badger at gmail.com Wed Oct 4 07:31:09 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 04 Oct 2006 00:31:09 -0700 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <1159941287.13363.297.camel@mccallum.corsepiu.local> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <20061002133104.a9332604.bugs.michael@gmx.net> <1159810608.13363.231.camel@mccallum.corsepiu.local> <20061003015646.b2626b9c.bugs.michael@gmx.net> <1159935934.13363.291.camel@mccallum.corsepiu.local> <1159939017.2630.25.camel@localhost> <1159941287.13363.297.camel@mccallum.corsepiu.local> Message-ID: <1159947069.2630.35.camel@localhost> On Wed, 2006-10-04 at 07:54 +0200, Ralf Corsepius wrote: > On Tue, 2006-10-03 at 22:16 -0700, Toshio Kuratomi wrote: > > On Wed, 2006-10-04 at 06:25 +0200, Ralf Corsepius wrote: > > > Also consider: Any package using libtool by default installs *.la's, any > > > package's author (Note: author, not Fedora package maintainer) has the > > > liberty of removing them upon installation as part of his package's > > > "installation step", if he thinks they are harmful/not useful. > > > > You're wrong. *.la's provides benefit to upstream. It does not always > > provide benefits to downstream. Therefore it is downstream which must > > make the decision whether to remove the .la files. > > > If you know of a feature that *.la's provide on Fedora that otherwise is > > not present, > > * library dependencies. We have this already. > * rpath (consider parallel installed package, e.g. openmotif in parallel to lesscrap) We have this manually, *.la's add it automatically. For the motif case, it seems that lesstif installs to %{_libdir} and has no rpath set so it doesn't need a *.la. openmotif, as a non-Fedora package, is free to install wherever it pleases with whatever rpath it likes and use *.la's to implement its choice. Can you point me to two Fedora packages that need to parallel install libraries? > * redundancy - Remember: Conflicts between *.la's, *.pc's, ld.so.conf > and rpm deps not always are libtool's fault. Esp. *.pc's are MANUALLY > written. > * Inconsistent flags: Remember *.pc's are manually written. Some people > tend to abuse CFlags in *.pcs. > Unless I'm misunderstanding what you mean, these are bugs and should be fixed, not ignored because we have *.la's. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Wed Oct 4 08:40:37 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Oct 2006 10:40:37 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <1159947069.2630.35.camel@localhost> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <20061002133104.a9332604.bugs.michael@gmx.net> <1159810608.13363.231.camel@mccallum.corsepiu.local> <20061003015646.b2626b9c.bugs.michael@gmx.net> <1159935934.13363.291.camel@mccallum.corsepiu.local> <1159939017.2630.25.camel@localhost> <1159941287.13363.297.camel@mccallum.corsepiu.local> <1159947069.2630.35.camel@localhost> Message-ID: <1159951238.13363.340.camel@mccallum.corsepiu.local> On Wed, 2006-10-04 at 00:31 -0700, Toshio Kuratomi wrote: > On Wed, 2006-10-04 at 07:54 +0200, Ralf Corsepius wrote: > > On Tue, 2006-10-03 at 22:16 -0700, Toshio Kuratomi wrote: > > > On Wed, 2006-10-04 at 06:25 +0200, Ralf Corsepius wrote: > > > > Also consider: Any package using libtool by default installs *.la's, any > > > > package's author (Note: author, not Fedora package maintainer) has the > > > > liberty of removing them upon installation as part of his package's > > > > "installation step", if he thinks they are harmful/not useful. > > > > > > You're wrong. *.la's provides benefit to upstream. It does not always > > > provide benefits to downstream. Therefore it is downstream which must > > > make the decision whether to remove the .la files. > > > > > If you know of a feature that *.la's provide on Fedora that otherwise is > > > not present, > > > > * library dependencies. > We have this already. Where? All Fedora has is libs somewhere on the file system, being searched for at run-time by ld.so, and searched for by GCC/ld/etc. at link-time with paths being composed by arbitrary "configure scripts". There is no guarantee run-time deps are satisfied or complete, neither at run-time nor at link-time, but rpm's deps. => Without *.la you can exchange (and brake) a libraries/applications dependencies unnoticed. > > * rpath (consider parallel installed package, e.g. openmotif in parallel to lesscrap) > We have this manually, *.la's add it automatically. For the motif case, > it seems that lesstif installs to %{_libdir} and has no rpath set so it > doesn't need a *.la. openmotif, as a non-Fedora package, is free to > install wherever it pleases with whatever rpath it likes and use *.la's > to implement its choice. Can you point me to two Fedora packages that > need to parallel install libraries? ATM, this case doesn't exist, but it would be easy to construct, e.g. by introducing compat-*devel packages being designed to exist in parallel. > > * redundancy - Remember: Conflicts between *.la's, *.pc's, ld.so.conf > > and rpm deps not always are libtool's fault. Esp. *.pc's are MANUALLY > > written. > > * Inconsistent flags: Remember *.pc's are manually written. Some people > > tend to abuse CFlags in *.pcs. > > > Unless I'm misunderstanding what you mean, these are bugs and should be > fixed, not ignored because we have *.la's. In a nutshell, I mean "*.pc's are equally broken and not any better than *.la's". They don't suffer from the same issues as *.la's but they also suffer from defects, e.g. * language specific compiler flags in *.pc * compiler/compiler-version specific compiler flags in *.pc * Incorrect hard-coded libs (-l) * Incorrect (Missing rsp. superfluous) deps (Requires: foo) * pkgconfig not properly separating CPPFLAGS/CFLAGS/CXXFLAGS/FFLAGS * being manually written. * being static (They denote a situation having being valid at one point in time - There is no guarantee it still is, nor that they match ld.so's configuration.). ... Ralf From Axel.Thimm at ATrpms.net Wed Oct 4 11:01:33 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 4 Oct 2006 13:01:33 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061002194326.GA21324@neu.nirvana> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> <87r6xqq1ta.fsf@kosh.bigo.ensc.de> <20061002134531.GG13434@neu.nirvana> <87mz8epmnl.fsf@kosh.bigo.ensc.de> <20061002194326.GA21324@neu.nirvana> Message-ID: <20061004110133.GG2149@neu.nirvana> On Mon, Oct 02, 2006 at 09:43:26PM +0200, Axel Thimm wrote: > On Mon, Oct 02, 2006 at 09:01:34PM +0200, Enrico Scholz wrote: > > Axel.Thimm at ATrpms.net (Axel Thimm) writes: > > > > >> 1. somebody has to write a patch against ltmain.sh and probably > > >> libtool.m4. Quick look into ltmain.sh indicates that this is not > > >> a trivial job (some archs do not support indirect linking and > > >> need a graph like above). > > > > > > We currently care about Linux, so we'd need that patch for Linux at > > > the beginning. More platforms could add themselves to the whitelist as > > > they see fit. > > > > Defining and evaluating a 'whitelist' in ltmain.sh might be a problem... > > Wow, looks like there already exists such a patch and that this patch > only changes about a dozen lines. So much for a non-trivial job. ... > > http://people.debian.org/~keybuk/keybuk-linux-deplibs.patch > > I raised this up on the libtool list, which is probably better than > guessing around. Looks like Debian is using this patch for some time > now. I was told that this is still not the best way to slice bread, > and am waiting for further details. OK, after browsing through the Debian bugs related to this patch it looks like there are two issues, both of which are fixable and not really a blocker for Fedora packaging: o When libtool is told not to remember the dependent libs/rpaths of shared builds, a library being built as a subproject of a build may later be overrideen by an older version of itself under %{_libdir}. This will never happen in a clean chroot build, but can happen with conventional non-package builds. But this happens outside of libtool anyway, an example is rpm itself that cannot be properly built in presence of rpm-devel. A fix could be a switch to turn this only on for packaging, or a proper permanent fix in libtool. o Cross-compilation of libs may also lose their rpath and try the system's rpath. A similar issue like above in a different domain. Concerning upstream libtool, there is no input from vendors, be it Red Hat, Debian, Fedora etc. to push in patches or enhancements. This is true for multilib and the mentioned patch the same. The reasons look like vendor lazyness. For example both Debian and Red Hat have their 10-line patches for years in their packages but never properly sumbitted this upstream or even tried to raise the issue to a level where libtool maintainers would address it. In the past there have been some small momentum from the outside, libtoolers then had some _positive_ discussion on the matter, but the feedback was missing. I think if someone here outlines the issues/desires to upstream then libtool may have both patches plus further needed fixes in upstream really soon. I have started doing so, but I'm not going to fight in fedora-packaging for a lost cause again, I'll let someone else bleed his heart here this time. ;) Of course that would only affect new upstream tarballs of libtoolized projects, so any packaging using such an improved system libtool on older tarballs would need to libtoolize. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Wed Oct 4 11:24:30 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 04 Oct 2006 06:24:30 -0500 Subject: [Fedora-packaging] Vacation Message-ID: <1159961070.24584.23.camel@dhcp-10-12-33-223.boston.devel.redhat.com> I'm leaving for vacation tomorrow morning, and I will not be back in the continental US until Friday, October 13th. Accordingly, I will not be attending the FESCO or FPC meetings this week or next. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From bugs.michael at gmx.net Wed Oct 4 16:26:27 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 4 Oct 2006 18:26:27 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <1159951238.13363.340.camel@mccallum.corsepiu.local> References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <20061002133104.a9332604.bugs.michael@gmx.net> <1159810608.13363.231.camel@mccallum.corsepiu.local> <20061003015646.b2626b9c.bugs.michael@gmx.net> <1159935934.13363.291.camel@mccallum.corsepiu.local> <1159939017.2630.25.camel@localhost> <1159941287.13363.297.camel@mccallum.corsepiu.local> <1159947069.2630.35.camel@localhost> <1159951238.13363.340.camel@mccallum.corsepiu.local> Message-ID: <20061004182627.10422ae5.bugs.michael@gmx.net> On Wed, 04 Oct 2006 10:40:37 +0200, Ralf Corsepius wrote: > In a nutshell, I mean "*.pc's are equally broken and not any better than > *.la's". > > They don't suffer from the same issues as *.la's but they also suffer > from defects, e.g. > * language specific compiler flags in *.pc > * compiler/compiler-version specific compiler flags in *.pc > * Incorrect hard-coded libs (-l) > * Incorrect (Missing rsp. superfluous) deps (Requires: foo) > * pkgconfig not properly separating CPPFLAGS/CFLAGS/CXXFLAGS/FFLAGS > * being manually written. > * being static (They denote a situation having being valid at one point > in time - There is no guarantee it still is, nor that they match ld.so's > configuration.). > ... In *many* cases they are much more better/useful, however, because with the pkg-config front-end (man pkg-config) they give very easy access to meta-information of installed packages in a similar way like custom "foo-config" scripts. This makes them an extremely popular choice whereas a big chunk of the "libtool stuff" is transparent to the package author. Additionally, .pc files in many cases are a strict build-requirement of the software to be built, as else the software set-up utility would not find installed libraries or be unable to use them. Unlike .la files. All you've come up with above is a list of potential bugs in .pc files without comparing it with a similarly extensive list of potential bugs in .la files. Sure, a big hindrance of .pc files is also that they suffer badly from the same dep-chain breakage, where "Requires" within a .pc file are not mirrored in the RPM package's "Requires" (neither automatically nor manually). As a result, -devel package users at the root of the dep-chain need to work around missing dependencies exactly as causes by incomplete .la packaging. A difference compared with .la files is that .la files add additional dependencies on absolute paths to other .la files, which makes it much more easy to break the chain, whereas .pc files just create links to other pkg names. From aoliva at redhat.com Thu Oct 5 05:08:39 2006 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 05 Oct 2006 02:08:39 -0300 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <1159947069.2630.35.camel@localhost> (Toshio Kuratomi's message of "Wed, 04 Oct 2006 00:31:09 -0700") References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <20061002133104.a9332604.bugs.michael@gmx.net> <1159810608.13363.231.camel@mccallum.corsepiu.local> <20061003015646.b2626b9c.bugs.michael@gmx.net> <1159935934.13363.291.camel@mccallum.corsepiu.local> <1159939017.2630.25.camel@localhost> <1159941287.13363.297.camel@mccallum.corsepiu.local> <1159947069.2630.35.camel@localhost> Message-ID: On Oct 4, 2006, Toshio Kuratomi wrote: >> * library dependencies. > We have this already. Only for dynamic libraries. If you want to link statically, you still need to list the static dependencies explicitly, and the .la file is where the dependencies are. Sure enough, most packages don't rely on libtool for that and just take care of finding dependencies themselves, so this is hardly a strong argument to keep the .la files around. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Thu Oct 5 05:15:58 2006 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 05 Oct 2006 02:15:58 -0300 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061002123703.GA13434@neu.nirvana> (Axel Thimm's message of "Mon, 2 Oct 2006 14:37:03 +0200") References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> Message-ID: On Oct 2, 2006, Axel Thimm wrote: > So, if libtool were to simply ignore dependency_libs when building > against shared libs wouldn't that solve all issues? Nope, it would only solve the common case. It is perfectly possible for a dynamic library to depend on a static-only library. And it's even possible to create other dynamic libraries out of that, if the static-only library is PIC or the platform can handle non-PIC in dynamic libraries. > If so the patch looks almost trivial and is far better than to setup > workflows on whether removing some *.la files and still have some > false positives/negatives. Breaking the libtool sources that get installed for packagers all over the world to use, for deployment on various operating systems, is not really an option I'd recommend. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Thu Oct 5 05:13:23 2006 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 05 Oct 2006 02:13:23 -0300 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <87ven2q5m9.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Mon, 02 Oct 2006 14:11:58 +0200") References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> Message-ID: On Oct 2, 2006, Enrico Scholz wrote: >> - If -la was needed for building libb, then there exists a real >> dependency between liba and libb and libb.la is correct about that. > No, this dependency does not need to be handled explicitly with dynamic > libraries. And it's actually harmful if you move the .so link to the -devel package, which is the general recommendation. Consider that foo-devel provides libfoo.so, which is a link to libfoo.so.0 provided by foo-libs. Consider that libfoo.so.0 depends on libbar.so.0, provided by bar-libs. If you link with -lfoo without libtool, it just works. If you link with -lfoo with libtool, and libtool finds the .la file that lists -lbar as a dependency of libfoo.la, then you lose unless you list bar-devel as a dependency of foo-devel. Is the absence of such an otherwise-unnecessary dependency a bug in package foo? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Thu Oct 5 05:20:53 2006 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 05 Oct 2006 02:20:53 -0300 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <1159855229.13363.251.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Tue, 03 Oct 2006 08:00:28 +0200") References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> <87r6xqq1ta.fsf@kosh.bigo.ensc.de> <20061002134531.GG13434@neu.nirvana> <87mz8epmnl.fsf@kosh.bigo.ensc.de> <20061002194326.GA21324@neu.nirvana> <1159855229.13363.251.camel@mccallum.corsepiu.local> Message-ID: On Oct 3, 2006, Ralf Corsepius wrote: > Though libtool to a large extend is a RH invention (Alex O. had been one > of its key developers), RH devs had been more or less absent in libtool > development for many years. Actually, I inherited maintainership from Gord, who invented libtool, long before I joined Red Hat. And after I joined, I failed to keep up with it except for the first year or so. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Thu Oct 5 05:27:43 2006 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 05 Oct 2006 02:27:43 -0300 Subject: [Fedora-packaging] .so files in main package for python packages In-Reply-To: <200609100913.29721.jkeating@redhat.com> (Jesse Keating's message of "Sun, 10 Sep 2006 09:13:29 -0400") References: <200609100911.16656.jkeating@redhat.com> <200609100913.29721.jkeating@redhat.com> Message-ID: On Sep 10, 2006, Jesse Keating wrote: > On Sunday 10 September 2006 09:11, Jesse Keating wrote: >> Only .so SYMLINKS should be in the -devel package, the symlinks that are >> made to the actual libraries that would be in the main package. > Whoops, that's not quite right I think... That's the general idea but I'm > sure there are exceptions. The exception I'm aware of is when the .so name is used for dlopening. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From Axel.Thimm at ATrpms.net Thu Oct 5 09:51:09 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 5 Oct 2006 11:51:09 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> Message-ID: <20061005095109.GA16017@neu.nirvana> On Thu, Oct 05, 2006 at 02:15:58AM -0300, Alexandre Oliva wrote: > On Oct 2, 2006, Axel Thimm wrote: > > > So, if libtool were to simply ignore dependency_libs when building > > against shared libs wouldn't that solve all issues? > > Nope, it would only solve the common case. > > It is perfectly possible for a dynamic library to depend on a > static-only library. And it's even possible to create other dynamic > libraries out of that, if the static-only library is PIC or the > platform can handle non-PIC in dynamic libraries. So? That's not a problem with the mentioned patch. > > If so the patch looks almost trivial and is far better than to setup > > workflows on whether removing some *.la files and still have some > > false positives/negatives. > > Breaking the libtool sources that get installed for packagers all over > the world to use, for deployment on various operating systems, is not > really an option I'd recommend. Nobody suggested breaking anything. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aoliva at redhat.com Fri Oct 6 02:19:50 2006 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 05 Oct 2006 23:19:50 -0300 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061005095109.GA16017@neu.nirvana> (Axel Thimm's message of "Thu, 5 Oct 2006 11:51:09 +0200") References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> <20061005095109.GA16017@neu.nirvana> Message-ID: On Oct 5, 2006, Axel Thimm wrote: > On Thu, Oct 05, 2006 at 02:15:58AM -0300, Alexandre Oliva wrote: >> On Oct 2, 2006, Axel Thimm wrote: >> >> > So, if libtool were to simply ignore dependency_libs when building >> > against shared libs wouldn't that solve all issues? >> >> Nope, it would only solve the common case. >> >> It is perfectly possible for a dynamic library to depend on a >> static-only library. And it's even possible to create other dynamic >> libraries out of that, if the static-only library is PIC or the >> platform can handle non-PIC in dynamic libraries. > So? That's not a problem with the mentioned patch. Ignoring dependency_libs would break the following case: - libA.la, static only, provides symbol A - libB.la is linked with libA but doesn't bring in symbol A - program links with libB rightfully expecting it to provide a definition for A -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From rdieter at math.unl.edu Fri Oct 6 04:06:26 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 05 Oct 2006 23:06:26 -0500 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> <20061005095109.GA16017@neu.nirvana> Message-ID: Alexandre Oliva wrote: > On Oct 5, 2006, Axel Thimm wrote: >> So? That's not a problem with the mentioned patch. > Ignoring dependency_libs would break the following case: > - libA.la, static only... Right, but: 1. That's why I mentioned on the libtool ml that the patch should only apply in non-static lib cases (though I haven't the foggiest the complications involved in implementing that). 2. Good thing we don't package static libs (or at least *strongly* discouraged). -- Rex From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Oct 9 13:13:43 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 9 Oct 2006 15:13:43 +0200 Subject: [Fedora-packaging] Kernel modules packaged for dkms Message-ID: <20061009151343.6d968164@python3.es.egwn.lan> Hi, Regarding kernel modules, as many, I got tired of : 1) Packaging them as binary rpms, tracking new kernels to release new packages (it's almost impossible to track Rawhide btw). 2) Endless discussions about what packaging method is the best, upgrade paths, ugliness of versions inside names, common vs. kernel specific bits etc. etc. So I decided to go for the dkms approach to install 3rd party kernel modules, and things got so much simpler. It's pretty obvious : If one can issue a simple "make" to get a required module, why go through so much complexity for rpm packages? There are two possible discussions which can start here : 1) What do Fedora packagers think of dkms? Up to now, no kernel modules packages using dkms have been released in Extras, nor in 3rd party repositories AFAIK. Maybe there are some good reasons, in which case I'm interested in knowing them. 2) If kernel modules packages using dkms are acceptable for Extras, what guidelines should they follow? Here we'd need at least : - A naming guideline, for which I'd suggest "dkms-" (Mandrake seems to be using that). - Recommendations for the dkms calls in the scriplets. Do we build the module for the current kernel on install (I do)? Do we run depmod on install (I don't, but maybe I should)? I'm possibly missing stuff. Anyway, here are some pointers : http://svn.rpmforge.net/svn/trunk/rpms/dkms-tiacx/ (Extras candidate) http://svn.rpmforge.net/svn/trunk/rpms/dkms-ipw3945/ (Needs fw/daemon) http://svn.rpmforge.net/svn/trunk/rpms/madwifi/ (HAL license problem) http://svn.rpmforge.net/svn/trunk/rpms/nvidia-x11-drv/ (definite NO!) The last two are good examples of packages that provide both userland tools and kernel modules, and show how splitting out sub-packages isn't even required for this case. Obviously, most 3rd party kernel modules aren't Extras candidates because of licensing issues, but it would be nice nevertheless to have some official Extras packaging guidelines for packages using dkms. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2726.fc6 Load : 2.72 2.84 1.53 From jcm at redhat.com Mon Oct 9 13:20:31 2006 From: jcm at redhat.com (Jon Masters) Date: Mon, 09 Oct 2006 14:20:31 +0100 Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: <20061009151343.6d968164@python3.es.egwn.lan> References: <20061009151343.6d968164@python3.es.egwn.lan> Message-ID: <1160400032.3423.26.camel@localhost.localdomain> On Mon, 2006-10-09 at 15:13 +0200, Matthias Saou wrote: > 1) What do Fedora packagers think of dkms? It requires building on the target to get the most out of it, and therefore necessitates that you have those tools installed. Having said that, I'd like to see DKMS being used on Fedora, just I think we can't expect everyone to have working toolchains installed. Jon. P.S. I know it's not that clear-cut. You can always use some of DKMS functionality anyway - it supports SuSE KMPs and in due course will probably support the ABI tracking kmods in Fedora too... -- Jon Masters Cellphone: +44 7776 131337 Red Hat, Inc. Email: jcm at redhat.com From rdieter at math.unl.edu Mon Oct 9 13:23:08 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 09 Oct 2006 08:23:08 -0500 Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: <1160400032.3423.26.camel@localhost.localdomain> References: <20061009151343.6d968164@python3.es.egwn.lan> <1160400032.3423.26.camel@localhost.localdomain> Message-ID: <452A4D3C.6040405@math.unl.edu> Jon Masters wrote: > On Mon, 2006-10-09 at 15:13 +0200, Matthias Saou wrote: > >> 1) What do Fedora packagers think of dkms? > > It requires building on the target to get the most out of it, and > therefore necessitates that you have those tools installed. > > Having said that, I'd like to see DKMS being used on Fedora, just I > think we can't expect everyone to have working toolchains installed. If folks will by using dkms-* rpms, then yes, given proper 'Requires: foo' magic, we can. Unless you meant say something like "We can't expect everyone to like the necessity of having build toolchains just for dkms's..." -- rex From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Oct 9 13:31:49 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 9 Oct 2006 15:31:49 +0200 Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: <1160400032.3423.26.camel@localhost.localdomain> References: <20061009151343.6d968164@python3.es.egwn.lan> <1160400032.3423.26.camel@localhost.localdomain> Message-ID: <20061009153149.5eec5dce@python3.es.egwn.lan> Jon Masters wrote : > Having said that, I'd like to see DKMS being used on Fedora, just I > think we can't expect everyone to have working toolchains installed. Yeah, the packages pulled in by gcc (glibc-devel) and kernel-devel are the main drawback. But, as much as I don't like installing anything which isn't _really_ required on a system, since these 3rd party kernel modules shouldn't be something everyone needs, and since the full kernel sources aren't required nowadays (only the much smaller kernel-devel), it's a "limited" drawback, that people wanting to install 3rd party kernel modules should be willing to accept ;-) Note that one can also use dkms to create rpm packages of the modules, I haven't tried that, but it would add a layer of complexity to the packaging and the build system. I definitely prefer keeping things as simple as possible. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2726.fc6 Load : 1.60 1.40 1.24 From paul at city-fan.org Mon Oct 9 13:52:32 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 09 Oct 2006 14:52:32 +0100 Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: <20061009151343.6d968164@python3.es.egwn.lan> References: <20061009151343.6d968164@python3.es.egwn.lan> Message-ID: <452A5420.2060103@city-fan.org> Matthias Saou wrote: > Hi, > > Regarding kernel modules, as many, I got tired of : > 1) Packaging them as binary rpms, tracking new kernels to release new > packages (it's almost impossible to track Rawhide btw). > 2) Endless discussions about what packaging method is the best, upgrade > paths, ugliness of versions inside names, common vs. kernel specific > bits etc. etc. > > So I decided to go for the dkms approach to install 3rd party kernel > modules, and things got so much simpler. It's pretty obvious : If one > can issue a simple "make" to get a required module, why go through so > much complexity for rpm packages? > > There are two possible discussions which can start here : > > 1) What do Fedora packagers think of dkms? Up to now, no kernel modules > packages using dkms have been released in Extras, nor in 3rd party > repositories AFAIK. Maybe there are some good reasons, in which case > I'm interested in knowing them. The ppp_mppe kernel module was successfully distributed as a dkms-based RPM package by the PPTP Client project before the module got included upstream in 2.6.15 (and is still used by distributions having older kernels). http://pptpclient.sourceforge.net/yum/ Paul. From fedora at leemhuis.info Mon Oct 9 15:38:34 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 09 Oct 2006 17:38:34 +0200 Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: <20061009151343.6d968164@python3.es.egwn.lan> References: <20061009151343.6d968164@python3.es.egwn.lan> Message-ID: <452A6CFA.1080205@leemhuis.info> Matthias Saou schrieb: > Regarding kernel modules, as many, I got tired of : > 1) Packaging them as binary rpms, tracking new kernels to release new > packages (it's almost impossible to track Rawhide btw). Well, the plan always was to be: Have support for kmod in the buildsys and automate these things. Due to discussing kmod in the past again and some other stuff it was never implemented. Now that we get more kmod in Extras we should driver this forward again. > 2) Endless discussions about what packaging method is the best, upgrade > paths, ugliness of versions inside names, common vs. kernel specific > bits etc. etc. Including this mail ;-) > So I decided to go for the dkms approach to install 3rd party kernel > modules, and things got so much simpler. It's pretty obvious : If one > can issue a simple "make" to get a required module, why go through so > much complexity for rpm packages? Well, with that argument we could stop our work on Fedora and RPM and move over to Gentoo ;-) Further: That argument ("can issue a simple "make"") in parts also holds true for dkms itself, too. In the beginning (2.4 days) dkms was a nice idea because it easily allowed to compile modules for different kernels. But exactly that function can be done by all 2.6 kernels without dkms if they are shipped properly. Sure, dkms can do a lot more these days, but I don't think we need most of it. > There are two possible discussions which can start here : > 1) What do Fedora packagers think of dkms? We looked at it before we started the kmod effort and choose not to use it. I don't see any reasons why this should have changed in between. > Up to now, no kernel modules > packages using dkms have been released in Extras, nor in 3rd party > repositories AFAIK. Maybe there are some good reasons, in which case > I'm interested in knowing them. Well, dkms kernel-modules are not directly forbidden (at least it's not written down somewhere), but we choose to use kmod for kernel-module packages -- so they are not allowed AFAICS. And I don't think that we should change this as it helps people not much if we put two or more competing standards in Fedora Core/Extras. > [...] I'm not in general against rebuilding modules on the users system -- but it should be a option (e.g. for rawhide users), not the norm. I actually implemented a small script once that did what most users want -- simply rebuild the kmod-foo.srpm during boot up for the running kernel. I can work on it again if people are interested. It did what we are interested in in 5k -- dkms does a lot more what we don't need in 100k. CU thl From nicolas.mailhot at laposte.net Mon Oct 9 15:23:59 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 9 Oct 2006 17:23:59 +0200 (CEST) Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: <20061009153149.5eec5dce@python3.es.egwn.lan> References: <20061009151343.6d968164@python3.es.egwn.lan> <1160400032.3423.26.camel@localhost.localdomain> <20061009153149.5eec5dce@python3.es.egwn.lan> Message-ID: <20056.192.54.193.51.1160407439.squirrel@rousalka.dyndns.org> Le Lun 9 octobre 2006 15:31, Matthias Saou a ?crit : > Note that one can also use dkms to create rpm packages of the modules, > I haven't tried that, I think that for most people who tried it: 1. dkms vs in-core module: dkms loses 2. dkms vs other form of external modules (kmdl or fedora-style) : dkms wins. I know which form I took as base when I had to package ivtv 0.8 last week-end. Also dkms will increase the pressure on not applying fedora-specific patches over the upstream kernel. Don't know if it's a good or a bad thing (I know davej's opinion) Regards, -- Nicolas Mailhot From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Oct 9 16:13:06 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 9 Oct 2006 18:13:06 +0200 Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: <20056.192.54.193.51.1160407439.squirrel@rousalka.dyndns.org> References: <20061009151343.6d968164@python3.es.egwn.lan> <1160400032.3423.26.camel@localhost.localdomain> <20061009153149.5eec5dce@python3.es.egwn.lan> <20056.192.54.193.51.1160407439.squirrel@rousalka.dyndns.org> Message-ID: <20061009181306.032cde5f@python3.es.egwn.lan> Nicolas Mailhot wrote : > I think that for most people who tried it: > 1. dkms vs in-core module: dkms loses > 2. dkms vs other form of external modules (kmdl or fedora-style) : dkms wins. I confirm that for my own case. > Also dkms will increase the pressure on not applying fedora-specific > patches over the upstream kernel. Don't know if it's a good or a bad thing > (I know davej's opinion) I'm not sure I understand the first sentence correctly :-/ If you meant that it will reduce pressure to apply Fedora specific patches, it's probably a good thing for the Fedora kernel maintainers, since a parallel effort can be made to get the module(s) into the upstream kernel, unless of course the Fedora kernel maintainers get swamped with bug reports where kernels are tainted and/or running buggy modules that don't come from the Fedora kernel... But this discussion is also valid for the kmod packaging scheme anyway. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2726.fc6 Load : 1.43 1.46 1.20 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Oct 9 16:30:33 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 9 Oct 2006 18:30:33 +0200 Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: <452A6CFA.1080205@leemhuis.info> References: <20061009151343.6d968164@python3.es.egwn.lan> <452A6CFA.1080205@leemhuis.info> Message-ID: <20061009183033.08e77573@python3.es.egwn.lan> Thorsten Leemhuis wrote : [...] > Well, dkms kernel-modules are not directly forbidden (at least it's not > written down somewhere), but we choose to use kmod for kernel-module > packages -- so they are not allowed AFAICS. Then I'd like the people who pushed the kmod scheme to be accepted to try and get it to be 100% functional ASAP, as the whole build server side, to get automated rebuilds for all newly released kernels is quite far from being implemented (unless I'm mistaken). > And I don't think that we should change this as it helps people not much > if we put two or more competing standards in Fedora Core/Extras. > > > [...] > > I'm not in general against rebuilding modules on the users system -- but > it should be a option (e.g. for rawhide users), not the norm. I actually > implemented a small script once that did what most users want -- simply > rebuild the kmod-foo.srpm during boot up for the running kernel. I can > work on it again if people are interested. It did what we are interested > in in 5k -- dkms does a lot more what we don't need in 100k. But dkms is quite solid, handles errors in a user friendly way... and "just works" overall while keeping things simple. Sure, the actual modules aren't in the rpmdb, but are easily identifiable (dkms.conf). I would really prefer to have all kernel modules cleanly installed with rpm, believe me, but I'm simply not comfortable with any of the current packaging schemes. I packaged acx100 as acx-kmod a few months ago : http://svn.rpmforge.net/svn/trunk/rpms/acx-kmod-common/ http://svn.rpmforge.net/svn/trunk/rpms/acx-kmod/ Honestly, it stopped me from wanting to package more kernel modules... :-( Yesterday, I packaged the newer tiacx as dkms-tiacx : http://svn.rpmforge.net/svn/trunk/rpms/dkms-tiacx/ ...and it made me want to package _more_ kernel modules! The most painful part for kmod is getting a build environment ready to rebuild the module for all the different kernels. The whole complexity of the spec file filled with macros and stuff generated from the kmodtool script doesn't help either. I'm sure that if I had wrote it, I wouldn't see it as being so complex... but I didn't. Anyway, I think you answered my questions : dkms packages aren't what Extras want, so no need to bother. For the time being, I think I'll stick with dkms for my own 3rd party kernel modules, and move to kmod only once the framework to make packagers' life easier will be ready. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2726.fc6 Load : 0.22 0.38 0.70 From smooge at gmail.com Mon Oct 9 23:37:40 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 9 Oct 2006 17:37:40 -0600 Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: <20061009151343.6d968164@python3.es.egwn.lan> References: <20061009151343.6d968164@python3.es.egwn.lan> Message-ID: <80d7e4090610091637j24fad8f7r9897426079ad0306@mail.gmail.com> On 10/9/06, Matthias Saou wrote: > Hi, > > Regarding kernel modules, as many, I got tired of : > 1) Packaging them as binary rpms, tracking new kernels to release new > packages (it's almost impossible to track Rawhide btw). > 2) Endless discussions about what packaging method is the best, upgrade > paths, ugliness of versions inside names, common vs. kernel specific > bits etc. etc. > After dealing with various fedora systems where someone gets a kernel update and things not working because an extra drvier wasnt ready.. I am all for the dkms solution as a system administrator. Yes it takes more stuff on a client system, but for my workloads.. it has worked out a better solution for my fedora and enterprise systems. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From Matt_Domsch at dell.com Tue Oct 10 05:03:07 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 10 Oct 2006 00:03:07 -0500 Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: <20061009151343.6d968164@python3.es.egwn.lan> References: <20061009151343.6d968164@python3.es.egwn.lan> Message-ID: <20061010050307.GA25620@lists.us.dell.com> On Mon, Oct 09, 2006 at 03:13:43PM +0200, Matthias Saou wrote: > Hi, > > Regarding kernel modules, as many, I got tired of : > 1) Packaging them as binary rpms, tracking new kernels to release new > packages (it's almost impossible to track Rawhide btw). > 2) Endless discussions about what packaging method is the best, upgrade > paths, ugliness of versions inside names, common vs. kernel specific > bits etc. etc. > > So I decided to go for the dkms approach to install 3rd party kernel > modules, and things got so much simpler. It's pretty obvious : If one > can issue a simple "make" to get a required module, why go through so > much complexity for rpm packages? > > There are two possible discussions which can start here : > > 1) What do Fedora packagers think of dkms? Up to now, no kernel modules > packages using dkms have been released in Extras, nor in 3rd party > repositories AFAIK. Maybe there are some good reasons, in which case > I'm interested in knowing them. The dell-software repo http://linux.dell.com/repo/software/ distributes openipmi, dcdbas, and dell_rbu for RHEL[34], SLES9, and FC[34] because those distros didn't originally have them. We've since gotten those driver into kernel.org and therefore newer kernels and distro versions, which has always been our goal all along - use DKMS as a stop-gap until upstream and every distro kernel has a good-enough version of each driver to not need to package them separately. I'm glad for all the renewed interest, I had no idea how many people were really packaging drivers using DKMS outside of Dell and our immediate partners. And yes, I owe Jon Masters some more time getting DKMS fully up to speed with the work he's been doing with kerneldrivers.org and KMPs. I'm getting there, I promise! Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From pmatilai at laiskiainen.org Tue Oct 10 08:00:23 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 10 Oct 2006 11:00:23 +0300 (EEST) Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: <20061009183033.08e77573@python3.es.egwn.lan> References: <20061009151343.6d968164@python3.es.egwn.lan> <452A6CFA.1080205@leemhuis.info> <20061009183033.08e77573@python3.es.egwn.lan> Message-ID: On Mon, 9 Oct 2006, Matthias Saou wrote: > Thorsten Leemhuis wrote : > > [...] >> Well, dkms kernel-modules are not directly forbidden (at least it's not >> written down somewhere), but we choose to use kmod for kernel-module >> packages -- so they are not allowed AFAICS. > > Then I'd like the people who pushed the kmod scheme to be accepted to > try and get it to be 100% functional ASAP, as the whole build server > side, to get automated rebuilds for all newly released kernels is quite > far from being implemented (unless I'm mistaken). IIRC dkms was never *really* considered for the kernel module standard, everybody was too busy arguing over uname-r in name, how to handle debuginfo packages, what kind of macro magic to include, how many kernels to build for in buildsys, how to teach the kmod scheme to buildsys etc. >> And I don't think that we should change this as it helps people not much >> if we put two or more competing standards in Fedora Core/Extras. >> >>> [...] >> >> I'm not in general against rebuilding modules on the users system -- but >> it should be a option (e.g. for rawhide users), not the norm. I actually >> implemented a small script once that did what most users want -- simply >> rebuild the kmod-foo.srpm during boot up for the running kernel. I can >> work on it again if people are interested. It did what we are interested >> in in 5k -- dkms does a lot more what we don't need in 100k. > > But dkms is quite solid, handles errors in a user friendly way... > and "just works" overall while keeping things simple. Sure, the actual > modules aren't in the rpmdb, but are easily identifiable (dkms.conf). I > would really prefer to have all kernel modules cleanly installed with > rpm, believe me, but I'm simply not comfortable with any of the current > packaging schemes. > > I packaged acx100 as acx-kmod a few months ago : > http://svn.rpmforge.net/svn/trunk/rpms/acx-kmod-common/ > http://svn.rpmforge.net/svn/trunk/rpms/acx-kmod/ > > Honestly, it stopped me from wanting to package more kernel > modules... :-( Yesterday, I packaged the newer tiacx as dkms-tiacx : > http://svn.rpmforge.net/svn/trunk/rpms/dkms-tiacx/ > > ...and it made me want to package _more_ kernel modules! The most > painful part for kmod is getting a build environment ready to rebuild > the module for all the different kernels. The whole complexity of the > spec file filled with macros and stuff generated from the kmodtool > script doesn't help either. I'm sure that if I had wrote it, I wouldn't > see it as being so complex... but I didn't. Amen brother :) I've been intending to have a look at dkms for a long time, your post on the subject finally pushed me to actually do so. After converting a couple of kernel module packages (internal stuff at work) over to dkms, I'm simply loving it. It's going to save me a helluva lot of time wasted on dealing with rebuilding kernel modules for this-and-that kernel, please the propellerheads running their own custom kernels and removes pretty much the impossibility of trying to deal with kernel module dependencies in some semi-correct way. My only regret now is that I haven't looked at DKMS earlier :) - Panu - From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Oct 10 09:09:32 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 10 Oct 2006 11:09:32 +0200 Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: References: <20061009151343.6d968164@python3.es.egwn.lan> <452A6CFA.1080205@leemhuis.info> <20061009183033.08e77573@python3.es.egwn.lan> Message-ID: <20061010110932.79a17135@python3.es.egwn.lan> Panu Matilainen wrote : > Amen brother :) I've been intending to have a look at dkms for a long > time, your post on the subject finally pushed me to actually do so. After > converting a couple of kernel module packages (internal stuff at work) > over to dkms, I'm simply loving it. > > It's going to save me a helluva lot of time wasted on dealing with > rebuilding kernel modules for this-and-that kernel, please the > propellerheads running their own custom kernels and removes pretty much > the impossibility of trying to deal with kernel module dependencies in > some semi-correct way. Well, the dkms approach is definitely best when it comes to enterprise distributions (for which few or no kmod packages are available), custom kernels or even rawhide. > My only regret now is that I haven't looked at DKMS earlier :) Same here. And I definitely owe Gary Lerhaupt (the original author it seems) an apology, as he contacted me back in early 2004 to explain what dkms was and asked me if I'd be interested in making it available on freshrpms. But I never took the time to look at it :-( Maybe my original questions are still relevant, as if other people here are interested in dkms kernel module packages for their own needs, we might as well agree on a common naming scheme and some common guidelines. For now, I've been leaving the dkms enabled sources in the "main" packages for projects that contain more than just kernel bits (nvidia, madwifi), but still providing "dkms- = V-R". Simple modules I've named "dkms-" (dkms-tiacx, dkms-ipw3945). As for the scriplets, I've just tried to add the rpm release to the module version in order to make it easier to update a kernel module to the same upstream version (i.e. a patched and fixed package), but I'm not sure it's actually needed since I was still hitting other problems. I'm still looking for the best solution to completely avoid corner cases, make sure we never end up with a missing module, and handle all possible updates correctly. This seems to work : %post # Add to DKMS registry dkms add -m %{dkms_name} -v %{version}-%{release} -q --rpm_safe_upgrade # Reuild and make available for the currenty running kernel dkms build -m %{dkms_name} -v %{version}-%{release} -q || : dkms install -m %{dkms_name} -v %{version}-%{release} -q --force || : %preun # Remove all versions from DKMS registry dkms remove -m %{dkms_name} -v %{version}-%{release} -q --all \ --rpm_safe_upgrade But I'd like to avoid the --force, though.. I just can't seem to find a way around it. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2726.fc6 Load : 0.31 0.26 0.26 From skvidal at linux.duke.edu Tue Oct 10 12:34:28 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 10 Oct 2006 08:34:28 -0400 Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: References: <20061009151343.6d968164@python3.es.egwn.lan> <452A6CFA.1080205@leemhuis.info> <20061009183033.08e77573@python3.es.egwn.lan> Message-ID: <1160483668.1308.44.camel@cutter> On Tue, 2006-10-10 at 11:00 +0300, Panu Matilainen wrote: > On Mon, 9 Oct 2006, Matthias Saou wrote: > > Thorsten Leemhuis wrote : > > > > [...] > >> Well, dkms kernel-modules are not directly forbidden (at least it's not > >> written down somewhere), but we choose to use kmod for kernel-module > >> packages -- so they are not allowed AFAICS. > > > > Then I'd like the people who pushed the kmod scheme to be accepted to > > try and get it to be 100% functional ASAP, as the whole build server > > side, to get automated rebuilds for all newly released kernels is quite > > far from being implemented (unless I'm mistaken). > > IIRC dkms was never *really* considered for the kernel module standard, > everybody was too busy arguing over uname-r in name, how to handle > debuginfo packages, what kind of macro magic to include, how many kernels > to build for in buildsys, how to teach the kmod scheme to buildsys etc. > I think dkms is a good solution for sysadmins managing a bunch of systems - but for our use situation it causes issues b/c we want people to be able to install and use kernel modules w/o having to build them and/or have all the build tools installed. -sv From rdieter at math.unl.edu Tue Oct 10 12:39:04 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 10 Oct 2006 07:39:04 -0500 Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: <1160483668.1308.44.camel@cutter> References: <20061009151343.6d968164@python3.es.egwn.lan> <452A6CFA.1080205@leemhuis.info> <20061009183033.08e77573@python3.es.egwn.lan> <1160483668.1308.44.camel@cutter> Message-ID: <452B9468.1070807@math.unl.edu> seth vidal wrote: > I think dkms is a good solution for sysadmins managing a bunch of > systems - but for our use situation it causes issues b/c we want people > to be able to install and use kernel modules w/o having to build them > and/or have all the build tools installed. You imply there are issues beyond simply the requirement of having build tools installed (and used). What are they? -- Rex From pmatilai at laiskiainen.org Tue Oct 10 12:47:17 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 10 Oct 2006 15:47:17 +0300 (EEST) Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: <1160483668.1308.44.camel@cutter> References: <20061009151343.6d968164@python3.es.egwn.lan> <452A6CFA.1080205@leemhuis.info> <20061009183033.08e77573@python3.es.egwn.lan> <1160483668.1308.44.camel@cutter> Message-ID: On Tue, 10 Oct 2006, seth vidal wrote: > On Tue, 2006-10-10 at 11:00 +0300, Panu Matilainen wrote: >> On Mon, 9 Oct 2006, Matthias Saou wrote: >>> Thorsten Leemhuis wrote : >>> >>> [...] >>>> Well, dkms kernel-modules are not directly forbidden (at least it's not >>>> written down somewhere), but we choose to use kmod for kernel-module >>>> packages -- so they are not allowed AFAICS. >>> >>> Then I'd like the people who pushed the kmod scheme to be accepted to >>> try and get it to be 100% functional ASAP, as the whole build server >>> side, to get automated rebuilds for all newly released kernels is quite >>> far from being implemented (unless I'm mistaken). >> >> IIRC dkms was never *really* considered for the kernel module standard, >> everybody was too busy arguing over uname-r in name, how to handle >> debuginfo packages, what kind of macro magic to include, how many kernels >> to build for in buildsys, how to teach the kmod scheme to buildsys etc. >> > > I think dkms is a good solution for sysadmins managing a bunch of > systems - but for our use situation it causes issues b/c we want people > to be able to install and use kernel modules w/o having to build them > and/or have all the build tools installed. Requiring clients to have build tools installed is a downside to dkms, yes, but me thinks it's really just a minor nuisance compared to the hideous mess of kernel module rpms. - Panu - From skvidal at linux.duke.edu Tue Oct 10 12:52:54 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 10 Oct 2006 08:52:54 -0400 Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: <452B9468.1070807@math.unl.edu> References: <20061009151343.6d968164@python3.es.egwn.lan> <452A6CFA.1080205@leemhuis.info> <20061009183033.08e77573@python3.es.egwn.lan> <1160483668.1308.44.camel@cutter> <452B9468.1070807@math.unl.edu> Message-ID: <1160484774.1308.48.camel@cutter> On Tue, 2006-10-10 at 07:39 -0500, Rex Dieter wrote: > seth vidal wrote: > > > I think dkms is a good solution for sysadmins managing a bunch of > > systems - but for our use situation it causes issues b/c we want people > > to be able to install and use kernel modules w/o having to build them > > and/or have all the build tools installed. > > You imply there are issues beyond simply the requirement of having build > tools installed (and used). What are they? > I didn't mean to imply that. That's all I was trying to say. -sv From skvidal at linux.duke.edu Tue Oct 10 12:54:04 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 10 Oct 2006 08:54:04 -0400 Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: References: <20061009151343.6d968164@python3.es.egwn.lan> <452A6CFA.1080205@leemhuis.info> <20061009183033.08e77573@python3.es.egwn.lan> <1160483668.1308.44.camel@cutter> Message-ID: <1160484844.1308.50.camel@cutter> On Tue, 2006-10-10 at 15:47 +0300, Panu Matilainen wrote: > On Tue, 10 Oct 2006, seth vidal wrote: > > > On Tue, 2006-10-10 at 11:00 +0300, Panu Matilainen wrote: > >> On Mon, 9 Oct 2006, Matthias Saou wrote: > >>> Thorsten Leemhuis wrote : > >>> > >>> [...] > >>>> Well, dkms kernel-modules are not directly forbidden (at least it's not > >>>> written down somewhere), but we choose to use kmod for kernel-module > >>>> packages -- so they are not allowed AFAICS. > >>> > >>> Then I'd like the people who pushed the kmod scheme to be accepted to > >>> try and get it to be 100% functional ASAP, as the whole build server > >>> side, to get automated rebuilds for all newly released kernels is quite > >>> far from being implemented (unless I'm mistaken). > >> > >> IIRC dkms was never *really* considered for the kernel module standard, > >> everybody was too busy arguing over uname-r in name, how to handle > >> debuginfo packages, what kind of macro magic to include, how many kernels > >> to build for in buildsys, how to teach the kmod scheme to buildsys etc. > >> > > > > I think dkms is a good solution for sysadmins managing a bunch of > > systems - but for our use situation it causes issues b/c we want people > > to be able to install and use kernel modules w/o having to build them > > and/or have all the build tools installed. > > Requiring clients to have build tools installed is a downside to dkms, > yes, but me thinks it's really just a minor nuisance compared to the > hideous mess of kernel module rpms. > I disagree. I'd rather not force users on laptops to be exposed to that level of pain. -sv From Matt_Domsch at dell.com Tue Oct 10 13:23:59 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 10 Oct 2006 08:23:59 -0500 Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: <1160483668.1308.44.camel@cutter> References: <20061009151343.6d968164@python3.es.egwn.lan> <452A6CFA.1080205@leemhuis.info> <20061009183033.08e77573@python3.es.egwn.lan> <1160483668.1308.44.camel@cutter> Message-ID: <20061010132359.GA10004@lists.us.dell.com> On Tue, Oct 10, 2006 at 08:34:28AM -0400, seth vidal wrote: > I think dkms is a good solution for sysadmins managing a bunch of > systems - but for our use situation it causes issues b/c we want people > to be able to install and use kernel modules w/o having to build them > and/or have all the build tools installed. To be fair, DKMS doesn't strictly require the build tools and/or kernel-$foo-devel be installed. (The current Extras requirement that kernel-devel be installed is, IMHO, a mistake, but FE Review strongly asked for it). It's designed to use kernel-devel and a toolchain if present and no prebuilt module exists for your currently running kernel. Like the current FE kmod proposal, the build system *could* rebuild *dkms drivers for the new kernel, and repackage them in the *dkms package. Exactly the same pain is needed for kmods; DKMS just gives you an "out" if you've got a toolchain and kernel-devel installed but your package provider hasn't (yet) respun their *dkms package. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From aoliva at redhat.com Thu Oct 12 06:21:01 2006 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 12 Oct 2006 03:21:01 -0300 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: (Rex Dieter's message of "Thu, 05 Oct 2006 23:06:26 -0500") References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> <20061005095109.GA16017@neu.nirvana> Message-ID: On Oct 6, 2006, Rex Dieter wrote: > Alexandre Oliva wrote: >> On Oct 5, 2006, Axel Thimm wrote: >>> So? That's not a problem with the mentioned patch. >> Ignoring dependency_libs would break the following case: >> - libA.la, static only... > 2. Good thing we don't package static libs (or at least *strongly* > discouraged). This is too narrow a vision. Fedora is a major development platform for packages that ship libtool-using packages for many different platforms. If we break libtool such that it still works for us, but won't work for others, people who develop their packages on Fedora will think libtool will get them the portability they expect, but it won't because Fedora broke the portability. Thinking of Fedora-only changes for libtool is completely missing the point about how libtool is used. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From Axel.Thimm at ATrpms.net Thu Oct 12 08:47:26 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 12 Oct 2006 10:47:26 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <45194CF5.3090509@math.unl.edu> References: <45194CF5.3090509@math.unl.edu> Message-ID: <20061012084726.GA7721@neu.nirvana> Revisting the root of evil. What exactly is wrong with not removing all *.la files? Bloated dependencies in *-devel packages? If that's the only reason, was the (ongoing) pain worth the trouble? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Thu Oct 12 10:58:24 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 12 Oct 2006 12:58:24 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061012084726.GA7721@neu.nirvana> (Axel Thimm's message of "Thu, 12 Oct 2006 10:47:26 +0200") References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> Message-ID: <87bqoh2433.fsf@fc5.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: > Revisting the root of evil. What exactly is wrong with not removing > all *.la files? - .la files must be shipped in main package, not in -devel - they add untracked dependencies to the rpm packages: when B was built against A which has libA.la, B will stop to work when A does not ship libA.la anymore (e.g. because it uses now cmake). - .la files are not required Enrico From Axel.Thimm at ATrpms.net Thu Oct 12 12:32:52 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 12 Oct 2006 14:32:52 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <87bqoh2433.fsf@fc5.bigo.ensc.de> References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> Message-ID: <20061012123252.GA3985@neu.nirvana> On Thu, Oct 12, 2006 at 12:58:24PM +0200, Enrico Scholz wrote: > Axel.Thimm at ATrpms.net (Axel Thimm) writes: > > > Revisting the root of evil. What exactly is wrong with not removing > > all *.la files? > > - .la files must be shipped in main package, not in -devel Obviously "must" is the wrong word since they are currently nuked away. And the issue seems to be when using the information on the dependent libraries inside which only affects *-devel files independent whether *.la is part of the main or the *-devel file. E.g. keep the *.la if you like in the main packge or elsewhere, the issue is still only "bloat in BRs in *-devel". Do you agree? > - they add untracked dependencies to the rpm packages: when B was built > against A which has libA.la, B will stop to work when A does not ship > libA.la anymore (e.g. because it uses now cmake). It will also break when libA changes the soname, an API, add/remove include files and the like. And changes to the build system of a package are certainly far less often than changes to it' API/ABI, so we can certainly live with that. > - .la files are not required Seems to really depend on the software generating/using them. Or from a different viewpoint: if they really were not required (on Linux), then why are libtool authors installing them (on Linux)? We wouldn't be having this thread if the simple statement ".la files are not required" would indeed hold true. So ATM I'm still not convinced that there is any other drawback than a couple too many BRs on *-devel packages. And IMHO that doesn't compare to the pain and complexity we have created in having packagers selectively judge on the necessity or not of *.la files. I just saw yet another report on fedora-list that is induced by removing *.la files on some packages and not all. And to mention it again: The libtool authors are open to any improvement that would please us. Some patches that do 95% of what we want are already floating around or are even in production at other distributions. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Thu Oct 12 14:00:24 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 12 Oct 2006 16:00:24 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061012123252.GA3985@neu.nirvana> (Axel Thimm's message of "Thu, 12 Oct 2006 14:32:52 +0200") References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> <20061012123252.GA3985@neu.nirvana> Message-ID: <8764ep1vnr.fsf@fc5.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: >> > Revisting the root of evil. What exactly is wrong with not removing >> > all *.la files? >> >> - .la files must be shipped in main package, not in -devel > > Obviously "must" is the wrong word since they are currently nuked > away. Sentence was written under the assumption that all .la files will be shipped (as suggested by your question). > And the issue seems to be when using the information on the dependent > libraries inside which only affects *-devel files independent whether > *.la is part of the main or the *-devel file. No; modules (which are non-devel files) can contain something like | dependency_libs='... /usr/lib/libkickermain.la ...' --> non-devel file requires .la file --> .la files must not be in -devel package > E.g. keep the *.la if you like in the main packge or elsewhere, the > issue is still only "bloat in BRs in *-devel". Do you agree? When it would be only the small .la file in -devel, I agree. But I have problems with shipping a useless file without a good reason in -lib packages. >> - they add untracked dependencies to the rpm packages: when B was >> built against A which has libA.la, B will stop to work when A does >> not ship libA.la anymore (e.g. because it uses now cmake). > > It will also break when libA changes the soname, an API, add/remove > include files and the like. rpm would bark loudly about broken dependencies in these casees. >> - .la files are not required > > Seems to really depend on the software generating/using them. Or from > a different viewpoint: if they really were not required (on Linux), > then why are libtool authors installing them (on Linux)? I know exactly one case where they are required: when software uses 'lt_dlopen("foo.la")'. This can be fixed easily by writing 'lt_dlopenext("foo")'. Installing .la files happens probably only due to legacy reasons. > We wouldn't be having this thread if the simple statement ".la files > are not required" would indeed hold true. See above about lt_dlopen(); KDE (which requires .la) moved away from .la recently. Enrico From rdieter at math.unl.edu Thu Oct 12 14:26:22 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 12 Oct 2006 09:26:22 -0500 Subject: [Fedora-packaging] Re: Re: libtool(.la) archive policy proposal References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> <20061005095109.GA16017@neu.nirvana> Message-ID: Alexandre Oliva wrote: >> 2. Good thing we don't package static libs (or at least *strongly* >> discouraged). > > This is too narrow a vision. > > Fedora is a major development platform for packages that ship > libtool-using packages for many different platforms. > > If we break libtool such that it still works for us I fail to see how simply not including static libs (or needless .la files) in rpms shipped in Fedora, yields the conclusion that we're breaking libtool. Or, are you arguing against the existing "no static lib" policy? -- Rex From rdieter at math.unl.edu Thu Oct 12 14:31:20 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 12 Oct 2006 09:31:20 -0500 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> <20061012123252.GA3985@neu.nirvana> Message-ID: Axel Thimm wrote: > So ATM I'm still not convinced that there is any other drawback than a > couple too many BRs on *-devel packages. It's more than a "couple too many BRs", some complex pkgs would/could get 10+. For one concrete example, see kdelibs: http://bugzilla.redhat.com/170602 Take this to an extreme, and we might as well go back to dropping the minimal buildroot and simply do BuildRequires: world for everything. -- Rex From Axel.Thimm at ATrpms.net Thu Oct 12 18:01:11 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 12 Oct 2006 20:01:11 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> <20061012123252.GA3985@neu.nirvana> Message-ID: <20061012180111.GB11017@neu.nirvana> On Thu, Oct 12, 2006 at 09:31:20AM -0500, Rex Dieter wrote: > Axel Thimm wrote: > > > So ATM I'm still not convinced that there is any other drawback than a > > couple too many BRs on *-devel packages. > > It's more than a "couple too many BRs", some complex pkgs would/could get > 10+. For one concrete example, see kdelibs: > http://bugzilla.redhat.com/170602 > > Take this to an extreme, and we might as well go back to dropping the > minimal buildroot and simply do > BuildRequires: world > for everything. I haven't really checked on what is considered a minimal buildroot these days, but I think nothing in it even comes close to kdelibs :) The issue with a couple more BR or a dozen for some packages like kdelibs just mean that for some chroot builds the build system would install a couple (or dozen) too many *-devel packages (along with the mandatory in both cases non devel packages). The drawback is that these packages will need a couple of seconds more to build. Do we really care? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Oct 12 18:03:12 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 12 Oct 2006 20:03:12 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <8764ep1vnr.fsf@fc5.bigo.ensc.de> References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> <20061012123252.GA3985@neu.nirvana> <8764ep1vnr.fsf@fc5.bigo.ensc.de> Message-ID: <20061012180312.GC11017@neu.nirvana> On Thu, Oct 12, 2006 at 04:00:24PM +0200, Enrico Scholz wrote: > > E.g. keep the *.la if you like in the main packge or elsewhere, the > > issue is still only "bloat in BRs in *-devel". Do you agree? > > When it would be only the small .la file in -devel, I agree. The question on agreeing wasn't on putting it in *-devel or whereever, it was on whether the final issue is simply "bloat in BRs in *-devel" or more. Still agree? > >> - they add untracked dependencies to the rpm packages: when B was > >> built against A which has libA.la, B will stop to work when A does > >> not ship libA.la anymore (e.g. because it uses now cmake). > > > > It will also break when libA changes the soname, an API, add/remove > > include files and the like. > > rpm would bark loudly about broken dependencies in these casees. Indeed? You never hit any funny bugs where gcc happily *warns* you about missing include files and continues to build? > >> - .la files are not required > > > > Seems to really depend on the software generating/using them. Or from > > a different viewpoint: if they really were not required (on Linux), > > then why are libtool authors installing them (on Linux)? > > I know exactly one case where they are required: when software uses > 'lt_dlopen("foo.la")'. > > This can be fixed easily by writing 'lt_dlopenext("foo")'. Is this portable, so that upstream can accept this? What about the normal libtool use where it is required? Removing *.la means that you need to take care of adding non-trivial required flags to the linker manually. E.g. any ISV/IHV packaging under /opt (as the standards tell him to) suddenly needs special handling only for Fedora because we kill *.la. > Installing .la files happens probably only due to legacy reasons. Not really. That would imply that the libtool folks are too dumb to track modern development which is not the case. I raised the issue last week or so and the people there seem knowledgeable enough on it. See also Alexandre's replies to this thread. See also my initial replies to this list discussing about if la files were legacy indeed, that this should be reflected by adapting libtool, not nuking-after-the-fact. > > We wouldn't be having this thread if the simple statement ".la files > > are not required" would indeed hold true. > > See above about lt_dlopen(); KDE (which requires .la) moved away from > .la recently. Check fedora-list for packages breaking outside of kde world, I just saw a report yesterday again. The nuke-la solution has created more problems than it thought it solved. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Oct 12 18:20:03 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 12 Oct 2006 20:20:03 +0200 Subject: [Fedora-packaging] Refining today's "don't touch system fs" guideline Message-ID: <20061012182003.GJ9881@neu.nirvana> We voted today on "Build scripts of packages (%prep, %build, %install and %check) may only alter files (create, modify, delete) under %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process). Further clarification: That should hold true irrespective of the builder's uid" But after thinking about it I'm not quite happy now. Since we go into details naming what the build scripts are, we should make clear that they are not equal in what they may or may not do. For example %{buildroot} should only be modified by %install, not %prep/%build and %check. How about extending the rule and having a root/non-root rule, too, e.g. o Package builds should yield the same results irrespective of the packaging process' uid/gid, for example builds under root and non-root users should behave the same. o Build scripts of packages (%prep, %build, %install and %check) may only alter files (create, modify, delete) under %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process). %{buildroot} should only be allowed to be altered in %install scripts. Note I: The first part of this rule is automatically fulfilled for typical non-user build process uids but the packager should not rely on that, since users may rebuild the src.rpm under root Note II: As a consequence $HOME and similar parts of the filesystem are not to be used directly. Of course some of the allowed write spaces like the builddir, buildroot or $TMPDIR may have been placed under $HOME, so indirectly a user may be writing under $HOME, but direct access to parts under $HOME are strictly forbidden. Note III: Cheating with relative paths (".." escapes) grants you a ticket to packaging hell. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Thu Oct 12 19:24:42 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 12 Oct 2006 21:24:42 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061012180312.GC11017@neu.nirvana> (Axel Thimm's message of "Thu, 12 Oct 2006 20:03:12 +0200") References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> <20061012123252.GA3985@neu.nirvana> <8764ep1vnr.fsf@fc5.bigo.ensc.de> <20061012180312.GC11017@neu.nirvana> Message-ID: <87mz81nxqd.fsf@kosh.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: >> > E.g. keep the *.la if you like in the main packge or elsewhere, the >> > issue is still only "bloat in BRs in *-devel". Do you agree? >> >> When it would be only the small .la file in -devel, I agree. > > The question on agreeing wasn't on putting it in *-devel or whereever, > it was on whether the final issue is simply "bloat in BRs in *-devel" > or more. Still agree? no Final issues are, whether we want useless files with sideeffects in main packages. Another issue: .la files are slowing down library loading significantly because a text file must parsed additionally, instead of interpreting an ELF header. >> >> - they add untracked dependencies to the rpm packages: when B was >> >> built against A which has libA.la, B will stop to work when A does >> >> not ship libA.la anymore (e.g. because it uses now cmake). >> > >> > It will also break when libA changes the soname, an API, add/remove >> > include files and the like. >> >> rpm would bark loudly about broken dependencies in these casees. > > Indeed? You never hit any funny bugs where gcc happily *warns* you > about missing include files and continues to build? Include files are a documented part of an API. .la files are stuff where most developers are unaware of its existence and do not care about it. >> I know exactly one case where they are required: when software uses >> 'lt_dlopen("foo.la")'. >> >> This can be fixed easily by writing 'lt_dlopenext("foo")'. > > Is this portable, so that upstream can accept this? yes > What about the normal libtool use where it is required? Which "normal use"? libtool .la files: * might be required for static linking where static libs have dependencies. --> this is discouraged in Fedora and there exist more powerful alternatives (pkgconfig) * might be required when architecture supports flat library dependencies only (e.g. on Darwin) --> uninteresting for Fedora and there exist more powerful alternatives (pkgconfig) * are used internally when building a package consisting of multiple libs and/or applications --> uninteresting for packaging * are required for 'lt_dlopen("foo.la")' --> can be replaced by 'lt_dlopenext("foo")' > Removing *.la means that you need to take care of adding non-trivial > required flags to the linker manually. Due to reordering of linker options by libtool, only '-l' and '-L' make sense in linker flags. Most dynamic libs should not need '-l' overall and pkgconfig provides the same (and more) functionality. > E.g. any ISV/IHV packaging under /opt I do not see, how /opt fits into any Fedora packaging discussion... > (as the standards tell him to) suddenly needs special handling only > for Fedora because we kill *.la. > >> Installing .la files happens probably only due to legacy reasons. > > Not really. That would imply that the libtool folks are too dumb to > track modern development lt_dlopenext() was probably added while tracking modern development. Declaring a (former) elementary feature (installed .la files) as obsolete requires a quorum and convincing reasons which cover all possible use cases. For Fedora, we can ignore use cases like static linking and flat library dependencies. >> See above about lt_dlopen(); KDE (which requires .la) moved away from >> .la recently. > > Check fedora-list for packages breaking outside of kde world, I just > saw a report yesterday again. The nuke-la solution has created more > problems than it thought it solved. I would make it a packager's decision whether he adds a small patch (lt_dlopenext()) or whether he packages .la files. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From aoliva at redhat.com Thu Oct 12 19:44:19 2006 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 12 Oct 2006 16:44:19 -0300 Subject: [Fedora-packaging] Re: Re: libtool(.la) archive policy proposal In-Reply-To: (Rex Dieter's message of "Thu, 12 Oct 2006 09:26:22 -0500") References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> <20061005095109.GA16017@neu.nirvana> Message-ID: On Oct 12, 2006, Rex Dieter wrote: > Alexandre Oliva wrote: >>> 2. Good thing we don't package static libs (or at least *strongly* >>> discouraged). >> >> This is too narrow a vision. >> >> Fedora is a major development platform for packages that ship >> libtool-using packages for many different platforms. >> >> If we break libtool such that it still works for us > I fail to see how simply not including static libs (or needless .la > files) in rpms shipped in Fedora, yields the conclusion that we're > breaking libtool. It doesn't. It's what you snipped out of my response that clarifies that I objected to a patch to ignore dependency_libs, because *that* would break libtool on other OSes, even though it would make no visible difference for us. > Or, are you arguing against the existing "no static lib" policy? No, I'm not arguing against the "no static lib" policy, and I'm not arguing against removing .la files. I'm only arguing against patching libtool in ways that have negative consequences for other OSes, because this would affect Fedora users that develop on Fedora and expect the libtool in it to deliver them portability to other OSes. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Thu Oct 12 19:47:56 2006 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 12 Oct 2006 16:47:56 -0300 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061012084726.GA7721@neu.nirvana> (Axel Thimm's message of "Thu, 12 Oct 2006 10:47:26 +0200") References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> Message-ID: On Oct 12, 2006, Axel Thimm wrote: > Revisting the root of evil. What exactly is wrong with not removing > all *.la files? Removing all .la files is fine as long as (i) static libraries are not in use at all, or (ii.a) dependent libraries of static libraries are explicitly listed along with the static libraries in link commands using libtool and (ii.b) emulation of dlopening of static libraries is not required. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From rdieter at math.unl.edu Thu Oct 12 19:57:19 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 12 Oct 2006 14:57:19 -0500 Subject: [Fedora-packaging] Re: Re: libtool(.la) archive policy proposal In-Reply-To: References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> <20061005095109.GA16017@neu.nirvana> Message-ID: <452E9E1F.9080509@math.unl.edu> Alexandre Oliva wrote: > I'm not arguing against the "no static lib" policy, and I'm not > arguing against removing .la files. I'm only arguing against patching > libtool in ways that have negative consequences for other OSes, > because this would affect Fedora users that develop on Fedora and > expect the libtool in it to deliver them portability to other OSes. Ah, and you must've missed that I qualified the use of ignoring dependancy_libs only on platforms that *can* (ie, linux) and not using it in the case of static linking. (: -- Rex From aoliva at redhat.com Thu Oct 12 19:58:18 2006 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 12 Oct 2006 16:58:18 -0300 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <87bqoh2433.fsf@fc5.bigo.ensc.de> (Enrico Scholz's message of "Thu, 12 Oct 2006 12:58:24 +0200") References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> Message-ID: On Oct 12, 2006, Enrico Scholz wrote: > Axel.Thimm at ATrpms.net (Axel Thimm) writes: >> Revisting the root of evil. What exactly is wrong with not removing >> all *.la files? > - .la files must be shipped in main package, not in -devel Only if users of the library rely on libltdl and explicitly refer to the .la files. > - they add untracked dependencies to the rpm packages: when B was built > against A which has libA.la, B will stop to work when A does not ship > libA.la anymore (e.g. because it uses now cmake). rpm might be improved to track such dependencies automatically. Or the package ought to list its dependencies explicitly. That's just a packaging bug. Quite inconvenient, I agree. But if A changes its interface by removing the .la file (and that is a change of interface for libtool users), then someone must deal with the consequences. It's not really much different from renaming a library or a header file or moving them to a different directory. Users (as in dependent packages, not people who run the software) are affected by such changes, and that's unfortunate. But it's not libtool that is to blame, it's the removal of the .la file, that was in place before and went missing, and the absence of an rpm dependency reflecting the actual dependency given by the .la files. If you remove a header file from a library, users of that header file will lose just the same. > - .la files are not required In the absence of static libraries, on GNU/Linux systems, they aren't, indeed. In their presence, given a few additional constraints that are relatively easy to comply with, it makes things a bit smaller and faster, so the move is probably a reasonable step, in spite kf the breakage that the removal of interface files (I'm talking about the .la files) is going to cause. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Thu Oct 12 20:01:03 2006 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 12 Oct 2006 17:01:03 -0300 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061012123252.GA3985@neu.nirvana> (Axel Thimm's message of "Thu, 12 Oct 2006 14:32:52 +0200") References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> <20061012123252.GA3985@neu.nirvana> Message-ID: On Oct 12, 2006, Axel Thimm wrote: > Seems to really depend on the software generating/using them. Or from > a different viewpoint: if they really were not required (on Linux), > then why are libtool authors installing them (on Linux)? We wouldn't > be having this thread if the simple statement ".la files are not > required" would indeed hold true. They're part of the portable libtool library abstraction. Removing them means you give up some of the portability. On GNU/Linux, with the further constraint of not using static libraries, and only installing libraries in directories searched by both ld and ld.so, you don't lose or miss anything. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From Axel.Thimm at ATrpms.net Thu Oct 12 20:55:41 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 12 Oct 2006 22:55:41 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> Message-ID: <20061012205541.GL9881@neu.nirvana> On Thu, Oct 12, 2006 at 04:47:56PM -0300, Alexandre Oliva wrote: > On Oct 12, 2006, Axel Thimm wrote: > > > Revisting the root of evil. What exactly is wrong with not removing ^^^ > > all *.la files? > > Removing all .la files is fine as long as (i) [...] (ii.a) [...] > (ii.b) [...] Wrong answer, the question was what is wrong with *not* removing them, not what is wrong with doing so. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Oct 12 21:02:46 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 12 Oct 2006 23:02:46 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> <20061012123252.GA3985@neu.nirvana> Message-ID: <20061012210246.GM9881@neu.nirvana> On Thu, Oct 12, 2006 at 05:01:03PM -0300, Alexandre Oliva wrote: > On Oct 12, 2006, Axel Thimm wrote: > > > Seems to really depend on the software generating/using them. Or from > > a different viewpoint: if they really were not required (on Linux), > > then why are libtool authors installing them (on Linux)? We wouldn't > > be having this thread if the simple statement ".la files are not > > required" would indeed hold true. > > They're part of the portable libtool library abstraction. Removing > them means you give up some of the portability. Pretending not to have read the following restricting paragraph: If *.la files were indeed unnecessary/redundant on a platform, let's call it *-redhat-no-static-linux-gnu, then *.la file installation could be skipped. But since we only think we live on such a platform this isn't happening. > On GNU/Linux, with the further constraint of not using static > libraries, and only installing libraries in directories searched by > both ld and ld.so, you don't lose or miss anything. So you would lose on /opt and if some lib needs static linking, and this decision is non-local as you properly explained in some other part of this thread. E.g. we would globally remove degrees of freedom for little gain. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Thu Oct 12 22:21:23 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 13 Oct 2006 00:21:23 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: (Alexandre Oliva's message of "Thu, 12 Oct 2006 16:58:18 -0300") References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> Message-ID: <87hcy9npjw.fsf@kosh.bigo.ensc.de> Alexandre Oliva writes: >>> Revisting the root of evil. What exactly is wrong with not removing >>> all *.la files? > >> - .la files must be shipped in main package, not in -devel > > Only if users of the library rely on libltdl and explicitly refer to > the .la files. no; when some package contains a dynamic loadable module with .la files, this .la file will be used for dependency resolving. When such a dependency is expressed as | dependency_libs='... /usr/lib/libkickermain.la ...' 'libkickermain.la' must be a main package but not in -devel. Because a library can be linked against arbitrary .la modules, a library must either remove .la files completely or ship them in the main package. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From rc040203 at freenet.de Fri Oct 13 04:06:11 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 13 Oct 2006 06:06:11 +0200 Subject: [Fedora-packaging] Refining today's "don't touch system fs" guideline In-Reply-To: <20061012182003.GJ9881@neu.nirvana> References: <20061012182003.GJ9881@neu.nirvana> Message-ID: <1160712372.27470.59.camel@mccallum.corsepiu.local> On Thu, 2006-10-12 at 20:20 +0200, Axel Thimm wrote: > We voted today on > > "Build scripts of packages (%prep, %build, %install and %check) may > only alter files (create, modify, delete) under %{buildroot}, > %{_builddir} and valid temporary locations like /tmp, /var/tmp (or > $TMPDIR or %{_tmppath} as set by the rpmbuild process). > > Further clarification: That should hold true irrespective of the > builder's uid" > > But after thinking about it I'm not quite happy now. Since we go into > details naming what the build scripts are, we should make clear > that they are not equal in what they may or may not do. For example > %{buildroot} should only be modified by %install, not %prep/%build and > %check. Though I agree that the formulation could have been better, I do not agree upon your conclusion. Remember, the intent behind all this was to say: "building an rpm must be free of side-effects on the hosting system.". We had tried to narrow this to file system operations ("alter files") to make this more understandable/handy to "Joe Occasional Builder". I don't think we should try to further narrow this to "what to do when, and when is rpm allowed to do what". IMO, this is a completely different question and beyond the scope of the problem we had wanted to address. > How about extending the rule and having a root/non-root rule, too, > e.g. > > o Package builds should yield the same results irrespective of the > packaging process' uid/gid, for example builds under root and > non-root users should behave the same. > > o Build scripts of packages (%prep, %build, %install and %check) may > only alter files (create, modify, delete) under %{buildroot}, > %{_builddir} and valid temporary locations like /tmp, /var/tmp (or > $TMPDIR or %{_tmppath} as set by the rpmbuild process). > %{buildroot} should only be allowed to be altered in %install > scripts. Technically, in some (rare) occasions, this last sentence is not applicable. E.g. there exist packages, which want/need to be built "multi-staged", with %build containing (often: temporary) installs to %{buildroot}. In some (very rare) occasions, packages even require "building" inside of %buildroot. The constraint you're adding above, would (IMO: unnecessarily) close out these packages from being packaged, or force packagers to resort to move "building" to %install. Ralf From aoliva at redhat.com Fri Oct 13 06:19:41 2006 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 13 Oct 2006 03:19:41 -0300 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061012205541.GL9881@neu.nirvana> (Axel Thimm's message of "Thu, 12 Oct 2006 22:55:41 +0200") References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <20061012205541.GL9881@neu.nirvana> Message-ID: On Oct 12, 2006, Axel Thimm wrote: > On Thu, Oct 12, 2006 at 04:47:56PM -0300, Alexandre Oliva wrote: >> On Oct 12, 2006, Axel Thimm wrote: >> >> > Revisting the root of evil. What exactly is wrong with not removing > ^^^ >> > all *.la files? >> >> Removing all .la files is fine as long as (i) [...] (ii.a) [...] >> (ii.b) [...] > Wrong answer, the question was what is wrong with *not* removing > them, not what is wrong with doing so. :) Oh, I thought you just misunderstood that I was opposing that move, so I thought I'd clarify my position and justify it. There's nothing wrong in keeping .la files, for sure. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Fri Oct 13 06:23:40 2006 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 13 Oct 2006 03:23:40 -0300 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061012210246.GM9881@neu.nirvana> (Axel Thimm's message of "Thu, 12 Oct 2006 23:02:46 +0200") References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> <20061012123252.GA3985@neu.nirvana> <20061012210246.GM9881@neu.nirvana> Message-ID: On Oct 12, 2006, Axel Thimm wrote: > On Thu, Oct 12, 2006 at 05:01:03PM -0300, Alexandre Oliva wrote: >> On GNU/Linux, with the further constraint of not using static >> libraries, and only installing libraries in directories searched by >> both ld and ld.so, you don't lose or miss anything. > So you would lose on /opt and if some lib needs static linking, and > this decision is non-local as you properly explained in some other > part of this thread. E.g. we would globally remove degrees of freedom > for little gain. Right. Keeping the .la files for these rare cases makes a lot of sense to me. I get the impression they never occur in Fedora packages (I mean Core and Extras here, not packages *for* Fedora), so the Fedora policy might very well rule out .la files entirely, even if with a rationale explaining the assumptions behind it and recommendations about when to break this rule in third-party packages. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Fri Oct 13 06:33:16 2006 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 13 Oct 2006 03:33:16 -0300 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <87hcy9npjw.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Fri, 13 Oct 2006 00:21:23 +0200") References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> <87hcy9npjw.fsf@kosh.bigo.ensc.de> Message-ID: On Oct 12, 2006, Enrico Scholz wrote: > Alexandre Oliva writes: >>>> Revisting the root of evil. What exactly is wrong with not removing >>>> all *.la files? >> >>> - .la files must be shipped in main package, not in -devel >> >> Only if users of the library rely on libltdl and explicitly refer to >> the .la files. > no; when some package contains a dynamic loadable module with .la > files, this .la file will be used for dependency resolving. Err... I don't follow. Is this any different from the libltdl case I mentioned above? > When such a dependency is expressed as > | dependency_libs='... /usr/lib/libkickermain.la ...' > 'libkickermain.la' must be a main package but not in -devel. Aah, I think I see what you mean. libfoo.la is a loadable module. libbar.la is a library in a separate package that libfoo.la was linked with. Someone lt_dlopenext()s libfoo, and that fails if libbar.la is not available. Is this what you mean? If you, you're right. I hadn't considered this case. That said, if libbar.la had never had its .la file present at libfoo's build time, libfoo.la couldn't possibly refer to libbar.la. /me wonders if his reasoning breaks if both libfoo and libbar are in the same package. In this case, libfoo.la might refer to libbar.la, indeed. But then, since they're both part of the same build, that's a single spec file, and one might easily arrange to keep libbar.la installed. So indeed there may have to be an exception to the rule for this case. Unless you also remove the libfoo.la, and call it a bug if any package that relies on lt_dlopen("libfoo.la"), instead of lt_dlopenext("libfoo"). Then, you can do away with the .la files even in this case. Right? Or am I still missing anything? > Because a library can be linked against arbitrary .la modules, a library > must either remove .la files completely or ship them in the main package. I don't think this follows. It does hold that they probably ought to be in the same package, or arranged such that the package containing libfoo.la requires that containing libbar.la. But I still fail to see a need for the .la file in the main package, except for lt_dlopen("libfoo.la") -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Fri Oct 13 06:37:23 2006 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 13 Oct 2006 03:37:23 -0300 Subject: [Fedora-packaging] Re: Re: libtool(.la) archive policy proposal In-Reply-To: <452E9E1F.9080509@math.unl.edu> (Rex Dieter's message of "Thu, 12 Oct 2006 14:57:19 -0500") References: <45194CF5.3090509@math.unl.edu> <20061002103212.GK28594@neu.nirvana> <87ven2q5m9.fsf@kosh.bigo.ensc.de> <20061002123703.GA13434@neu.nirvana> <20061005095109.GA16017@neu.nirvana> <452E9E1F.9080509@math.unl.edu> Message-ID: On Oct 12, 2006, Rex Dieter wrote: > Alexandre Oliva wrote: >> I'm not arguing against the "no static lib" policy, and I'm not >> arguing against removing .la files. I'm only arguing against patching >> libtool in ways that have negative consequences for other OSes, >> because this would affect Fedora users that develop on Fedora and >> expect the libtool in it to deliver them portability to other OSes. > Ah, and you must've missed that I qualified the use of ignoring > dependancy_libs only on platforms that *can* (ie, linux) You can only given a very specific set of assumptions, such as no static libs, no non-default lib dirs. There's nothing GNU/Linux-specific about that. The same probably applies to any recent ELF platforms. > and not using it in the case of static linking. (: Point still holds that, if a patch to improve libtool in this regard is available, it shouldn't be in our copy of libtool only, it should be upstream, because it's useful for everybody, and then we don't get the heat if our patch accidentally breaks libtool's portability features for other OSes. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From enrico.scholz at informatik.tu-chemnitz.de Fri Oct 13 07:13:03 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 13 Oct 2006 09:13:03 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: (Alexandre Oliva's message of "Fri, 13 Oct 2006 03:33:16 -0300") References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> <87hcy9npjw.fsf@kosh.bigo.ensc.de> Message-ID: <87hcy8heo0.fsf@kosh.bigo.ensc.de> Alexandre Oliva writes: >>>> - .la files must be shipped in main package, not in -devel > ... > Aah, I think I see what you mean. > > libfoo.la is a loadable module. > > libbar.la is a library in a separate package that libfoo.la was linked > with. > > Someone lt_dlopenext()s libfoo, and that fails if libbar.la is not > available. > > Is this what you mean? yes > /me wonders if his reasoning breaks if both libfoo and libbar are in > the same package. no; 'libbar.la' might be used by a 'libbaz.la' loadable module which is added to the repository a year later by a different maintainer. Therefore, 'libbar.la' must be handled like 'libbar.so.0' and must be in the main package but not in devel. >> Because a library can be linked against arbitrary .la modules, a >> library must either remove .la files completely or ship them in the >> main package. > > I don't think this follows. It does hold that they probably ought to be in > the same package, or arranged such that the package containing libfoo.la > requires that containing libbar.la. Exactly. Because (usually) main packages (e.g. this with 'libfoo.la') must not depend on -devel packages, the required 'libbar.la' must not be in -devel but in a main package. Automatic dependencies (by interpreting 'dependency_libs') will prevent silent breakage but do not change this rule. Checking only the current state of the repository does not help. There exists always the chance that 'libX.la' is used later by some loadable module (which is shipped in a main package). Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Oct 13 07:33:06 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 13 Oct 2006 09:33:06 +0200 Subject: [Fedora-packaging] Re: Refining today's "don't touch system fs" guideline In-Reply-To: <1160712372.27470.59.camel@mccallum.corsepiu.local> References: <20061012182003.GJ9881@neu.nirvana> <1160712372.27470.59.camel@mccallum.corsepiu.local> Message-ID: <20061013073306.GR9881@neu.nirvana> On Fri, Oct 13, 2006 at 06:06:11AM +0200, Ralf Corsepius wrote: > E.g. there exist packages, which want/need to be built "multi-staged", > with %build containing (often: temporary) installs to %{buildroot}. > In some (very rare) occasions, packages even require "building" inside > of %buildroot. These are exactly the broken packages that I want to cater with the proposed changes! If you want to do staged installs during build time you *HAVE* to do so in builddir, not buildroot. > The constraint you're adding above, would (IMO: unnecessarily) close > out these packages from being packaged, or force packagers to resort to > move "building" to %install. Nope, both ways are a sloppy way of packaging. It should be forbidden. Stage your builds in %build/%{builddir}, don't build in %install and don't touch %{buildroot} in %prep/%build. This should be carved in stone. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Fri Oct 13 08:25:36 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 13 Oct 2006 10:25:36 +0200 Subject: [Fedora-packaging] Re: Refining today's "don't touch system fs" guideline In-Reply-To: <20061013073306.GR9881@neu.nirvana> References: <20061012182003.GJ9881@neu.nirvana> <1160712372.27470.59.camel@mccallum.corsepiu.local> <20061013073306.GR9881@neu.nirvana> Message-ID: <1160727937.21016.5.camel@mccallum.corsepiu.local> On Fri, 2006-10-13 at 09:33 +0200, Axel Thimm wrote: > On Fri, Oct 13, 2006 at 06:06:11AM +0200, Ralf Corsepius wrote: > > E.g. there exist packages, which want/need to be built "multi-staged", > > with %build containing (often: temporary) installs to %{buildroot}. > > In some (very rare) occasions, packages even require "building" inside > > of %buildroot. > > These are exactly the broken packages that I want to cater with the > proposed changes! There ain't anything broken with these packages ;) They do not leave files around, nor do they do anything harmful. They simply do not fit into the constraints you are trying to set up. > If you want to do staged installs during build time you *HAVE* to do > so in builddir, not buildroot. Why? rpmbuild and the spec have full access to both directories and can read/write to both. Whether a package does a %build make something make install-something DESTDIR=$RPM_BUILD_ROOT export LD_LIBRARY_PATH=$RPM_BUILD_ROOT%{_lib} make all %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT or a %build make something make install-something DESTDIR=$(PWD)/tmp export LD_LIBRARY_PATH=(PWD)/tmp%{_lib} make all %install rm -rf $(PWD)/tmp rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT doesn't make a real difference. To the contrary, the later is sightly more error-prone. > > The constraint you're adding above, would (IMO: unnecessarily) close > > out these packages from being packaged, or force packagers to resort to > > move "building" to %install. > > Nope, both ways are a sloppy way of packaging. It should be > forbidden. Stage your builds in %build/%{builddir}, don't build in > %install and don't touch %{buildroot} in %prep/%build. This should be > carved in stone. IMO, you are trying to overengineer something. Ralf From Axel.Thimm at ATrpms.net Fri Oct 13 08:33:36 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 13 Oct 2006 10:33:36 +0200 Subject: [Fedora-packaging] Re: Refining today's "don't touch system fs" guideline In-Reply-To: <1160727937.21016.5.camel@mccallum.corsepiu.local> References: <20061012182003.GJ9881@neu.nirvana> <1160712372.27470.59.camel@mccallum.corsepiu.local> <20061013073306.GR9881@neu.nirvana> <1160727937.21016.5.camel@mccallum.corsepiu.local> Message-ID: <20061013083336.GT9881@neu.nirvana> On Fri, Oct 13, 2006 at 10:25:36AM +0200, Ralf Corsepius wrote: > On Fri, 2006-10-13 at 09:33 +0200, Axel Thimm wrote: > > On Fri, Oct 13, 2006 at 06:06:11AM +0200, Ralf Corsepius wrote: > > > E.g. there exist packages, which want/need to be built "multi-staged", > > > with %build containing (often: temporary) installs to %{buildroot}. > > > In some (very rare) occasions, packages even require "building" inside > > > of %buildroot. > > > > These are exactly the broken packages that I want to cater with the > > proposed changes! > There ain't anything broken with these packages ;) You're entitled to think so, yes. But they are broken nonetheless. :) > They do not leave files around, nor do they do anything harmful. They > simply do not fit into the constraints you are trying to set up. Same is true for a package doing everything in %prep. Does that justify it just the same? And these are not constraints *I* am trying to set up, this is how rpm was designed to be used, the constraints are just to make sure it is used that way. > > If you want to do staged installs during build time you *HAVE* to do > > so in builddir, not buildroot. > Why? rpmbuild and the spec have full access to both directories and can > read/write to both. rpmbuild has access to a lot of other directories, the guidelines are there to restrict this access to the sane set of directories. > > Nope, both ways are a sloppy way of packaging. It should be > > forbidden. Stage your builds in %build/%{builddir}, don't build in > > %install and don't touch %{buildroot} in %prep/%build. This should be > > carved in stone. > IMO, you are trying to overengineer something. Well, in your opinion. That's the nice thing about a democratic institution, everybody may have an opinion and need not agree with the other. Still if enough opinions are gathered we'll have a functional guideline. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Fri Oct 13 08:56:39 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 13 Oct 2006 10:56:39 +0200 Subject: [Fedora-packaging] Re: Refining today's "don't touch system fs" guideline In-Reply-To: <20061013083336.GT9881@neu.nirvana> References: <20061012182003.GJ9881@neu.nirvana> <1160712372.27470.59.camel@mccallum.corsepiu.local> <20061013073306.GR9881@neu.nirvana> <1160727937.21016.5.camel@mccallum.corsepiu.local> <20061013083336.GT9881@neu.nirvana> Message-ID: <1160729799.21016.12.camel@mccallum.corsepiu.local> On Fri, 2006-10-13 at 10:33 +0200, Axel Thimm wrote: > On Fri, Oct 13, 2006 at 10:25:36AM +0200, Ralf Corsepius wrote: > > On Fri, 2006-10-13 at 09:33 +0200, Axel Thimm wrote: > > > On Fri, Oct 13, 2006 at 06:06:11AM +0200, Ralf Corsepius wrote: > > > > E.g. there exist packages, which want/need to be built "multi-staged", > > > > with %build containing (often: temporary) installs to %{buildroot}. > > > > In some (very rare) occasions, packages even require "building" inside > > > > of %buildroot. > > > > > > These are exactly the broken packages that I want to cater with the > > > proposed changes! > > There ain't anything broken with these packages ;) Then I can't avoid replying a bit clearer: * The issue you are trying to address is not related at all to our original problem ("free of side-effects") * Your proposal does not solve an actual technical problem, to the contrary, it artificially introduces new ones. Ralf From Axel.Thimm at ATrpms.net Fri Oct 13 09:14:47 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 13 Oct 2006 11:14:47 +0200 Subject: [Fedora-packaging] Re: Refining today's "don't touch system fs" guideline In-Reply-To: <1160729799.21016.12.camel@mccallum.corsepiu.local> References: <20061012182003.GJ9881@neu.nirvana> <1160712372.27470.59.camel@mccallum.corsepiu.local> <20061013073306.GR9881@neu.nirvana> <1160727937.21016.5.camel@mccallum.corsepiu.local> <20061013083336.GT9881@neu.nirvana> <1160729799.21016.12.camel@mccallum.corsepiu.local> Message-ID: <20061013091447.GV9881@neu.nirvana> On Fri, Oct 13, 2006 at 10:56:39AM +0200, Ralf Corsepius wrote: > On Fri, 2006-10-13 at 10:33 +0200, Axel Thimm wrote: > > On Fri, Oct 13, 2006 at 10:25:36AM +0200, Ralf Corsepius wrote: > > > On Fri, 2006-10-13 at 09:33 +0200, Axel Thimm wrote: > > > > On Fri, Oct 13, 2006 at 06:06:11AM +0200, Ralf Corsepius wrote: > > > > > E.g. there exist packages, which want/need to be built "multi-staged", > > > > > with %build containing (often: temporary) installs to %{buildroot}. > > > > > In some (very rare) occasions, packages even require "building" inside > > > > > of %buildroot. > > > > > > > > These are exactly the broken packages that I want to cater with the > > > > proposed changes! > > > There ain't anything broken with these packages ;) > > Then I can't avoid replying a bit clearer: > > * The issue you are trying to address is not related at all to our > original problem ("free of side-effects") So? Is that the only problem we are interested in solving in this group? What kind of childish argument is that? Let's become constructive again. > * Your proposal does not solve an actual technical problem, to the > contrary, it artificially introduces new ones. As said, you're entitled to your opinion. As well as others like myself are entitled to the opinion that packages writing into %{buildroot} at any other stage that %install are broken. If you continue to stiffly argue on technical grounds we'll end up doing all in %prep. There is no technical reason not to do everything there, right? No side-effects, the binary results are the same and so on. You'll probably start removing comments next, since they is no technically needed. Greetings from homo faber. Just going into hyperboles to make the point since IMO it is a very trivial point that shouldn't even need discussion. There are reasons building and installing software have been seperated in all build mechanisms, make, rpm, ant, cmake, etc, and arguing that it's technically not neccessary is nonsense. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Fri Oct 13 08:53:08 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 Oct 2006 10:53:08 +0200 (CEST) Subject: [Fedora-packaging] Re: Refining today's "don't touch system fs" guideline In-Reply-To: <20061013083336.GT9881@neu.nirvana> References: <20061012182003.GJ9881@neu.nirvana> <1160712372.27470.59.camel@mccallum.corsepiu.local> <20061013073306.GR9881@neu.nirvana> <1160727937.21016.5.camel@mccallum.corsepiu.local> <20061013083336.GT9881@neu.nirvana> Message-ID: <55365.192.54.193.51.1160729588.squirrel@rousalka.dyndns.org> Le Ven 13 octobre 2006 10:33, Axel Thimm a ?crit : > On Fri, Oct 13, 2006 at 10:25:36AM +0200, Ralf Corsepius wrote: >> They do not leave files around, nor do they do anything harmful. They >> simply do not fit into the constraints you are trying to set up. > > Same is true for a package doing everything in %prep. Does that > justify it just the same? And these are not constraints *I* am trying > to set up, this is how rpm was designed to be used, the constraints > are just to make sure it is used that way. While some packagers may manipulate directories outside of the intended rpm section safely, most people who do so just do not understand the risks and usually end up with broken packages. (installing stuff before a script changes it, installing a mix of production and build files and so on). Also a spec which does not respect common style is more difficult to review or salvage later if the maintainer went awol. I'm all for Axel's proposal, except I'd also allow other constructs provided the corresponding commented template is posted in the wiki and approved by the board. -- Nicolas Mailhot From bugs.michael at gmx.net Fri Oct 13 12:11:08 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 13 Oct 2006 14:11:08 +0200 Subject: [Fedora-packaging] Re: Refining today's "don't touch system fs" guideline In-Reply-To: <1160727937.21016.5.camel@mccallum.corsepiu.local> References: <20061012182003.GJ9881@neu.nirvana> <1160712372.27470.59.camel@mccallum.corsepiu.local> <20061013073306.GR9881@neu.nirvana> <1160727937.21016.5.camel@mccallum.corsepiu.local> Message-ID: <20061013141108.73243d4a.bugs.michael@gmx.net> On Fri, 13 Oct 2006 10:25:36 +0200, Ralf Corsepius wrote: > Whether a package does a > > %build > make something > make install-something DESTDIR=$RPM_BUILD_ROOT > export LD_LIBRARY_PATH=$RPM_BUILD_ROOT%{_lib} > make all > %install > rm -rf $RPM_BUILD_ROOT > make install DESTDIR=$RPM_BUILD_ROOT > > or a > > %build > make something > make install-something DESTDIR=$(PWD)/tmp > export LD_LIBRARY_PATH=(PWD)/tmp%{_lib} > make all > %install > rm -rf $(PWD)/tmp > rm -rf $RPM_BUILD_ROOT > make install DESTDIR=$RPM_BUILD_ROOT > > doesn't make a real difference. It does. ;) The former installs into $RPM_BUILD_ROOT without doing "rm -rf $RPM_BUILD_ROOT" first. It would need to do this at the beginning of %build (!). Rather than $RPM_BUILD_DIR I would also choose $RPM_BUILD_ROOT as a temporary working directory, because it is emptied at the beginning of %install again anyway and is specific to the current package. $RPM_BUILD_DIR or %_builddir is not. It is %{_topdir}/BUILD by default and hence is located above the extracted source tarballs. Usually, you would prefer $(pwd) which expands to $RPM_BUILD_ROOT or below. Or append a unique string to %_builddir before working in there. We want rpmbuild --short-circuit builds to work for both %build and %install, regardless of how that is achieved. If it is necessary to create tmp files in %check, don't impose too many restrictions on the packagers. From rc040203 at freenet.de Fri Oct 13 12:27:51 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 13 Oct 2006 14:27:51 +0200 Subject: [Fedora-packaging] Re: Refining today's "don't touch system fs" guideline In-Reply-To: <20061013141108.73243d4a.bugs.michael@gmx.net> References: <20061012182003.GJ9881@neu.nirvana> <1160712372.27470.59.camel@mccallum.corsepiu.local> <20061013073306.GR9881@neu.nirvana> <1160727937.21016.5.camel@mccallum.corsepiu.local> <20061013141108.73243d4a.bugs.michael@gmx.net> Message-ID: <1160742471.21016.30.camel@mccallum.corsepiu.local> On Fri, 2006-10-13 at 14:11 +0200, Michael Schwendt wrote: > On Fri, 13 Oct 2006 10:25:36 +0200, Ralf Corsepius wrote: > > > Whether a package does a > > > > %build > > make something > > make install-something DESTDIR=$RPM_BUILD_ROOT > > export LD_LIBRARY_PATH=$RPM_BUILD_ROOT%{_lib} > > make all > > %install > > rm -rf $RPM_BUILD_ROOT > > make install DESTDIR=$RPM_BUILD_ROOT > > > > or a > > > > %build > > make something > > make install-something DESTDIR=$(PWD)/tmp > > export LD_LIBRARY_PATH=(PWD)/tmp%{_lib} > > make all > > %install > > rm -rf $(PWD)/tmp > > rm -rf $RPM_BUILD_ROOT > > make install DESTDIR=$RPM_BUILD_ROOT > > > > doesn't make a real difference. > > It does. ;) > > The former installs into $RPM_BUILD_ROOT without doing "rm -rf > $RPM_BUILD_ROOT" first. It would need to do this at the beginning of > %build (!). hastly off-head scribbled pseudo-code", you know? The real world case in FE, I am facing this issue with, does have an rm -rf $RPM_BUILD_ROOT in %build ;) Ralf From rdieter at math.unl.edu Fri Oct 13 13:09:57 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 13 Oct 2006 08:09:57 -0500 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <87hcy8heo0.fsf@kosh.bigo.ensc.de> References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> <87hcy9npjw.fsf@kosh.bigo.ensc.de> <87hcy8heo0.fsf@kosh.bigo.ensc.de> Message-ID: <452F9025.8050603@math.unl.edu> Enrico Scholz wrote: > Alexandre Oliva writes: > >>>>> - .la files must be shipped in main package, not in -devel >> ... >> Aah, I think I see what you mean. >> >> libfoo.la is a loadable module. >> >> libbar.la is a library in a separate package that libfoo.la was linked >> with. >> >> Someone lt_dlopenext()s libfoo, and that fails if libbar.la is not >> available. >> >> Is this what you mean? > > yes In my experience, this only fails if libfoo has undefined symbols. -- Rex From Axel.Thimm at ATrpms.net Fri Oct 13 13:58:09 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 13 Oct 2006 15:58:09 +0200 Subject: [Fedora-packaging] Re: Refining today's "don't touch system fs" guideline In-Reply-To: <1160742471.21016.30.camel@mccallum.corsepiu.local> References: <20061012182003.GJ9881@neu.nirvana> <1160712372.27470.59.camel@mccallum.corsepiu.local> <20061013073306.GR9881@neu.nirvana> <1160727937.21016.5.camel@mccallum.corsepiu.local> <20061013141108.73243d4a.bugs.michael@gmx.net> <1160742471.21016.30.camel@mccallum.corsepiu.local> Message-ID: <20061013135809.GB13642@neu.nirvana> On Fri, Oct 13, 2006 at 02:27:51PM +0200, Ralf Corsepius wrote: > On Fri, 2006-10-13 at 14:11 +0200, Michael Schwendt wrote: > > > doesn't make a real difference. > > > > It does. ;) > > > > The former installs into $RPM_BUILD_ROOT without doing "rm -rf > > $RPM_BUILD_ROOT" first. It would need to do this at the beginning of > > %build (!). > hastly off-head scribbled pseudo-code", you know? > > The real world case in FE, I am facing this issue with, does have an > rm -rf $RPM_BUILD_ROOT in %build ;) And you consider that proper? This package should not be allowed to pass the review! *Shudder* -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Fri Oct 13 13:58:59 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 13 Oct 2006 15:58:59 +0200 Subject: [Fedora-packaging] Re: Refining today's "don't touch system fs" guideline In-Reply-To: <20061013091447.GV9881@neu.nirvana> References: <20061012182003.GJ9881@neu.nirvana> <1160712372.27470.59.camel@mccallum.corsepiu.local> <20061013073306.GR9881@neu.nirvana> <1160727937.21016.5.camel@mccallum.corsepiu.local> <20061013083336.GT9881@neu.nirvana> <1160729799.21016.12.camel@mccallum.corsepiu.local> <20061013091447.GV9881@neu.nirvana> Message-ID: <1160747940.21016.45.camel@mccallum.corsepiu.local> On Fri, 2006-10-13 at 11:14 +0200, Axel Thimm wrote: > On Fri, Oct 13, 2006 at 10:56:39AM +0200, Ralf Corsepius wrote: > > On Fri, 2006-10-13 at 10:33 +0200, Axel Thimm wrote: > > > On Fri, Oct 13, 2006 at 10:25:36AM +0200, Ralf Corsepius wrote: > > > > On Fri, 2006-10-13 at 09:33 +0200, Axel Thimm wrote: > > > > > On Fri, Oct 13, 2006 at 06:06:11AM +0200, Ralf Corsepius wrote: > > > > > > E.g. there exist packages, which want/need to be built "multi-staged", > > > > > > with %build containing (often: temporary) installs to %{buildroot}. > > > > > > In some (very rare) occasions, packages even require "building" inside > > > > > > of %buildroot. > > > > > > > > > > These are exactly the broken packages that I want to cater with the > > > > > proposed changes! > > > > There ain't anything broken with these packages ;) > > > > Then I can't avoid replying a bit clearer: > > > > * The issue you are trying to address is not related at all to our > > original problem ("free of side-effects") > > So? Is that the only problem we are interested in solving in this > group? What kind of childish argument is that? Let's become > constructive again. Pardon, in which world are you living? Being opposed to a proposal is considered to be destructive? I am saying your extension to the proposal doesn't solve any problem, it introduces NEW problems, that's why I am opposed to it. > > * Your proposal does not solve an actual technical problem, to the > > contrary, it artificially introduces new ones. > > As said, you're entitled to your opinion. As well as others like > myself are entitled to the opinion that packages writing into > %{buildroot} at any other stage that %install are broken. > > If you continue to stiffly argue on technical grounds we'll end up > doing all in %prep. There is no technical reason not to do everything > there, right? No side-effects, the binary results are the same and so > on. You'll probably start removing comments next, since they is no > technically needed. Right! The %prep/%build/%install separation is an artificial separation based on the assumption that all packages have a build model supporting this 3-staged building model. Reality is: Most GNU packages do, but this doesn't apply in general. Not all packages have a "natural separation" fitting into this model. There are packages for which %prep/%build/%install can be collapsed into one step (e.g. by simply untarring into %RPM_BUILD_ROOT[1], instead of copying them around through the different stage), there are others for which %build consists of several stages with installation of subpackages into temporary locations. Ralf [1] Very handy and effective for packages consisting of several 10MBs. From rc040203 at freenet.de Fri Oct 13 14:02:30 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 13 Oct 2006 16:02:30 +0200 Subject: [Fedora-packaging] Re: Refining today's "don't touch system fs" guideline In-Reply-To: <20061013135809.GB13642@neu.nirvana> References: <20061012182003.GJ9881@neu.nirvana> <1160712372.27470.59.camel@mccallum.corsepiu.local> <20061013073306.GR9881@neu.nirvana> <1160727937.21016.5.camel@mccallum.corsepiu.local> <20061013141108.73243d4a.bugs.michael@gmx.net> <1160742471.21016.30.camel@mccallum.corsepiu.local> <20061013135809.GB13642@neu.nirvana> Message-ID: <1160748150.21016.47.camel@mccallum.corsepiu.local> On Fri, 2006-10-13 at 15:58 +0200, Axel Thimm wrote: > On Fri, Oct 13, 2006 at 02:27:51PM +0200, Ralf Corsepius wrote: > > On Fri, 2006-10-13 at 14:11 +0200, Michael Schwendt wrote: > > > > doesn't make a real difference. > > > > > > It does. ;) > > > > > > The former installs into $RPM_BUILD_ROOT without doing "rm -rf > > > $RPM_BUILD_ROOT" first. It would need to do this at the beginning of > > > %build (!). > > hastly off-head scribbled pseudo-code", you know? > > > > The real world case in FE, I am facing this issue with, does have an > > rm -rf $RPM_BUILD_ROOT in %build ;) > > And you consider that proper? This package should not be allowed to > pass the review! Why? What is the problem? Ralf From aoliva at redhat.com Fri Oct 13 18:04:33 2006 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 13 Oct 2006 15:04:33 -0300 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <87hcy8heo0.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Fri, 13 Oct 2006 09:13:03 +0200") References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> <87hcy9npjw.fsf@kosh.bigo.ensc.de> <87hcy8heo0.fsf@kosh.bigo.ensc.de> Message-ID: On Oct 13, 2006, Enrico Scholz wrote: > Alexandre Oliva writes: >> /me wonders if his reasoning breaks if both libfoo and libbar are in >> the same package. > no; 'libbar.la' might be used by a 'libbaz.la' loadable module which is > added to the repository a year later by a different maintainer. Not if libbar.la was not installed. > Exactly. Because (usually) main packages (e.g. this with 'libfoo.la') > must not depend on -devel packages, the required 'libbar.la' must not be > in -devel but in a main package. But if you add the .la to the main package, that brings in references to the .so and .a files, if present, so you'd then have to add the undesired dependency. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From enrico.scholz at informatik.tu-chemnitz.de Fri Oct 13 18:52:41 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 13 Oct 2006 20:52:41 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: (Alexandre Oliva's message of "Fri, 13 Oct 2006 15:04:33 -0300") References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> <87hcy9npjw.fsf@kosh.bigo.ensc.de> <87hcy8heo0.fsf@kosh.bigo.ensc.de> Message-ID: <87odsg3v5y.fsf@kosh.bigo.ensc.de> aoliva at redhat.com (Alexandre Oliva) writes: >> no; 'libbar.la' might be used by a 'libbaz.la' loadable module which >> is added to the repository a year later by a different maintainer. > > Not if libbar.la was not installed. So you suggest to avoid packaging of .la files? Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From aoliva at redhat.com Sat Oct 14 06:53:01 2006 From: aoliva at redhat.com (Alexandre Oliva) Date: Sat, 14 Oct 2006 03:53:01 -0300 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <87odsg3v5y.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Fri, 13 Oct 2006 20:52:41 +0200") References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> <87hcy9npjw.fsf@kosh.bigo.ensc.de> <87hcy8heo0.fsf@kosh.bigo.ensc.de> <87odsg3v5y.fsf@kosh.bigo.ensc.de> Message-ID: On Oct 13, 2006, Enrico Scholz wrote: > aoliva at redhat.com (Alexandre Oliva) writes: >>> no; 'libbar.la' might be used by a 'libbaz.la' loadable module which >>> is added to the repository a year later by a different maintainer. >> >> Not if libbar.la was not installed. > So you suggest to avoid packaging of .la files? I understand that was the proposal on the table, and I don't see reasons against that given the constraints exposed so far. It's not my suggestion, and I wouldn't say I actively promote it, but I don't mind it, and I did mind arguments that were brought up against it, so I voiced my opinion against the arguments ;-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From Axel.Thimm at ATrpms.net Sat Oct 14 10:04:26 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 14 Oct 2006 12:04:26 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> <87hcy9npjw.fsf@kosh.bigo.ensc.de> <87hcy8heo0.fsf@kosh.bigo.ensc.de> <87odsg3v5y.fsf@kosh.bigo.ensc.de> Message-ID: <20061014100426.GA23120@neu.nirvana> On Sat, Oct 14, 2006 at 03:53:01AM -0300, Alexandre Oliva wrote: > On Oct 13, 2006, Enrico Scholz wrote: > > > aoliva at redhat.com (Alexandre Oliva) writes: > >>> no; 'libbar.la' might be used by a 'libbaz.la' loadable module which > >>> is added to the repository a year later by a different maintainer. > >> > >> Not if libbar.la was not installed. > > > So you suggest to avoid packaging of .la files? > > I understand that was the proposal on the table, and I don't see > reasons against that given the constraints exposed so far. It's not > my suggestion, and I wouldn't say I actively promote it, but I don't > mind it, and I did mind arguments that were brought up against it, so > I voiced my opinion against the arguments ;-) How about fixing the issues we *think* we have with *.la files upstream, so that we don't even have to undo what libtool does? Alexandre seems to have the best insight of libtool and our issues with *.la around here, so he could setup the specs of what we'd like to see improved in libtool and open up a dialogue with the current libtool maintainers. The outcome for me is that the "drawback" of keeping *.la files unconditionally is that some *.devel files get a couple too many BRs, and a very few (like kdelibs) get a dozen too many. That doesn't break any minimal buildroots, it simply adds a few seconds during build time (note that the non devel parts of the dependent libs are installed during the builds anyway). Compared to that we have random breakage in some packages eating up developer and user time and endless discussions on lists. So let the build systems spend a couple of CPU seconds instead. ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Oct 14 11:05:25 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 14 Oct 2006 13:05:25 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061014100426.GA23120@neu.nirvana> (Axel Thimm's message of "Sat, 14 Oct 2006 12:04:26 +0200") References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> <87hcy9npjw.fsf@kosh.bigo.ensc.de> <87hcy8heo0.fsf@kosh.bigo.ensc.de> <87odsg3v5y.fsf@kosh.bigo.ensc.de> <20061014100426.GA23120@neu.nirvana> Message-ID: <87bqof5f9m.fsf@kosh.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: > The outcome for me is that the "drawback" of keeping *.la files > unconditionally is that some *.devel files get a couple too many > BRs, and a very few (like kdelibs) get a dozen too many. ... and that you have to put .la files into main packages (which is adding untracked dependencies) and you slow down module loading... Enrico From Axel.Thimm at ATrpms.net Sat Oct 14 11:19:28 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 14 Oct 2006 13:19:28 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <87bqof5f9m.fsf@kosh.bigo.ensc.de> References: <87bqoh2433.fsf@fc5.bigo.ensc.de> <87hcy9npjw.fsf@kosh.bigo.ensc.de> <87hcy8heo0.fsf@kosh.bigo.ensc.de> <87odsg3v5y.fsf@kosh.bigo.ensc.de> <20061014100426.GA23120@neu.nirvana> <87bqof5f9m.fsf@kosh.bigo.ensc.de> Message-ID: <20061014111928.GB23120@neu.nirvana> On Sat, Oct 14, 2006 at 01:05:25PM +0200, Enrico Scholz wrote: > ... and that you have to put .la files into main packages (which is > adding untracked dependencies) and you slow down module loading... You are exaggerating. How did RHL, RHEL and FC survive so far? o Can you show a list of bugs related to main packages missing *.la files to compare the pains? And doesn't this contradict your statement "*.la files are unneccessary"? So your complete statement is "*.la files are unneccessary, but they are required in the main package"? Simple logic implies that then the main package is unneccessary, too. ;) o How many milliseconds are we losing for module loading through *.la files? How much faster in percentage do the modules load w/o *.la files? Are we really going to compare a few hundred ms to several seconds, especially in light of where dynamic module loading is really used? Are we then going to rebuild Fedora based on dietlibc to gain a couple seconds, too? No, I think the pain and *.la-micro-surgery needs to end. Get *.la files back and address any remaining issues with libtool upstream. We can live with a couple more BR in *-devel until this gets resolved. We did so for several years. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Sat Oct 14 11:20:19 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 14 Oct 2006 14:20:19 +0300 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <87bqof5f9m.fsf@kosh.bigo.ensc.de> References: <45194CF5.3090509@math.unl.edu> <20061012084726.GA7721@neu.nirvana> <87bqoh2433.fsf@fc5.bigo.ensc.de> <87hcy9npjw.fsf@kosh.bigo.ensc.de> <87hcy8heo0.fsf@kosh.bigo.ensc.de> <87odsg3v5y.fsf@kosh.bigo.ensc.de> <20061014100426.GA23120@neu.nirvana> <87bqof5f9m.fsf@kosh.bigo.ensc.de> Message-ID: <1160824819.4207.10.camel@viper.local> On Sat, 2006-10-14 at 13:05 +0200, Enrico Scholz wrote: > Axel.Thimm at ATrpms.net (Axel Thimm) writes: > > > The outcome for me is that the "drawback" of keeping *.la files > > unconditionally is that some *.devel files get a couple too many > > BRs, -devel packages get bloated Requires, not BuildRequires. Or if they're not there, other packages in a lot of cases need bloated BuildRequires in order to only accomplish also unnecessarily bloating the resulting binaries/libs, see below. > > and a very few (like kdelibs) get a dozen too many. > > ... and that you have to put .la files into main packages (which is > adding untracked dependencies) and you slow down module loading... ...and in many cases, end up unnecessarily bloating linkage of binaries/libs in main packages too, making things like soname changes even more painful than they already are... From Axel.Thimm at ATrpms.net Sat Oct 14 11:29:28 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 14 Oct 2006 13:29:28 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <1160824819.4207.10.camel@viper.local> References: <87hcy9npjw.fsf@kosh.bigo.ensc.de> <87hcy8heo0.fsf@kosh.bigo.ensc.de> <87odsg3v5y.fsf@kosh.bigo.ensc.de> <20061014100426.GA23120@neu.nirvana> <87bqof5f9m.fsf@kosh.bigo.ensc.de> <1160824819.4207.10.camel@viper.local> Message-ID: <20061014112928.GC23120@neu.nirvana> On Sat, Oct 14, 2006 at 02:20:19PM +0300, Ville Skytt? wrote: > On Sat, 2006-10-14 at 13:05 +0200, Enrico Scholz wrote: > > Axel.Thimm at ATrpms.net (Axel Thimm) writes: > > > > > The outcome for me is that the "drawback" of keeping *.la files > > > unconditionally is that some *.devel files get a couple too many > > > BRs, > > -devel packages get bloated Requires, not BuildRequires. Yes, thanks, that's correct and what I meant. > ...and in many cases, end up unnecessarily bloating linkage of > binaries/libs in main packages too, making things like soname changes > even more painful than they already are... I think the thread made clear that this is not the case. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Sat Oct 14 11:45:31 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 14 Oct 2006 14:45:31 +0300 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061014112928.GC23120@neu.nirvana> References: <87hcy9npjw.fsf@kosh.bigo.ensc.de> <87hcy8heo0.fsf@kosh.bigo.ensc.de> <87odsg3v5y.fsf@kosh.bigo.ensc.de> <20061014100426.GA23120@neu.nirvana> <87bqof5f9m.fsf@kosh.bigo.ensc.de> <1160824819.4207.10.camel@viper.local> <20061014112928.GC23120@neu.nirvana> Message-ID: <1160826331.4207.16.camel@viper.local> On Sat, 2006-10-14 at 13:29 +0200, Axel Thimm wrote: > On Sat, Oct 14, 2006 at 02:20:19PM +0300, Ville Skytt? wrote: > > > ...and in many cases, end up unnecessarily bloating linkage of > > binaries/libs in main packages too, making things like soname changes > > even more painful than they already are... > > I think the thread made clear that this is not the case. If it did, I missed it. Got any pointers to posts that support the above conclusion to share? From enrico.scholz at informatik.tu-chemnitz.de Sat Oct 14 11:47:08 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 14 Oct 2006 13:47:08 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061014111928.GB23120@neu.nirvana> (Axel Thimm's message of "Sat, 14 Oct 2006 13:19:28 +0200") References: <87bqoh2433.fsf@fc5.bigo.ensc.de> <87hcy9npjw.fsf@kosh.bigo.ensc.de> <87hcy8heo0.fsf@kosh.bigo.ensc.de> <87odsg3v5y.fsf@kosh.bigo.ensc.de> <20061014100426.GA23120@neu.nirvana> <87bqof5f9m.fsf@kosh.bigo.ensc.de> <20061014111928.GB23120@neu.nirvana> Message-ID: <877iz35dc3.fsf@kosh.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: >> ... and that you have to put .la files into main packages (which is >> adding untracked dependencies) and you slow down module loading... > > o Can you show a list of bugs related to main packages missing *.la > files to compare the pains? And doesn't this contradict your > statement "*.la files are unneccessary"? AGAIN (and citing [1]): Sentence was written under the assumption that all .la files will be shipped. When .la will not be shipped they do not need to be in main packages (nor in -devel ones) because they are not shipped. > o How many milliseconds are we losing for module loading through *.la > files? How much faster in percentage do the modules load w/o *.la > files? Dunno. But we can save these few milliseconds without any costs by removing the .la files. Enrico Footnotes: [1] https://www.redhat.com/archives/fedora-packaging/2006-October/msg00062.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Oct 14 11:55:36 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 14 Oct 2006 13:55:36 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <877iz35dc3.fsf@kosh.bigo.ensc.de> References: <87hcy9npjw.fsf@kosh.bigo.ensc.de> <87hcy8heo0.fsf@kosh.bigo.ensc.de> <87odsg3v5y.fsf@kosh.bigo.ensc.de> <20061014100426.GA23120@neu.nirvana> <87bqof5f9m.fsf@kosh.bigo.ensc.de> <20061014111928.GB23120@neu.nirvana> <877iz35dc3.fsf@kosh.bigo.ensc.de> Message-ID: <20061014115536.GD23120@neu.nirvana> On Sat, Oct 14, 2006 at 01:47:08PM +0200, Enrico Scholz wrote: > Axel.Thimm at ATrpms.net (Axel Thimm) writes: > > >> ... and that you have to put .la files into main packages (which is > >> adding untracked dependencies) and you slow down module loading... > > > > o Can you show a list of bugs related to main packages missing *.la > > files to compare the pains? And doesn't this contradict your > > statement "*.la files are unneccessary"? > > AGAIN (and citing [1]): Sentence was written under the assumption that > all .la files will be shipped. > > When .la will not be shipped they do not need to be in main packages > (nor in -devel ones) because they are not shipped. The standard procedure until now is to have *.la files in *-devel files and only have *.la files for dlopen in the main packages. That's what is being discussed. > > o How many milliseconds are we losing for module loading through *.la > > files? How much faster in percentage do the modules load w/o *.la > > files? > Dunno. But we can save these few milliseconds without any costs by > removing the .la files. Gosh, asserting on every mail that there are no issues with removing *.la files won't make that turn to truth. In fact if you present your arguments as biased I (and others) can't judge on the validity of any of your argumentation. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Oct 14 11:58:59 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 14 Oct 2006 13:58:59 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <1160826331.4207.16.camel@viper.local> References: <87hcy8heo0.fsf@kosh.bigo.ensc.de> <87odsg3v5y.fsf@kosh.bigo.ensc.de> <20061014100426.GA23120@neu.nirvana> <87bqof5f9m.fsf@kosh.bigo.ensc.de> <1160824819.4207.10.camel@viper.local> <20061014112928.GC23120@neu.nirvana> <1160826331.4207.16.camel@viper.local> Message-ID: <20061014115859.GE23120@neu.nirvana> On Sat, Oct 14, 2006 at 02:45:31PM +0300, Ville Skytt? wrote: > On Sat, 2006-10-14 at 13:29 +0200, Axel Thimm wrote: > > On Sat, Oct 14, 2006 at 02:20:19PM +0300, Ville Skytt? wrote: > > > > > ...and in many cases, end up unnecessarily bloating linkage of > > > binaries/libs in main packages too, making things like soname changes > > > even more painful than they already are... > > > > I think the thread made clear that this is not the case. > > If it did, I missed it. Got any pointers to posts that support the > above conclusion to share? How about this thread? No, honestly check the discussion especially Alexandre's posts who goes into the details of both libtool and non-libtool library internals. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Oct 14 12:05:17 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 14 Oct 2006 14:05:17 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061014115536.GD23120@neu.nirvana> (Axel Thimm's message of "Sat, 14 Oct 2006 13:55:36 +0200") References: <87hcy9npjw.fsf@kosh.bigo.ensc.de> <87hcy8heo0.fsf@kosh.bigo.ensc.de> <87odsg3v5y.fsf@kosh.bigo.ensc.de> <20061014100426.GA23120@neu.nirvana> <87bqof5f9m.fsf@kosh.bigo.ensc.de> <20061014111928.GB23120@neu.nirvana> <877iz35dc3.fsf@kosh.bigo.ensc.de> <20061014115536.GD23120@neu.nirvana> Message-ID: <873b9r5chu.fsf@kosh.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: >> >> ... and that you have to put .la files into main packages (which is >> >> adding untracked dependencies) and you slow down module loading... > ... > The standard procedure until now is to have *.la files in *-devel > files no; standard procedure until now is to remove .la files. When we allow .la files when they are not needed, then they must be in main packages, not in -devel. This thread shows why. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Oct 14 12:09:57 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 14 Oct 2006 14:09:57 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <873b9r5chu.fsf@kosh.bigo.ensc.de> References: <87hcy8heo0.fsf@kosh.bigo.ensc.de> <87odsg3v5y.fsf@kosh.bigo.ensc.de> <20061014100426.GA23120@neu.nirvana> <87bqof5f9m.fsf@kosh.bigo.ensc.de> <20061014111928.GB23120@neu.nirvana> <877iz35dc3.fsf@kosh.bigo.ensc.de> <20061014115536.GD23120@neu.nirvana> <873b9r5chu.fsf@kosh.bigo.ensc.de> Message-ID: <20061014120957.GF23120@neu.nirvana> On Sat, Oct 14, 2006 at 02:05:17PM +0200, Enrico Scholz wrote: > then they must be in main packages, not in -devel. This thread shows > why. Makes one wonder how RHL/RHEL/FC worked w/o doing so. Or given that they did work one wonders what makes you say that. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Sat Oct 14 12:20:45 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 14 Oct 2006 15:20:45 +0300 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061014115859.GE23120@neu.nirvana> References: <87hcy8heo0.fsf@kosh.bigo.ensc.de> <87odsg3v5y.fsf@kosh.bigo.ensc.de> <20061014100426.GA23120@neu.nirvana> <87bqof5f9m.fsf@kosh.bigo.ensc.de> <1160824819.4207.10.camel@viper.local> <20061014112928.GC23120@neu.nirvana> <1160826331.4207.16.camel@viper.local> <20061014115859.GE23120@neu.nirvana> Message-ID: <1160828445.4207.35.camel@viper.local> On Sat, 2006-10-14 at 13:58 +0200, Axel Thimm wrote: > On Sat, Oct 14, 2006 at 02:45:31PM +0300, Ville Skytt? wrote: > > On Sat, 2006-10-14 at 13:29 +0200, Axel Thimm wrote: > > > On Sat, Oct 14, 2006 at 02:20:19PM +0300, Ville Skytt? wrote: > > > > > > > ...and in many cases, end up unnecessarily bloating linkage of > > > > binaries/libs in main packages too, making things like soname changes > > > > even more painful than they already are... > > > > > > I think the thread made clear that this is not the case. > > > > If it did, I missed it. Got any pointers to posts that support the > > above conclusion to share? > > How about this thread? No, honestly check the discussion especially > Alexandre's posts who goes into the details of both libtool and > non-libtool library internals. Sorry, that's too much for me to dig into again now, so I'll exit the thread with an observation: compare the output of these (attached also for convenience): rpm -qRp http://download.fedora.redhat.com/pub/fedora/linux/extras/4/i386/apt-0.5.15lorg3.2-7.fc4.i386.rpm rpm -qRp http://download.fedora.redhat.com/pub/fedora/linux/extras/5/i386/apt-0.5.15lorg3.2-7.fc5.i386.rpm What happened between FC4 and FC5 was that *.la were dropped from rpm-devel and some other related -devel packages. No changes to the apt specfile, and the result is that apt in FE4 has 15+ more AFAICT useless library dependencies than the same package in FE5, with no change in apt functionality. In addition to being unneeded, they're actually harmful: if any of those libs would get a soname bump, it'd break apt's dependencies and require a rebuild for no gain whatsoever. (Note that this is just an example, don't pay attention to the probabilities of soname bumps in this particular case this particular time.) Another thing is that the apt specfile in FE devel still has a lot of BR's that were apparently sometime required because they were in rpm-devel's *.la but were not pulled in by rpm-devel. As the above example shows, they were there only in order to cause unneeded bloat to the resulting apt binaries, and now that they're most likely no longer needed, they remain as bloat in the apt specfile. Maybe removing *.la from rpm-devel and friends would have not been the only possible solution to the apt runtime package dependency bloat problem, dunno. It seems to have worked very well, though. -------------- next part -------------- A non-text attachment was scrubbed... Name: aptdeps.diff Type: text/x-patch Size: 1293 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Oct 14 13:41:52 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 14 Oct 2006 15:41:52 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061014120957.GF23120@neu.nirvana> (Axel Thimm's message of "Sat, 14 Oct 2006 14:09:57 +0200") References: <87hcy8heo0.fsf@kosh.bigo.ensc.de> <87odsg3v5y.fsf@kosh.bigo.ensc.de> <20061014100426.GA23120@neu.nirvana> <87bqof5f9m.fsf@kosh.bigo.ensc.de> <20061014111928.GB23120@neu.nirvana> <877iz35dc3.fsf@kosh.bigo.ensc.de> <20061014115536.GD23120@neu.nirvana> <873b9r5chu.fsf@kosh.bigo.ensc.de> <20061014120957.GF23120@neu.nirvana> Message-ID: <87y7rj3tgf.fsf@kosh.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: >> then they must be in main packages, not in -devel. This thread shows >> why. > > Makes one wonder how RHL/RHEL/FC worked w/o doing so. 'rpm -qf /usr/lib/*.la' tells that there is no rule how FC is packaging .la. Packaging in main instead of -devel seems to be the preferred method; and it seems that this is intentionally: | * Wed Mar 05 2003 Than Ngo 1.1-8 | - move la files in arts package (bug #83607) Enrico From tcallawa at redhat.com Fri Oct 13 01:38:36 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 12 Oct 2006 20:38:36 -0500 Subject: [Fedora-packaging] Refining today's "don't touch system fs" guideline In-Reply-To: <20061012182003.GJ9881@neu.nirvana> References: <20061012182003.GJ9881@neu.nirvana> Message-ID: <1160703516.2619.587.camel@localhost.localdomain> On Thu, 2006-10-12 at 20:20 +0200, Axel Thimm wrote: > How about extending the rule and having a root/non-root rule, too, > e.g. Well, keep in mind that the buildsystem is building everything as non-root, so any "root" specific rules are not terribly valuable to Fedora (but are almost certainly good practices for packaging in general). > o Package builds should yield the same results irrespective of the > packaging process' uid/gid, for example builds under root and > non-root users should behave the same. While this is accurate, if we add it, it should be a SHOULD, and not a MUST. It is a SHOULD in Axel's wording, but I just want to emphasize the point. :) > o Build scripts of packages (%prep, %build, %install and %check) may > only alter files (create, modify, delete) under %{buildroot}, > %{_builddir} and valid temporary locations like /tmp, /var/tmp (or > $TMPDIR or %{_tmppath} as set by the rpmbuild process). > %{buildroot} should only be allowed to be altered in %install > scripts. > > Note I: The first part of this rule is automatically > fulfilled for typical non-user build process uids but the packager > should not rely on that, since users may rebuild the src.rpm under > root But we really don't want them too. Heck, I would wholeheartedly support patching rpm to complain when rpmbuild is being run by UID 0. :) Generally, people rebuilding packages as root don't know what they're doing. These are the same sort of people who are liable to download SRPMS willy-nilly, from any possible source (and for any possible distribution) and rebuild them. So even if Fedora sets the bar high for quality here, we still don't want people to think that rebuilding SRPMS as root is a recommended or safe idea. > Note II: As a consequence $HOME and similar parts of the filesystem > are not to be used directly. Of course some of the allowed write > spaces like the builddir, buildroot or $TMPDIR may have been placed > under $HOME, so indirectly a user may be writing under $HOME, but > direct access to parts under $HOME are strictly forbidden. Agreed. If an end-user wants to set their variables to brain-dead locations, then they deserve whatever pain they get. > Note III: Cheating with relative paths (".." escapes) grants you a > ticket to packaging hell. This really ought to be a MUST. Using relative paths ("..") in anything involving a write operation should be actively discouraged. Perhaps even using it at all should be discouraged. Example: Version 1 of Package foo leaves some junk in a toplevel directory. When we run make install, we get this junk as part of a glob. To keep the install clean (and minimize the amount of bleeding from the eyes of dealing with autotools), the packager does this: cd .. rm -rf foo* But, in version 2 of the Package foo, they get rid of these files for us, and incorporate the same command set in their build process, and leave us in that toplevel directory. Suddenly, we've dropped down a level and we're deleting all sorts of unexpected things. Hopefully, a packager would catch this before he sent it to the buildsystem, and yes, mock insulates us for this case (worst case, he kills himself and the build fails). But for the end-user, not rebuilding in mock, they may do more damage. Multiple relative paths ("../..") only make the damage potential worse. Just food for thought at 35,000 feet over the Pacific. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From tcallawa at redhat.com Fri Oct 13 01:49:37 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 12 Oct 2006 20:49:37 -0500 Subject: [Fedora-packaging] Kernel modules packaged for dkms In-Reply-To: References: <20061009151343.6d968164@python3.es.egwn.lan> <452A6CFA.1080205@leemhuis.info> <20061009183033.08e77573@python3.es.egwn.lan> Message-ID: <1160704177.2619.596.camel@localhost.localdomain> On Tue, 2006-10-10 at 11:00 +0300, Panu Matilainen wrote: > IIRC dkms was never *really* considered for the kernel module standard, > everybody was too busy arguing over uname-r in name, how to handle > debuginfo packages, what kind of macro magic to include, how many kernels > to build for in buildsys, how to teach the kmod scheme to buildsys etc. FWIW, this is not quite correct. When I first started working on the kernel module standard (back when I was the one-man-singing-dancing-standards-generation-engine), I looked at DKMS. (I even owned the package for a while in FE while Matt got his legal ducks in a row). The reason I discarded it was this: We can't expect end-users to have a build environment. At the time, dkms without a build environment wasn't all that interesting. Now, IMHO, if dkms would run against a kernel ver-variant string passed to it, and churn-churn-churn and spit out a set of kernel modules and a filelist for rpm to use, then it would be an ideal replacement for a lot of the kmod pain that we have today. Plus, it would do the building on the buildsystem, which is where it should be. (If dkms does this today, then super. Lets see an example spec.) ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From rdieter at math.unl.edu Sat Oct 14 18:50:13 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 14 Oct 2006 13:50:13 -0500 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <87y7rj3tgf.fsf@kosh.bigo.ensc.de> References: <87hcy8heo0.fsf@kosh.bigo.ensc.de> <87odsg3v5y.fsf@kosh.bigo.ensc.de> <20061014100426.GA23120@neu.nirvana> <87bqof5f9m.fsf@kosh.bigo.ensc.de> <20061014111928.GB23120@neu.nirvana> <877iz35dc3.fsf@kosh.bigo.ensc.de> <20061014115536.GD23120@neu.nirvana> <873b9r5chu.fsf@kosh.bigo.ensc.de> <20061014120957.GF23120@neu.nirvana> <87y7rj3tgf.fsf@kosh.bigo.ensc.de> Message-ID: <45313165.6080103@math.unl.edu> Enrico Scholz wrote: > Axel.Thimm at ATrpms.net (Axel Thimm) writes: > >>> then they must be in main packages, not in -devel. This thread shows >>> why. >> Makes one wonder how RHL/RHEL/FC worked w/o doing so. > > 'rpm -qf /usr/lib/*.la' tells that there is no rule how FC is packaging > .la. > > Packaging in main instead of -devel seems to be the preferred method; > and it seems that this is intentionally: > > | * Wed Mar 05 2003 Than Ngo 1.1-8 > | - move la files in arts package (bug #83607) No, arts (and kde bits in general) are an exception, don't use them to draw generalities. In fact, in general, .la files (associated with shared libs, no loadable modules), if packaged at all, belong in -devel. -- Rex From enrico.scholz at informatik.tu-chemnitz.de Sat Oct 14 21:22:40 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 14 Oct 2006 23:22:40 +0200 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <45313165.6080103@math.unl.edu> (Rex Dieter's message of "Sat, 14 Oct 2006 13:50:13 -0500") References: <87hcy8heo0.fsf@kosh.bigo.ensc.de> <87odsg3v5y.fsf@kosh.bigo.ensc.de> <20061014100426.GA23120@neu.nirvana> <87bqof5f9m.fsf@kosh.bigo.ensc.de> <20061014111928.GB23120@neu.nirvana> <877iz35dc3.fsf@kosh.bigo.ensc.de> <20061014115536.GD23120@neu.nirvana> <873b9r5chu.fsf@kosh.bigo.ensc.de> <20061014120957.GF23120@neu.nirvana> <87y7rj3tgf.fsf@kosh.bigo.ensc.de> <45313165.6080103@math.unl.edu> Message-ID: <87r6xa4mov.fsf@kosh.bigo.ensc.de> rdieter at math.unl.edu (Rex Dieter) writes: >>>> then they must be in main packages, not in -devel. This thread shows >>>> why. > ... > No, arts (and kde bits in general) are an exception, don't use them > to draw generalities. In fact, in general, .la files (associated > with shared libs, no loadable modules), if packaged at all, belong in > -devel. No; .la files can be referred by .la modules and must be in main therefore (for Axel: when packaged at all). See rest of the thread. Enrico From a.badger at gmail.com Sun Oct 15 10:26:39 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 15 Oct 2006 03:26:39 -0700 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <20061014115859.GE23120@neu.nirvana> References: <87hcy8heo0.fsf@kosh.bigo.ensc.de> <87odsg3v5y.fsf@kosh.bigo.ensc.de> <20061014100426.GA23120@neu.nirvana> <87bqof5f9m.fsf@kosh.bigo.ensc.de> <1160824819.4207.10.camel@viper.local> <20061014112928.GC23120@neu.nirvana> <1160826331.4207.16.camel@viper.local> <20061014115859.GE23120@neu.nirvana> Message-ID: <1160907999.2925.14.camel@localhost> On Sat, 2006-10-14 at 13:58 +0200, Axel Thimm wrote: > On Sat, Oct 14, 2006 at 02:45:31PM +0300, Ville Skytt? wrote: > > On Sat, 2006-10-14 at 13:29 +0200, Axel Thimm wrote: > > > On Sat, Oct 14, 2006 at 02:20:19PM +0300, Ville Skytt? wrote: > > > > > > > ...and in many cases, end up unnecessarily bloating linkage of > > > > binaries/libs in main packages too, making things like soname changes > > > > even more painful than they already are... > > > > > > I think the thread made clear that this is not the case. > > > > If it did, I missed it. Got any pointers to posts that support the > > above conclusion to share? > > How about this thread? No, honestly check the discussion especially > Alexandre's posts who goes into the details of both libtool and > non-libtool library internals. https://www.redhat.com/archives/fedora-packaging/2006-October/msg00080.html I think this is the best statement from Alexandre of the facts which he works out over the course of the message. I think there are two options for what to do about it: A) Get rid of .la's with the possible exception of when static libraries are kept (maybe this can go along with Ralf's Static Library proposal). Uses of lt_dlopen("foo.la") are bugs and should be fixed by converting to lt_dlopenext("foo") B) Keep all *.la's and create the complete Requires chains specified by the .la file (could be automated some day.) And also have Application packages that use lt_dlopen("foo.la") Require: the chains of library file *.la's that contain them. (Which either means application packages Requiring: *-devel packages or application and main library packages (libfoo rather than libfoo-devel) holding the *.la's) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Sun Oct 15 16:16:33 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 15 Oct 2006 11:16:33 -0500 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal In-Reply-To: <87r6xa4mov.fsf@kosh.bigo.ensc.de> References: <87hcy8heo0.fsf@kosh.bigo.ensc.de> <87odsg3v5y.fsf@kosh.bigo.ensc.de> <20061014100426.GA23120@neu.nirvana> <87bqof5f9m.fsf@kosh.bigo.ensc.de> <20061014111928.GB23120@neu.nirvana> <877iz35dc3.fsf@kosh.bigo.ensc.de> <20061014115536.GD23120@neu.nirvana> <873b9r5chu.fsf@kosh.bigo.ensc.de> <20061014120957.GF23120@neu.nirvana> <87y7rj3tgf.fsf@kosh.bigo.ensc.de> <45313165.6080103@math.unl.edu> <87r6xa4mov.fsf@kosh.bigo.ensc.de> Message-ID: Enrico Scholz wrote: > rdieter at math.unl.edu (Rex Dieter) writes: > >>>>> then they must be in main packages, not in -devel. This thread shows >>>>> why. >> ... >> No, arts (and kde bits in general) are an exception, don't use them >> to draw generalities. In fact, in general, .la files (associated >> with shared libs, no loadable modules), if packaged at all, belong in >> -devel. > > No; .la files can be referred by .la modules and must be in main therefore > (for Axel: when packaged at all). See rest of the thread. Yeah, I read it, and I disagreed then (and still do), but hadn't bothered to reply until now. -- Rex From rc040203 at freenet.de Wed Oct 18 08:10:18 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 18 Oct 2006 10:10:18 +0200 Subject: [Fedora-packaging] Re: Announcing Dribble a new addon repo for Fedora Extras users In-Reply-To: <1161097727.3997.34.camel@localhost.localdomain> References: <45324D96.1000401@hhs.nl> <1160960230.3084.3.camel@localhost> <45332CAA.7020106@hhs.nl> <45332F93.4000204@fedoraproject.org> <45333A2C.3060703@hhs.nl> <1161081156.8931.29.camel@localhost.localdomain> <1161097727.3997.34.camel@localhost.localdomain> Message-ID: <1161159018.5971.113.camel@mccallum.corsepiu.local> On Tue, 2006-10-17 at 10:08 -0500, Tom 'spot' Callaway wrote: > On Tue, 2006-10-17 at 05:32 -0500, Callum Lerwick wrote: > > On Mon, 2006-10-16 at 09:52 +0200, Hans de Goede wrote: > > > What I was trying to say with the above message is that if someone else > > > is willing to have the discussion for a package here and if the outcome > > > is that the package is ok for Extras then I'm more then happy to move it > > > to Extras including putting it through review (again as all packages in > > > dribble are already reviewed). > > > > I'll do it! (I used various Atari STs from 1987 to 1997...) > > > > On Mon, 2006-10-16 at 12:36 +0530, Rahul Sundaram wrote: > > > I believe the rule of thumb here is that if we have freely > > > redistributable "data" that runs on these emulators, we can include the > > > emulator in extras. In other words, the question to ask yourself, is > > > there any legal and Free software uses for the emulators? > > > > > > Since there's GPL ROMs available[1], and the commonly used FreeMiNT > > kernel is apparently a mix of GPL and BSD[2], and most anything open > > source has been ported, and even packaged into RPMs[3], seems to me any > > Atari ST series emulator should be okay in Extras. ARAnyM can even run > > Linux/68k[4]. > > > > Anyone disagree? Do we need a FESCo blessing? > > No disagreement here. This is fine for Fedora. Well, though I agree to you, I think you are about to construct a precedence, which longs for an explanation, which probably should be reflected to the package guidelines: This case clearly violates: http://fedoraproject.org/wiki/PackagingDrafts/SourceRequirement and also is not covered by http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware These ROMs aren't a linux system's firmware, these are a foreign system's firmware, to be interpreted by an interpreter (emulator). Ralf From tibbs at math.uh.edu Wed Oct 18 14:42:01 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 18 Oct 2006 09:42:01 -0500 Subject: [Fedora-packaging] Re: Announcing Dribble a new addon repo for Fedora Extras users In-Reply-To: <1161159018.5971.113.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Wed, 18 Oct 2006 10:10:18 +0200") References: <45324D96.1000401@hhs.nl> <1160960230.3084.3.camel@localhost> <45332CAA.7020106@hhs.nl> <45332F93.4000204@fedoraproject.org> <45333A2C.3060703@hhs.nl> <1161081156.8931.29.camel@localhost.localdomain> <1161097727.3997.34.camel@localhost.localdomain> <1161159018.5971.113.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> This case clearly violates: RC> http://fedoraproject.org/wiki/PackagingDrafts/SourceRequirement Except that it's firmware. RC> and also is not covered by RC> http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware It seems to me that it is. "Some applications and drivers require binary-only firmware to function." OK, this is an application (an emulator) which requires the host system's binary firmware in order to function. "The files are non-executable (note: this means that the files cannot run on their own, not that they are just chmod -x)" Check. "The files are not libraries." Check. "The files are standalone, not embedded in executable or library code." Check. "Explicit permission is given by the owner to freely distribute without restrictions (this permission must be included, in "writing", with the files in the packaging)" Check. "The files must be necessary for the functionality of open source code being included in Fedora." Check. I assume you disagree with one or more of these, but I'm not sure which. RC> These ROMs aren't a linux system's firmware, these are a foreign RC> system's firmware, to be interpreted by an interpreter (emulator). Precisely. Are you drawing the distinction between firmware that is executed by hardware that that which is executed by emulated hardware, perhaps? - J< From rc040203 at freenet.de Wed Oct 18 15:08:23 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 18 Oct 2006 17:08:23 +0200 Subject: [Fedora-packaging] Re: Announcing Dribble a new addon repo for Fedora Extras users In-Reply-To: References: <45324D96.1000401@hhs.nl> <1160960230.3084.3.camel@localhost> <45332CAA.7020106@hhs.nl> <45332F93.4000204@fedoraproject.org> <45333A2C.3060703@hhs.nl> <1161081156.8931.29.camel@localhost.localdomain> <1161097727.3997.34.camel@localhost.localdomain> <1161159018.5971.113.camel@mccallum.corsepiu.local> Message-ID: <1161184103.10220.40.camel@mccallum.corsepiu.local> On Wed, 2006-10-18 at 09:42 -0500, Jason L Tibbitts III wrote: > >>>>> "RC" == Ralf Corsepius writes: > > RC> This case clearly violates: > RC> http://fedoraproject.org/wiki/PackagingDrafts/SourceRequirement > > Except that it's firmware. C.f. below: I am questioning the separation between "firmware" and "binary". > RC> and also is not covered by > RC> http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > > It seems to me that it is. > > "Some applications and drivers require binary-only firmware to > function." > > OK, this is an application (an emulator) which requires the host > system's binary firmware in order to function. > > "The files are non-executable (note: this means that the files cannot > run on their own, not that they are just chmod -x)" > > Check. Only a matter of mime-types, resp. of the way an emulator is being launched. > "The files are not libraries." > > Check. Irrelevant. Traditional libraries (ar-archives) are just a form of packaging. > "The files are standalone, not embedded in executable or library code." > > Check. Irrelevant, implementation detail. Such images can easily be transformed between different representations. Technically it doesn't matter if they are loaded from external files into memory or are directly embedded into a application's memory. > "Explicit permission is given by the owner to freely distribute > without restrictions (this permission must be included, in "writing", > with the files in the packaging)" > > Check. ACK. > "The files must be necessary for the functionality of open source code > being included in Fedora." > > Check. ACK. > I assume you disagree with one or more of these, but I'm not sure which. > > RC> These ROMs aren't a linux system's firmware, these are a foreign > RC> system's firmware, to be interpreted by an interpreter (emulator). > > Precisely. Are you drawing the distinction between firmware that is > executed by hardware that that which is executed by emulated hardware, > perhaps? Absolutely not. I am not questioning allowing such binaries (I am all for it), I am questioning the Fedora Packaging Guidelines. I consider the separation of firmware from "other binaries" inside of the FPG to be nonsensical and the criteria above to be nonsensical, and wish we (FPC) were able to find better criteria. Consider, an emulator's "firmware" from a Linux's system's perspective is not any different from other "binary shipped applications" to be run on an interpreter. Ralf From Axel.Thimm at ATrpms.net Wed Oct 18 16:13:15 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 18 Oct 2006 18:13:15 +0200 Subject: [Fedora-packaging] Re: Announcing Dribble a new addon repo for Fedora Extras users In-Reply-To: <1161184103.10220.40.camel@mccallum.corsepiu.local> References: <45324D96.1000401@hhs.nl> <1160960230.3084.3.camel@localhost> <45332CAA.7020106@hhs.nl> <45332F93.4000204@fedoraproject.org> <45333A2C.3060703@hhs.nl> <1161081156.8931.29.camel@localhost.localdomain> <1161097727.3997.34.camel@localhost.localdomain> <1161159018.5971.113.camel@mccallum.corsepiu.local> <1161184103.10220.40.camel@mccallum.corsepiu.local> Message-ID: <20061018161315.GB24252@neu.nirvana> On Wed, Oct 18, 2006 at 05:08:23PM +0200, Ralf Corsepius wrote: > I consider the separation of firmware from "other binaries" inside of > the FPG to be nonsensical and the criteria above to be nonsensical, and > wish we (FPC) were able to find better criteria. I think the package group's mandate is about *how* to package, not *what* to package and whether it's legal, endagers Fedora sponsors, is in the spirit of Fedora etc. E.g. these goals are set from a higher instance and we just provide matching guidelines. IMO we shouldn't redefine objectives, this needs to be escalated to . Especially if something isn't spelled out in the current objectives as clear as the position/distinction towards firmwares and other non-source binaries. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chris.stone at gmail.com Wed Oct 18 17:03:28 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 18 Oct 2006 10:03:28 -0700 Subject: [Fedora-packaging] Fedora Packaging Member forking Fedora/Causing problems with community and users Message-ID: As you are all probably intimately aware by now, there has been discussions about 3rd party repositories overriding base Fedora packages and creating their own distribution which causes very serious problems for users and damages the community. I suggest that we have a comittee (possibly the packaging comittee) create a wiki page which reviews 3rd party repositories for such things as: - Does the repository have a review process - Does the repository abide by Fedora packaging standards - Does the repository override Fedora base packages and possibly other criteria. This will allow users to see which 3rd party repositories play nice with Fedora, and which ones fork Fedora to create their own distributions, etc. I FIND IT *VERY* DISTRUBING THAT ONE OF THESE REPOSITORY MAINTAINERS IS ON THE FEDORA PACKAGING COMITTEE! Here is an example IRC log that was taken just last night illustrating the problem: 20:40:49 RyeBrye | Trying to get yum to install gtk2-devel from the update repo I get 4 dependency errors 20:41:10 RyeBrye | the first one is gtk2 itself 20:41:17 XulChris | RyeBrye: caused by using atrpms no doubt 20:41:25 RyeBrye | hm 20:41:34 RyeBrye | How can I tell which packages I have installed that came from atrpms? 20:42:00 XulChris | RyeBrye: disable the atrpms repo, and run "yum list extras" 20:43:42 RyeBrye | I'm relatively new to Linux - but it seems that the prevailing opinion is that atrpms = the devil 20:44:23 XulChris | RyeBrye: basically yes, we even attempted to tell AT this, but he refused to listen and accused of of using "FUD" techniques against his repository 20:44:40 RyeBrye | Oh. AT is a person? 20:44:46 XulChris | Axel Thimm 20:45:49 XulChris | RyeBrye: we are trying to put measures in place to prevent repositories from doing this 20:45:59 XulChris | see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211250 20:50:06 RyeBrye | Sounds like I should get that "priorities" plugin for yum going to prevent atrpms from going buck-wild installing packages 20:50:39 errr | oh boy, more atrpms "fud" :P 20:50:52 XulChris | RyeBrye: yea, or if you just need a single rpm, try installing it by hand using the rpm command instead of yum, and if it doesnt install, get the srpm file and rebuild the rpm from the srpm 20:51:08 XulChris | errr: lol 20:51:27 errr | that was really getting funny in my inbox the other day 20:51:53 XulChris | ya, what did we get? like 80 messages within 24 hours? :) 20:52:00 errr | maybe more 20:52:00 errr | lol 20:52:04 XulChris | hehe 20:52:11 * rewster is pretty sure atrpms' rpm for Myth doesn't build as-is on stock fedora 20:53:51 * RyeBrye is busy removing a whole lot of crap because atrpms installed a gtk2 package - and just about everything he installed from atrpms (mythtv) depended on it 20:53:56 rewster | err srpm. and I think the OP mentioned having AT for myth. 20:54:18 RyeBrye | or rather... yum is busy removing it 20:54:20 rewster | yeah... which is a bummer. A lot of the faqs for myth just say "use atrpms" 22:09:56 RyeBrye | ATRpms really f*'ed up my system... it installed a gtk2 that - when I removed it - removed just about every darn package I had installed because of dependencies... argggggg 22:10:18 EvilBob | RyeBrye: file a bug with them 22:10:24 autopsy | RyeBrye, don't use ATrpms. 22:10:27 siXy | again? 22:10:28 EvilBob | RyeBrye: PLEASE 22:10:42 errr | lol 22:10:49 RyeBrye | I'm learning my lesson... 22:10:56 RyeBrye | Does livna really have mythtv rpms? 22:10:59 siXy | or are you reffering to the first time? 22:11:02 siXy | no 22:11:05 EvilBob | RyeBrye: sorry you got burned but the maintainer insists that there is not a problem with how he does things 22:11:12 errr | does Alex never come to this IRC? 22:11:24 autopsy | You mean Axel. 22:11:26 siXy | axel is an interesting guy... 22:11:28 EvilBob | errr: Alex who? 22:11:34 RyeBrye | Why doesn't he just make his own damned distro! argh 22:11:40 XulChris | EvilBob: axel thimm (AT) 22:11:43 errr | autopsy: oh maybe I do 22:11:45 siXy | some would say he does 22:11:50 EvilBob | RyeBrye: add that to your bug 22:12:20 errr | I dont follow the room all that close but at least once or twice a week I notice someone in here with the ATrpms sobstory 22:12:52 siXy | but anyways - do like i told you and update, then enable atrpms grab myth and its explicit dependancies then delete the atrpms repo 22:13:13 RyeBrye | siXy - yeah, you are right 22:13:31 EvilBob | never ever update with atRPMs enabled 22:13:44 siXy | its important you update fist tho otherwise when you grab myth that will pull some atrpms pacakges that you really dont want 22:14:11 RyeBrye | is there a way to update without it loading a new kernel? I don't feel like rebuilding all my kernel extensions at the moment 22:14:53 siXy | RyeBrye: do you have a copy of that line to remove all atrpms pacakges? was trying to remember it earlier for someone else 22:14:53 chemaja The bz that XulChris pointed us to (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211250) will be the key once it is implemented. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Oct 18 17:19:18 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 18 Oct 2006 19:19:18 +0200 Subject: [Fedora-packaging] Fedora Packaging Member forking Fedora/Causing problems with community and users In-Reply-To: References: Message-ID: <20061018191918.53f1a2a8@python3.es.egwn.lan> Christopher Stone wrote : > As you are all probably intimately aware by now, there has been > discussions about 3rd party repositories overriding base Fedora > packages and creating their own distribution which causes very serious > problems for users and damages the community. This definitely reads like a personal opinion more than a fact. > I suggest that we have a comittee (possibly the packaging comittee) > create a wiki page which reviews 3rd party repositories for such > things as: > - Does the repository have a review process > - Does the repository abide by Fedora packaging standards > - Does the repository override Fedora base packages > and possibly other criteria. > > This will allow users to see which 3rd party repositories play nice > with Fedora, and which ones fork Fedora to create their own > distributions, etc. I don't see how this is possible nor how it would help the Fedora project in any way. Fedora is about Core, Extras and all the orbiting projects. It's not about going hunting for (nor caring about) external stuff. > I FIND IT *VERY* DISTRUBING THAT ONE OF THESE REPOSITORY MAINTAINERS > IS ON THE FEDORA PACKAGING COMITTEE! Again : Your opinion. I didn't reply in the OT flame fest, and will only reply once here, quoting Jesse : "Make it stop!!" It wasn't meant for the maintainers list, I don't see how it suits the packagers list any better. Thanks. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2759.fc6 Load : 0.27 0.26 0.26 From gdk at redhat.com Wed Oct 18 17:24:04 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 18 Oct 2006 13:24:04 -0400 (EDT) Subject: [Fedora-packaging] Fedora Packaging Member forking Fedora/Causing problems with community and users In-Reply-To: References: Message-ID: On Wed, 18 Oct 2006, Christopher Stone wrote: > I suggest that we have a comittee (possibly the packaging comittee) > create a wiki page which reviews 3rd party repositories for such > things as: > - Does the repository have a review process > - Does the repository abide by Fedora packaging standards > - Does the repository override Fedora base packages > and possibly other criteria. > > This will allow users to see which 3rd party repositories play nice > with Fedora, and which ones fork Fedora to create their own > distributions, etc. > > I FIND IT *VERY* DISTRUBING THAT ONE OF THESE REPOSITORY MAINTAINERS > IS ON THE FEDORA PACKAGING COMITTEE! You know what? I find it very disturbing that, despite the best efforts of everyone to keep this thread reasonably civil, you continue to derail it with nonsense like this. NOBODY IS IMPRESSED WHEN YOU SHOUT. Do you know why Axel is on the packaging committee? Because Axel was one of the people who was doing a good job at creating packages for Fedora before the Fedora Extras committee was even vaguely functional. Because Axel has earned the respect of Fedora packagers all over the world with his knowledge, insights, and hard work. Because we don't always agree with Axel's decisions, but we also understand that diversity in the decision-making body helps us come to stronger decisions. Personally? I think we need the mechanism you suggest, Chris. But you make it *insanely* difficult to take your side with this kind of behavior. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From rdieter at math.unl.edu Wed Oct 18 17:54:59 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 18 Oct 2006 12:54:59 -0500 Subject: [Fedora-packaging] Fedora Packaging Member forking Fedora/Causing problems with community and users In-Reply-To: References: Message-ID: <45366A73.1070801@math.unl.edu> Christopher Stone wrote: > I suggest that we have a comittee (possibly the packaging comittee) > create a wiki page which reviews 3rd party repositories for such > things as: IMO, this is outside the scope of the packaging committee's mandate/rights/responsibility. I'd suggest you start a new SIG if you feel so strongly about this subject. -- Rex From chris.stone at gmail.com Wed Oct 18 18:02:18 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 18 Oct 2006 11:02:18 -0700 Subject: [Fedora-packaging] Fedora Packaging Member forking Fedora/Causing problems with community and users In-Reply-To: <45366A73.1070801@math.unl.edu> References: <45366A73.1070801@math.unl.edu> Message-ID: On 10/18/06, Rex Dieter wrote: > Christopher Stone wrote: > > > I suggest that we have a comittee (possibly the packaging comittee) > > create a wiki page which reviews 3rd party repositories for such > > things as: > > IMO, this is outside the scope of the packaging committee's > mandate/rights/responsibility. > > I'd suggest you start a new SIG if you feel so strongly about this subject. I would be perfectly happy with this, even If its a one man SIG consisting of only me. As long as there is a wiki page on the Fedora wiki which has this information and users can be pointed to this page to learn about the consequences of installing another repository I would be happy. However, I think it would be better to have a comittee review other repositories instead of a single person who might be biased such as myself. From tcallawa at redhat.com Wed Oct 18 19:33:13 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 18 Oct 2006 14:33:13 -0500 Subject: [Fedora-packaging] Fedora Packaging Member forking Fedora/Causing problems with community and users In-Reply-To: References: <45366A73.1070801@math.unl.edu> Message-ID: <1161199994.23519.12.camel@localhost.localdomain> On Wed, 2006-10-18 at 11:02 -0700, Christopher Stone wrote: > On 10/18/06, Rex Dieter wrote: > > Christopher Stone wrote: > > > > > I suggest that we have a comittee (possibly the packaging comittee) > > > create a wiki page which reviews 3rd party repositories for such > > > things as: > > > > IMO, this is outside the scope of the packaging committee's > > mandate/rights/responsibility. > > > > I'd suggest you start a new SIG if you feel so strongly about this subject. > > I would be perfectly happy with this, even If its a one man SIG > consisting of only me. As long as there is a wiki page on the Fedora > wiki which has this information and users can be pointed to this page > to learn about the consequences of installing another repository I > would be happy. > > However, I think it would be better to have a comittee review other > repositories instead of a single person who might be biased such as > myself. I think that if this is as big of a problem as you claim, then it should be rather trivial for you (or someone else motivated) to install a Fedora box, enable the atrpms repo, and start filing bugs if/when things break. I even think it would be more productive to highlight the FC or FE packages that atrpms is providing overrides for, and start a discussion around why these packages exist, and if there exists the possibility to merge the changes into the FC or FE package and retire the atrpms packages. I'm sure that Axel would welcome that discussion, as less packages means less work for him. :) Running around screaming isn't really going to motivate anyone. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From chris.stone at gmail.com Wed Oct 18 20:24:28 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 18 Oct 2006 13:24:28 -0700 Subject: [Fedora-packaging] Fedora Packaging Member forking Fedora/Causing problems with community and users In-Reply-To: <1161199994.23519.12.camel@localhost.localdomain> References: <45366A73.1070801@math.unl.edu> <1161199994.23519.12.camel@localhost.localdomain> Message-ID: On 10/18/06, Tom 'spot' Callaway wrote: > On Wed, 2006-10-18 at 11:02 -0700, Christopher Stone wrote: > > On 10/18/06, Rex Dieter wrote: > > > Christopher Stone wrote: > > > > > > > I suggest that we have a comittee (possibly the packaging comittee) > > > > create a wiki page which reviews 3rd party repositories for such > > > > things as: > > > > > > IMO, this is outside the scope of the packaging committee's > > > mandate/rights/responsibility. > > > > > > I'd suggest you start a new SIG if you feel so strongly about this subject. > > > > I would be perfectly happy with this, even If its a one man SIG > > consisting of only me. As long as there is a wiki page on the Fedora > > wiki which has this information and users can be pointed to this page > > to learn about the consequences of installing another repository I > > would be happy. > > > > However, I think it would be better to have a comittee review other > > repositories instead of a single person who might be biased such as > > myself. > > I think that if this is as big of a problem as you claim, then it should > be rather trivial for you (or someone else motivated) to install a > Fedora box, enable the atrpms repo, and start filing bugs if/when things > break. I even think it would be more productive to highlight the FC or > FE packages that atrpms is providing overrides for, and start a > discussion around why these packages exist, and if there exists the > possibility to merge the changes into the FC or FE package and retire > the atrpms packages. I'm sure that Axel would welcome that discussion, > as less packages means less work for him. :) Fair enough. I will start by filing a bug report against the gtk libs RyeBrye had problems with. I hope this solution works. If it does not, I will re-address this issue here. From Axel.Thimm at ATrpms.net Wed Oct 18 21:21:45 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 18 Oct 2006 23:21:45 +0200 Subject: [Fedora-packaging] Re: Fedora Packaging Member forking Fedora/Causing problems with community and users In-Reply-To: References: Message-ID: <20061018212145.GB2279@neu.nirvana> I'm sorry to the fellow list members - I did stop defending against Christopher's FUD, but instead of a deescalation and a fade out, I now see him spreading FUD on websites, irc, several fedora lists, more bugzilla reports and probably any other means as well. It looks like a raging personal crusade. But since there are some very false statements placed by him into archives/bugzillas/google I need to rectify some of them at least. On Wed, Oct 18, 2006 at 10:03:28AM -0700, Christopher Stone wrote: > As you are all probably intimately aware by now, there has been > discussions about 3rd party repositories overriding base Fedora > packages and creating their own distribution which causes very serious > problems for users and damages the community. > I FIND IT *VERY* DISTRUBING THAT ONE OF THESE REPOSITORY MAINTAINERS > IS ON THE FEDORA PACKAGING COMITTEE! > > Here is an example IRC log that was taken just last night illustrating > the problem: Indeed! Perhaps you'll be surpised to find me agreeing that it illustrates the problem excellently! > 20:40:49 RyeBrye | Trying to get yum to install gtk2-devel > from the update repo I get 4 dependency errors > 20:41:10 RyeBrye | the first one is gtk2 itself > 20:41:17 XulChris | RyeBrye: caused by using atrpms no doubt > [...] > 20:43:42 RyeBrye | I'm relatively new to Linux - but it seems > that the prevailing opinion is that atrpms = the devil > 20:44:23 XulChris | RyeBrye: basically yes, we even attempted to > tell AT this, but he refused to listen and accused of of using "FUD" > techniques against his > repository > [...] > 20:53:51 * RyeBrye is busy removing a whole lot of crap because > atrpms installed a gtk2 package - and just about everything he > installed from atrpms (mythtv) > depended on it Now let's see, someone has an issue with gtk. XulChris (Chistopher Stone?) immediately accuses ATrpms ("no doubt"!). The reporting user believes that w/o questioning since he got some valuable consulting from XulChris who seems to have great insights in this matter. The culmination is the establishment that ATrpms managed to pull in gtk due to mythtv depending on in. Everybody then goes on in slantering ATrpms and Axel Thimm for doing such bad things. Now to the simple two facts reverting the "problem" a) mythtv is a qt application b) ATrpms has no gtk packages The user probably has some random issue and ATrpms is a good scapegoat. So what is the "problem"? It is o misinformation o 0 research o blind accusation o in short FUD It's also self-generating FUD. Tomorrow some of the people in the IRC will hear of someone with problem in his say bind update. They will ask him whether he has ATrpms enables and advise him to reinstall from scratch. The next day the guy doing the last reinstallation will reenforce someone else that ATrpms is bad and that his power issues on the monitor are due to having installed ATrpms. I hope it doesn't end assuming that evils spreading from *.gov and *.mil (and other foreign equivalents) are due to some PC in there having ATrpms enabled. ... So Chistopher Stone and people like him are not providing a solution to an alleged problem, but instead constitute themselfes great part of the problem. He is building walls where others try to build bridges. Note: The main theme of the "issues by ATrpms" is the package replacement policy. The ones that are longer here around or are ATrpms' users will know that there *are* efforts (and results) to reduce the overlaps and to provide a repo-side solution. Certainly not due to Chistopher's FUD, though. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chris.stone at gmail.com Thu Oct 19 00:19:28 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 18 Oct 2006 17:19:28 -0700 Subject: [Fedora-packaging] Fedora Packaging Member forking Fedora/Causing problems with community and users In-Reply-To: References: <45366A73.1070801@math.unl.edu> <1161199994.23519.12.camel@localhost.localdomain> Message-ID: On 10/18/06, Christopher Stone wrote: > On 10/18/06, Tom 'spot' Callaway wrote: > > On Wed, 2006-10-18 at 11:02 -0700, Christopher Stone wrote: > > > On 10/18/06, Rex Dieter wrote: > > > > Christopher Stone wrote: > > > > > > > > > I suggest that we have a comittee (possibly the packaging comittee) > > > > > create a wiki page which reviews 3rd party repositories for such > > > > > things as: > > > > > > > > IMO, this is outside the scope of the packaging committee's > > > > mandate/rights/responsibility. > > > > > > > > I'd suggest you start a new SIG if you feel so strongly about this subject. > > > > > > I would be perfectly happy with this, even If its a one man SIG > > > consisting of only me. As long as there is a wiki page on the Fedora > > > wiki which has this information and users can be pointed to this page > > > to learn about the consequences of installing another repository I > > > would be happy. > > > > > > However, I think it would be better to have a comittee review other > > > repositories instead of a single person who might be biased such as > > > myself. > > > > I think that if this is as big of a problem as you claim, then it should > > be rather trivial for you (or someone else motivated) to install a > > Fedora box, enable the atrpms repo, and start filing bugs if/when things > > break. I even think it would be more productive to highlight the FC or > > FE packages that atrpms is providing overrides for, and start a > > discussion around why these packages exist, and if there exists the > > possibility to merge the changes into the FC or FE package and retire > > the atrpms packages. I'm sure that Axel would welcome that discussion, > > as less packages means less work for him. :) > > Fair enough. I will start by filing a bug report against the gtk libs > RyeBrye had problems with. I hope this solution works. If it does > not, I will re-address this issue here. > I have filed over one-hundred and ten (110+) bugs for conflicts between ATrpms and FC/FE repositories. The tracker bug can be found here: http://bugzilla.atrpms.net/show_bug.cgi?id=1028 So let's see what becomes of this. AT should be happy because this is probably over 50% of his packages, so his work load should be cut in half. From rc040203 at freenet.de Thu Oct 19 05:03:01 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 19 Oct 2006 07:03:01 +0200 Subject: [Fedora-packaging] Re: Announcing Dribble a new addon repo for Fedora Extras users In-Reply-To: <20061018161315.GB24252@neu.nirvana> References: <45324D96.1000401@hhs.nl> <1160960230.3084.3.camel@localhost> <45332CAA.7020106@hhs.nl> <45332F93.4000204@fedoraproject.org> <45333A2C.3060703@hhs.nl> <1161081156.8931.29.camel@localhost.localdomain> <1161097727.3997.34.camel@localhost.localdomain> <1161159018.5971.113.camel@mccallum.corsepiu.local> <1161184103.10220.40.camel@mccallum.corsepiu.local> <20061018161315.GB24252@neu.nirvana> Message-ID: <1161234182.10220.81.camel@mccallum.corsepiu.local> On Wed, 2006-10-18 at 18:13 +0200, Axel Thimm wrote: > On Wed, Oct 18, 2006 at 05:08:23PM +0200, Ralf Corsepius wrote: > > I consider the separation of firmware from "other binaries" inside of > > the FPG to be nonsensical and the criteria above to be nonsensical, and > > wish we (FPC) were able to find better criteria. > > I think the package group's mandate is about *how* to package, ACK. > not > *what* to package and whether it's legal, endagers Fedora sponsors, is > in the spirit of Fedora etc. This questions lurking inside of this topic are "how" questions: * "How to package package-fragments source ship/require in binary form" * "When to consider rebuilding from sources not useful". The FPG it tries to narrow this problem to a set of precedences of exception on "what" (firmware), but actually doesn't cover these questions above, except that it wants packagers "to build everything from sources". > E.g. these goals are set from a higher instance and we just provide > matching guidelines. IMO we shouldn't redefine objectives, this needs > to be escalated to . Especially if something isn't > spelled out in the current objectives as clear as the > position/distinction towards firmwares and other non-source binaries. The later half of your sentence is what I consider not to be clear. Technically, firmware blobs are "download images", i.e. a container of arbitrary format with arbitrary contents, just like floppy disks images, CDROM images, tarballs or ar-archives. Do you note how the FPG criteria manage to miss the topic? Ralf From chris.stone at gmail.com Thu Oct 19 06:22:55 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 18 Oct 2006 23:22:55 -0700 Subject: [Fedora-packaging] Apology to Axel and Lists Message-ID: I would like to apologize to Axel and the mailing lists for some of the things I have written in the past few days which has lead to quite an extensive flame war over an issue we are all passionate about -- Fedora. When building bridges it is good to look for commonality between adversaries and Axel and I have one thing in common which is that we both want the best experience possible for Fedora users. Accomplishing this goal through flame wars is *not* the way to go, and I apologize to the mailing list and Axel for feeding the flame. From this point on I promise to try my best to be as tactful as possible in this and all future discussions on the list. I am confident that going from here forward we can all work together to make Fedora the best distribution on the planet, and I hope Axel feels the same way. Hopefully we can work together to work out our problems and come to an agreeable solution for everyone. I look forward to working with Axel and the rest of the community with technical discussions to make the highest quality packages and repositories to ultimately give the best possible experience for Fedora users. Sincerely, Christopher Stone aka XulChris From bugs.michael at gmx.net Thu Oct 19 09:04:22 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 19 Oct 2006 11:04:22 +0200 Subject: [Fedora-packaging] Extras package enables 3rd party repository Message-ID: <20061019110422.5ff37f9f.bugs.michael@gmx.net> Do we want to permit packages in Fedora Extras, which install and enable by default a 3rd party repository? Forwarded message below. It doesn't affect me personally, but in general it would be a tendency I dislike, particularly since this broke the user's system due to unavailability of the added repo. I don't want to file a bug report about this without prior backing from the FPG. [...] Begin forwarded message: Date: Mon, 16 Oct 2006 01:22:44 +0200 From: Michael Schwendt To: fedora-test-list at redhat.com Subject: Re: Working on the rawhide extras (Is it broken now?) On Sun, 15 Oct 2006 16:31:16 -0400, Ernest L. Williams Jr. wrote: > On Sun, 2006-10-15 at 16:24 -0400, Ernest L. Williams Jr. wrote: > > Hi, > > > > I was using yum install to get the Fedora extras from rawhide. I > > managed to get up through the letter "c" in terms of packages. > > > > > > Now, I am getting the following error: > > ================================================================== > > [root at python yum]# yum install ddd > > Loading "installonlyn" plugin > > Setting up Install Process > > Setting up repositories > > ftp://ftp.safe.ca/pub/clement-2.1/repodata/repomd.xml: [Errno 4] > > IOError: [Errno ftp error] 550 Failed to change directory. > > Trying other mirror. > > Error: Cannot open/read repomd.xml file for repository: clement > > [root at python yum]# > > ================================================================= > > > > Who/What by the way is clement??? $ rpm -qlvp clement-2.1-209.1.fc6.i386.rpm |grep yum -rw-r--r-- 1 root root 192 Sep 4 13:18 /etc/yum.repos.d/clement.repo Uhm... it's a package in Fedora Extras which installs and enables an external Yum repository for "updates". Highly questionable, since those updates ought to be provided within Fedora Extras. This asks for a new policy. Makes me wonder whether this has been like that during package review already or whether the packager added it later. > > Any ideas, how to work around this one? > > I disabled clement.repo > What does clement have to do with yum??? From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Oct 19 09:07:40 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 19 Oct 2006 11:07:40 +0200 Subject: [Fedora-packaging] Extras package enables 3rd party repository In-Reply-To: <20061019110422.5ff37f9f.bugs.michael@gmx.net> References: <20061019110422.5ff37f9f.bugs.michael@gmx.net> Message-ID: <20061019110740.71fb2597@python3.es.egwn.lan> Michael Schwendt wrote : > Do we want to permit packages in Fedora Extras, which install and enable > by default a 3rd party repository? > > Forwarded message below. > > It doesn't affect me personally, but in general it would be a tendency > I dislike, particularly since this broke the user's system due to > unavailability of the added repo. > > I don't want to file a bug report about this without prior backing from > the FPG. > > [...] I don't see the point of enabling new repositories from within Extras packages. If more stuff needs to be available, then it should go in Extras, period. If it can't go in Extras, then it probably can't be enabled automatically either for the same (legal) reasons. I would favour disallowing this, for the reason above, and encourage packagers to import and maintain their packages in Extras. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2759.fc6 Load : 0.11 0.17 0.17 From paul at city-fan.org Thu Oct 19 09:15:09 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 19 Oct 2006 10:15:09 +0100 Subject: [Fedora-packaging] Extras package enables 3rd party repository In-Reply-To: <20061019110422.5ff37f9f.bugs.michael@gmx.net> References: <20061019110422.5ff37f9f.bugs.michael@gmx.net> Message-ID: <4537421D.5050504@city-fan.org> Michael Schwendt wrote: > Do we want to permit packages in Fedora Extras, which install and enable > by default a 3rd party repository? ... > $ rpm -qlvp clement-2.1-209.1.fc6.i386.rpm |grep yum > -rw-r--r-- 1 root root 192 Sep 4 13:18 /etc/yum.repos.d/clement.repo > > Uhm... it's a package in Fedora Extras which installs and enables an > external Yum repository for "updates". Highly questionable, since those > updates ought to be provided within Fedora Extras. > > This asks for a new policy. > > Makes me wonder whether this has been like that during package review > already or whether the packager added it later. It was there at review time but not commented on: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176253 Paul. From Axel.Thimm at ATrpms.net Thu Oct 19 11:36:26 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 19 Oct 2006 13:36:26 +0200 Subject: [Fedora-packaging] Re: Apology to Axel and Lists In-Reply-To: References: Message-ID: <20061019113626.GC9514@neu.nirvana> Thanks, Christopher, for ending this. To lighten our moods we can start looking forward to FC6. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Oct 19 11:55:27 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 19 Oct 2006 13:55:27 +0200 Subject: [Fedora-packaging] Firmwares, roms and who decides on packagable items In-Reply-To: <1161234182.10220.81.camel@mccallum.corsepiu.local> References: <45332CAA.7020106@hhs.nl> <45332F93.4000204@fedoraproject.org> <45333A2C.3060703@hhs.nl> <1161081156.8931.29.camel@localhost.localdomain> <1161097727.3997.34.camel@localhost.localdomain> <1161159018.5971.113.camel@mccallum.corsepiu.local> <1161184103.10220.40.camel@mccallum.corsepiu.local> <20061018161315.GB24252@neu.nirvana> <1161234182.10220.81.camel@mccallum.corsepiu.local> Message-ID: <20061019115527.GD9514@neu.nirvana> On Thu, Oct 19, 2006 at 07:03:01AM +0200, Ralf Corsepius wrote: > > I think the package group's mandate is about *how* to package, > ACK. > > > not *what* to package and whether it's legal, endagers Fedora > > sponsors, is in the spirit of Fedora etc. > > This questions lurking inside of this topic are "how" questions: > * "How to package package-fragments source ship/require in binary form" > * "When to consider rebuilding from sources not useful". > > The FPG it tries to narrow this problem to a set of precedences of > exception on "what" (firmware), but actually doesn't cover these > questions above, except that it wants packagers "to build everything > from sources". > > > E.g. these goals are set from a higher instance and we just provide > > matching guidelines. IMO we shouldn't redefine objectives, this needs > > to be escalated to . Especially if something isn't > > spelled out in the current objectives as clear as the > > position/distinction towards firmwares and other non-source binaries. > > The later half of your sentence is what I consider not to be clear. > > Technically, firmware blobs are "download images", i.e. a container of > arbitrary format with arbitrary contents, just like floppy disks images, > CDROM images, tarballs or ar-archives. > > Do you note how the FPG criteria manage to miss the topic? What I'm trying to say is that we need to get told what is allowed to be packaged or not. Some here consider roms for emulators firmware, others not, and depending on that we can or cannot apply existing rules about firmwares. Instead of fighting over definitions let's just ask our parents to decide on roms of emulators. Just to present the hyperbole: Next somone packages filesystem images for qemu and argues that these are firmwares, too. I wouldn't want to be arguing against or in favour of that, we need clear a list of clear exceptions to open source items. Or a more down-to-earth example: madwifi argues that the closed source part of it is like firmware for various reasons (I'm not trying to support or not that view, just giving examples). So, as a dump package engineer, who's job is to craft technical guidelines on *how* to package stuff, I want to get the set of packagable items from management. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Thu Oct 19 13:16:50 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 19 Oct 2006 08:16:50 -0500 Subject: [Fedora-packaging] Extras package enables 3rd party repository In-Reply-To: <20061019110422.5ff37f9f.bugs.michael@gmx.net> References: <20061019110422.5ff37f9f.bugs.michael@gmx.net> Message-ID: <45377AC2.1090806@math.unl.edu> Michael Schwendt wrote: > Do we want to permit packages in Fedora Extras, which install and enable > by default a 3rd party repository? Absolutely not(*). -- Rex (*) Offhand, I can't think of any valid/acceptable use-case for this, but that doesn't mean one doesn't exist. From jkeating at redhat.com Thu Oct 19 13:27:51 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 19 Oct 2006 09:27:51 -0400 Subject: [Fedora-packaging] Extras package enables 3rd party repository In-Reply-To: <20061019110422.5ff37f9f.bugs.michael@gmx.net> References: <20061019110422.5ff37f9f.bugs.michael@gmx.net> Message-ID: <200610190927.51555.jkeating@redhat.com> On Thursday 19 October 2006 05:04, Michael Schwendt wrote: > Do we want to permit packages in Fedora Extras, which install and enable > by default a 3rd party repository? Please no. They could end up turning on a repo that points to a place that has !legal software, and now Extras+Fedora is in trouble for contributory infringement. So, no. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Thu Oct 19 15:42:06 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 19 Oct 2006 18:42:06 +0300 Subject: [Fedora-packaging] Extras package enables 3rd party repository In-Reply-To: <45377AC2.1090806@math.unl.edu> References: <20061019110422.5ff37f9f.bugs.michael@gmx.net> <45377AC2.1090806@math.unl.edu> Message-ID: <1161272526.3203.34.camel@viper.local> On Thu, 2006-10-19 at 08:16 -0500, Rex Dieter wrote: > Michael Schwendt wrote: > > Do we want to permit packages in Fedora Extras, which install and enable > > by default a 3rd party repository? > > Absolutely not(*). Seconded. From fedora at leemhuis.info Thu Oct 19 16:21:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 19 Oct 2006 18:21:32 +0200 Subject: [Fedora-packaging] Re: [Bug 203864] Review Request: tripwire - IDS In-Reply-To: <200610191508.k9JF8qLs021256@bugzilla.redhat.com> References: <200610191508.k9JF8qLs021256@bugzilla.redhat.com> Message-ID: <4537A60C.1060504@leemhuis.info> Hi! I justed noticed this: bugzilla at redhat.com schrieb: > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug report. > Summary: Review Request: tripwire - IDS > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203864 > > ------- Additional Comments From zing at fastmail.fm 2006-10-19 11:08 EST ------- > please don't spam the rpm installation with a cat of the README.RPM file. > > I'd say a note in the %description pointing the user to the /path/to/README.RPM > is a fine place for that. > > At most, _maybe_ a one line echo of the /path/to/README.RPM... and even that > doesn't really sit to well with me... I strongly agree with the last sentence. Should we write it somewhere into the policies that %pre/%post script should never print stuff? Cu thl From fedora at leemhuis.info Thu Oct 19 16:26:33 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 19 Oct 2006 18:26:33 +0200 Subject: [Fedora-packaging] Extras package enables 3rd party repository In-Reply-To: <1161272526.3203.34.camel@viper.local> References: <20061019110422.5ff37f9f.bugs.michael@gmx.net> <45377AC2.1090806@math.unl.edu> <1161272526.3203.34.camel@viper.local> Message-ID: <4537A739.4050101@leemhuis.info> FESCo-Members: Start of thread was https://www.redhat.com/archives/fedora-packaging/2006-October/msg00132.html Ville Skytt? schrieb: > On Thu, 2006-10-19 at 08:16 -0500, Rex Dieter wrote: >> Michael Schwendt wrote: >>> Do we want to permit packages in Fedora Extras, which install and enable >>> by default a 3rd party repository? >> Absolutely not(*). > Seconded. +1 Should we simply remove the package in question as quickly as possible? CU thl From notting at redhat.com Thu Oct 19 16:37:06 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 19 Oct 2006 12:37:06 -0400 Subject: [Fedora-packaging] Extras package enables 3rd party repository In-Reply-To: <1161272526.3203.34.camel@viper.local> References: <20061019110422.5ff37f9f.bugs.michael@gmx.net> <45377AC2.1090806@math.unl.edu> <1161272526.3203.34.camel@viper.local> Message-ID: <20061019163706.GB22273@nostromo.devel.redhat.com> Ville Skytt? (ville.skytta at iki.fi) said: > On Thu, 2006-10-19 at 08:16 -0500, Rex Dieter wrote: > > Michael Schwendt wrote: > > > Do we want to permit packages in Fedora Extras, which install and enable > > > by default a 3rd party repository? > > > > Absolutely not(*). > > Seconded. Not a member of FESCO here, but, 'thirded'. This could even lead to the possibility of legal issues... Bill From notting at redhat.com Thu Oct 19 16:38:25 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 19 Oct 2006 12:38:25 -0400 Subject: [Fedora-packaging] Re: [Bug 203864] Review Request: tripwire - IDS In-Reply-To: <4537A60C.1060504@leemhuis.info> References: <200610191508.k9JF8qLs021256@bugzilla.redhat.com> <4537A60C.1060504@leemhuis.info> Message-ID: <20061019163825.GD22273@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > I strongly agree with the last sentence. Should we write it somewhere > into the policies that %pre/%post script should never print stuff? Honestly, I thought it was already part of the policies. %pre/%post can not be interactive. Bill From rdieter at math.unl.edu Thu Oct 19 16:41:39 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 19 Oct 2006 11:41:39 -0500 Subject: [Fedora-packaging] Extras package enables 3rd party repository In-Reply-To: <4537A739.4050101@leemhuis.info> References: <20061019110422.5ff37f9f.bugs.michael@gmx.net> <45377AC2.1090806@math.unl.edu> <1161272526.3203.34.camel@viper.local> <4537A739.4050101@leemhuis.info> Message-ID: <4537AAC3.3070600@math.unl.edu> Thorsten Leemhuis wrote: > FESCo-Members: Start of thread was > https://www.redhat.com/archives/fedora-packaging/2006-October/msg00132.html > > Ville Skytt? schrieb: >> On Thu, 2006-10-19 at 08:16 -0500, Rex Dieter wrote: >>> Michael Schwendt wrote: >>>> Do we want to permit packages in Fedora Extras, which install and enable >>>> by default a 3rd party repository? >>> Absolutely not(*). >> Seconded. > > +1 > > Should we simply remove the package in question as quickly as possible? yes, +1. -- Rex From jeff at ocjtech.us Thu Oct 19 16:38:10 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 19 Oct 2006 11:38:10 -0500 Subject: [Fedora-packaging] Re: [Bug 203864] Review Request: tripwire - IDS In-Reply-To: <4537A60C.1060504@leemhuis.info> References: <200610191508.k9JF8qLs021256@bugzilla.redhat.com> <4537A60C.1060504@leemhuis.info> Message-ID: <1161275890.2945.11.camel@lt21223.campus.dmacc.edu.> On Thu, 2006-10-19 at 18:21 +0200, Thorsten Leemhuis wrote: > Should we write it somewhere > into the policies that %pre/%post script should never print stuff? Except for error messages... Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Thu Oct 19 19:27:16 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 19 Oct 2006 14:27:16 -0500 Subject: [Fedora-packaging] Re: [Bug 203864] Review Request: tripwire - IDS In-Reply-To: <20061019163825.GD22273@nostromo.devel.redhat.com> (Bill Nottingham's message of "Thu, 19 Oct 2006 12:38:25 -0400") References: <200610191508.k9JF8qLs021256@bugzilla.redhat.com> <4537A60C.1060504@leemhuis.info> <20061019163825.GD22273@nostromo.devel.redhat.com> Message-ID: >>>>> "BN" == Bill Nottingham writes: BN> Honestly, I thought it was already part of the BN> policies. %pre/%post can not be interactive. I thought "interactive" meant "accepting or expecting input". I'm not sure that simple display of text is also forbidden. - J< From bugs.michael at gmx.net Thu Oct 19 19:47:51 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 19 Oct 2006 21:47:51 +0200 Subject: [Fedora-packaging] Re: [Bug 203864] Review Request: tripwire - IDS In-Reply-To: References: <200610191508.k9JF8qLs021256@bugzilla.redhat.com> <4537A60C.1060504@leemhuis.info> <20061019163825.GD22273@nostromo.devel.redhat.com> Message-ID: <20061019214751.49273d22.bugs.michael@gmx.net> On Thu, 19 Oct 2006 14:27:16 -0500, Jason L Tibbitts III wrote: > >>>>> "BN" == Bill Nottingham writes: > > BN> Honestly, I thought it was already part of the > BN> policies. %pre/%post can not be interactive. > > I thought "interactive" meant "accepting or expecting input". I'm not > sure that simple display of text is also forbidden. Then let's make it "scriptlets can neither be interactive nor informative". You cannot expect GUI tools to capture stdout/stderr output and display it during or after installation/upgrade/removal of a package. In other words, output is lost (if not logged in any place, which would be non-obvious). Trying to give post-install instructions to a user via scriptlets is bad habit. Should happen in README %doc files instead. From opensource at till.name Thu Oct 19 20:25:16 2006 From: opensource at till.name (Till Maas) Date: Thu, 19 Oct 2006 22:25:16 +0200 Subject: [Fedora-packaging] Re: [Bug 203864] Review Request: tripwire - IDS In-Reply-To: <20061019214751.49273d22.bugs.michael@gmx.net> References: <200610191508.k9JF8qLs021256@bugzilla.redhat.com> <20061019214751.49273d22.bugs.michael@gmx.net> Message-ID: <200610192225.17837.opensource@till.name> Aloas, On Thursday 19 October 2006 21:47, Michael Schwendt wrote: > Trying to give post-install instructions to a user via scriptlets is bad > habit. Should happen in README %doc files instead. I want to propose to send post-install instrutions via mail to the root user additionally, this way one needs not to look into the documentation for every installed package but gets every information collected in his inbox. Regards, Till From bugs.michael at gmx.net Thu Oct 19 21:40:20 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 19 Oct 2006 23:40:20 +0200 Subject: [Fedora-packaging] Disabling debuginfo packages Message-ID: <20061019234020.ad2f5142.bugs.michael@gmx.net> I'd like to request the following packaging policy: [...] If a packager uses something with the same effect than %define debug_package %{nil} which disables the automatically built "debuginfo" package, the spec file MUST contain a comment that explains why this is done. From tcallawa at redhat.com Thu Oct 19 22:12:57 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 19 Oct 2006 17:12:57 -0500 Subject: [Fedora-packaging] Disabling debuginfo packages In-Reply-To: <20061019234020.ad2f5142.bugs.michael@gmx.net> References: <20061019234020.ad2f5142.bugs.michael@gmx.net> Message-ID: <1161295977.2909.95.camel@localhost.localdomain> On Thu, 2006-10-19 at 23:40 +0200, Michael Schwendt wrote: > I'd like to request the following packaging policy: > > [...] > > If a packager uses something with the same effect than > > %define debug_package %{nil} > > which disables the automatically built "debuginfo" package, the spec file > MUST contain a comment that explains why this is done. +1 ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From chris.stone at gmail.com Thu Oct 19 22:16:41 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 19 Oct 2006 15:16:41 -0700 Subject: [Fedora-packaging] Disabling debuginfo packages In-Reply-To: <20061019234020.ad2f5142.bugs.michael@gmx.net> References: <20061019234020.ad2f5142.bugs.michael@gmx.net> Message-ID: On 10/19/06, Michael Schwendt wrote: > I'd like to request the following packaging policy: > > [...] > > If a packager uses something with the same effect than > > %define debug_package %{nil} > > which disables the automatically built "debuginfo" package, the spec file > MUST contain a comment that explains why this is done. This goes without saying. Infact why be so specific? The rule should be that if anything is done that is out of the ordinary a comment must be added that explains why. From Axel.Thimm at ATrpms.net Thu Oct 19 23:38:43 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 20 Oct 2006 01:38:43 +0200 Subject: [Fedora-packaging] Re: [Bug 203864] Review Request: tripwire - IDS In-Reply-To: <20061019163825.GD22273@nostromo.devel.redhat.com> References: <200610191508.k9JF8qLs021256@bugzilla.redhat.com> <4537A60C.1060504@leemhuis.info> <20061019163825.GD22273@nostromo.devel.redhat.com> Message-ID: <20061019233843.GA32266@neu.nirvana> On Thu, Oct 19, 2006 at 12:38:25PM -0400, Bill Nottingham wrote: > Thorsten Leemhuis (fedora at leemhuis.info) said: > > I strongly agree with the last sentence. Should we write it somewhere > > into the policies that %pre/%post script should never print stuff? Yes. But that means filing a bug against glibc for visibly restarting ssh for example. > Honestly, I thought it was already part of the policies. %pre/%post > can not be interactive. I think this is already strongly deprecated at the pure rpm level. We could add a note on this in the guide, but it shouldn't suggest we really ever had another choice. :) Just as a side note: It's been a debate for several years now that dpkg allows licenses to be displayed in non-batch mode, and that rpm only has batch mode and thus no means for licenses to be displayed. Not that it's actually a drawback. In general most higher level rpm tool assume output on stderr/stdout from rpm packages to be an error and present it that way. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Thu Oct 19 23:43:13 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 19 Oct 2006 19:43:13 -0400 Subject: [Fedora-packaging] Re: [Bug 203864] Review Request: tripwire - IDS In-Reply-To: <20061019233843.GA32266@neu.nirvana> References: <200610191508.k9JF8qLs021256@bugzilla.redhat.com> <4537A60C.1060504@leemhuis.info> <20061019163825.GD22273@nostromo.devel.redhat.com> <20061019233843.GA32266@neu.nirvana> Message-ID: <1161301393.10399.0.camel@cutter> On Fri, 2006-10-20 at 01:38 +0200, Axel Thimm wrote: > On Thu, Oct 19, 2006 at 12:38:25PM -0400, Bill Nottingham wrote: > > Thorsten Leemhuis (fedora at leemhuis.info) said: > > > I strongly agree with the last sentence. Should we write it somewhere > > > into the policies that %pre/%post script should never print stuff? > > Yes. But that means filing a bug against glibc for visibly restarting > ssh for example. > > > Honestly, I thought it was already part of the policies. %pre/%post > > can not be interactive. > > I think this is already strongly deprecated at the pure rpm level. We > could add a note on this in the guide, but it shouldn't suggest we > really ever had another choice. :) > > Just as a side note: It's been a debate for several years now that > dpkg allows licenses to be displayed in non-batch mode, and that rpm > only has batch mode and thus no means for licenses to be > displayed. Not that it's actually a drawback. > > In general most higher level rpm tool assume output on stderr/stdout > from rpm packages to be an error and present it that way. only b/c we have no other choice. If we could get rpm to be silent and have all of the messages (stderr or stdout) be presented back to us as part of the callback I think most of us would be quite happy. If only b/c it would mean we would then have the option of echoing it back to the user, saving it to a log or both. -sv From a.badger at gmail.com Fri Oct 20 01:18:42 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 19 Oct 2006 18:18:42 -0700 Subject: [Fedora-packaging] Re: [Bug 203864] Review Request: tripwire - IDS In-Reply-To: <200610192225.17837.opensource@till.name> References: <200610191508.k9JF8qLs021256@bugzilla.redhat.com> <20061019214751.49273d22.bugs.michael@gmx.net> <200610192225.17837.opensource@till.name> Message-ID: <1161307122.2930.7.camel@localhost> On Thu, 2006-10-19 at 22:25 +0200, Till Maas wrote: > Aloas, > > On Thursday 19 October 2006 21:47, Michael Schwendt wrote: > > > Trying to give post-install instructions to a user via scriptlets is bad > > habit. Should happen in README %doc files instead. > > I want to propose to send post-install instrutions via mail to the root user > additionally, this way one needs not to look into the documentation for every > installed package but gets every information collected in his inbox. Bad idea. I have 2176 packages installed so potentially, I'd have 2176 emails awaiting me when I install a fresh box. Once enough packages start doing this, I won't be wading through my INBOX to find the information.... $ rpm -ql foo $ less /usr/share/doc/foo-1.0/README would still be my method of finding documentation. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Oct 20 08:56:36 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 20 Oct 2006 10:56:36 +0200 Subject: [Fedora-packaging] Re: [Bug 203864] Review Request: tripwire - IDS In-Reply-To: <1161301393.10399.0.camel@cutter> References: <200610191508.k9JF8qLs021256@bugzilla.redhat.com> <4537A60C.1060504@leemhuis.info> <20061019163825.GD22273@nostromo.devel.redhat.com> <20061019233843.GA32266@neu.nirvana> <1161301393.10399.0.camel@cutter> Message-ID: <20061020105636.79c55e8b@python3.es.egwn.lan> seth vidal wrote : > If we could get rpm to be silent and have all of the messages (stderr or > stdout) be presented back to us as part of the callback I think most of > us would be quite happy. If only b/c it would mean we would then have > the option of echoing it back to the user, saving it to a log or both. I couldn't agree more. I find it plain silly to almost always have to execute "foo args &>/dev/null || :" in scriplets, when getting the output of the command as well as knowing if it actually failed or succeeded can be interesting information. If we could have a log file of rpm operations output, it would be really great. *BUT* this does mean breaking backwards compatibility in many cases (i.e. having failing scriplets leave duplicate packages in the rpmdb). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2759.fc6 Load : 0.36 0.51 0.37 From bugs.michael at gmx.net Fri Oct 20 11:37:07 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 20 Oct 2006 13:37:07 +0200 Subject: [Fedora-packaging] Disabling debuginfo packages In-Reply-To: References: <20061019234020.ad2f5142.bugs.michael@gmx.net> Message-ID: <20061020133707.e13ab4fa.bugs.michael@gmx.net> On Thu, 19 Oct 2006 15:16:41 -0700, Christopher Stone wrote: > > I'd like to request the following packaging policy: > > > > [...] > > > > If a packager uses something with the same effect than > > > > %define debug_package %{nil} > > > > which disables the automatically built "debuginfo" package, the spec file > > MUST contain a comment that explains why this is done. > > This goes without saying. Infact why be so specific? The rule should > be that if anything is done that is out of the ordinary a comment must > be added that explains why. What is "anything that is out of the ordinary"? Where does it start? Where does it stop? You could call some BuildRequires "out of the ordinary", too, but a packager might consider them as ordinary. Some things in spec files must be enforced in order to sharpen the package maintainer's sense for adding explanatory comments. We want debuginfo packages where possible. And where they are disabled, we want to learn about the reason. From chris.stone at gmail.com Fri Oct 20 18:07:23 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 20 Oct 2006 11:07:23 -0700 Subject: [Fedora-packaging] Disabling debuginfo packages In-Reply-To: <20061020133707.e13ab4fa.bugs.michael@gmx.net> References: <20061019234020.ad2f5142.bugs.michael@gmx.net> <20061020133707.e13ab4fa.bugs.michael@gmx.net> Message-ID: On 10/20/06, Michael Schwendt wrote: > On Thu, 19 Oct 2006 15:16:41 -0700, Christopher Stone wrote: > > > > I'd like to request the following packaging policy: > > > > > > [...] > > > > > > If a packager uses something with the same effect than > > > > > > %define debug_package %{nil} > > > > > > which disables the automatically built "debuginfo" package, the spec file > > > MUST contain a comment that explains why this is done. > > > > This goes without saying. Infact why be so specific? The rule should > > be that if anything is done that is out of the ordinary a comment must > > be added that explains why. > > What is "anything that is out of the ordinary"? Where does it start? > Where does it stop? You could call some BuildRequires "out of the > ordinary", too, but a packager might consider them as ordinary. It's very simple. You use your own judgement. When in doubt, add a comment. If there is ever any disagreement between packager and reviewer, the default is to add a comment. From bugs.michael at gmx.net Fri Oct 20 19:01:41 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 20 Oct 2006 21:01:41 +0200 Subject: [Fedora-packaging] Disabling debuginfo packages In-Reply-To: References: <20061019234020.ad2f5142.bugs.michael@gmx.net> <20061020133707.e13ab4fa.bugs.michael@gmx.net> Message-ID: <20061020210141.8112e422.bugs.michael@gmx.net> On Fri, 20 Oct 2006 11:07:23 -0700, Christopher Stone wrote: > > On Thu, 19 Oct 2006 15:16:41 -0700, Christopher Stone wrote: > > > > > > I'd like to request the following packaging policy: > > > > > > > > [...] > > > > > > > > If a packager uses something with the same effect than > > > > > > > > %define debug_package %{nil} > > > > > > > > which disables the automatically built "debuginfo" package, the spec file > > > > MUST contain a comment that explains why this is done. > > > > > > This goes without saying. Infact why be so specific? The rule should > > > be that if anything is done that is out of the ordinary a comment must > > > be added that explains why. > > > > What is "anything that is out of the ordinary"? Where does it start? > > Where does it stop? You could call some BuildRequires "out of the > > ordinary", too, but a packager might consider them as ordinary. > > It's very simple. You use your own judgement. When in doubt, add a > comment. If there is ever any disagreement between packager and > reviewer, the default is to add a comment. ??? Then something in our process is broken, because there are spec files used in Extras where debuginfo packages are disabled _without_ a comment. Further, we don't apply any formal post-approval reviewing (or QA), so policies (or guidelines) for the post-approval life-time of a package are needed. These are the same than during review, at least. But they don't cover debuginfo packages yet. I'm talking about _enforcing_ an explanatory comment in the spec file. From chris.stone at gmail.com Fri Oct 20 19:04:13 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 20 Oct 2006 12:04:13 -0700 Subject: [Fedora-packaging] Disabling debuginfo packages In-Reply-To: <20061020210141.8112e422.bugs.michael@gmx.net> References: <20061019234020.ad2f5142.bugs.michael@gmx.net> <20061020133707.e13ab4fa.bugs.michael@gmx.net> <20061020210141.8112e422.bugs.michael@gmx.net> Message-ID: > I'm talking about _enforcing_ an explanatory comment in the spec file. Having specific enforcements for comments is a bad idea in my opinion. If you see a package and think it needs a comment, you should just be able to go in and add the comment to the spec file yourself, no questions asked. As long as you use good judgement, I don't see any problem with allowing people to do this. If a reviewer is being over-zealous of comment use such as "# use three spaces after Requries:" then this person's judgement can be called into question here. From bugs.michael at gmx.net Fri Oct 20 21:00:36 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 20 Oct 2006 23:00:36 +0200 Subject: [Fedora-packaging] Disabling debuginfo packages In-Reply-To: References: <20061019234020.ad2f5142.bugs.michael@gmx.net> <20061020133707.e13ab4fa.bugs.michael@gmx.net> <20061020210141.8112e422.bugs.michael@gmx.net> Message-ID: <20061020230036.9a3fd4c9.bugs.michael@gmx.net> On Fri, 20 Oct 2006 12:04:13 -0700, Christopher Stone wrote: > > I'm talking about _enforcing_ an explanatory comment in the spec file. > > Having specific enforcements for comments is a bad idea in my opinion. > > If you see a package and think it needs a comment, you should just be > able to go in and add the comment to the spec file yourself, no > questions asked. > > As long as you use good judgement, I don't see any problem with > allowing people to do this. If a reviewer is being over-zealous of > comment use such as "# use three spaces after Requries:" then this > person's judgement can be called into question here. How about we delete our ReviewGuidelines Wiki page and substitute the entire review process with a single guideline? * Use good judgement. And then we apply additional judgement when the package enters CVS. Okay, this thread has found an end for me. From chris.stone at gmail.com Fri Oct 20 21:02:18 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 20 Oct 2006 14:02:18 -0700 Subject: [Fedora-packaging] Disabling debuginfo packages In-Reply-To: <20061020230036.9a3fd4c9.bugs.michael@gmx.net> References: <20061019234020.ad2f5142.bugs.michael@gmx.net> <20061020133707.e13ab4fa.bugs.michael@gmx.net> <20061020210141.8112e422.bugs.michael@gmx.net> <20061020230036.9a3fd4c9.bugs.michael@gmx.net> Message-ID: On 10/20/06, Michael Schwendt wrote: > On Fri, 20 Oct 2006 12:04:13 -0700, Christopher Stone wrote: > > > > I'm talking about _enforcing_ an explanatory comment in the spec file. > > > > Having specific enforcements for comments is a bad idea in my opinion. > > > > If you see a package and think it needs a comment, you should just be > > able to go in and add the comment to the spec file yourself, no > > questions asked. > > > > As long as you use good judgement, I don't see any problem with > > allowing people to do this. If a reviewer is being over-zealous of > > comment use such as "# use three spaces after Requries:" then this > > person's judgement can be called into question here. > > How about we delete our ReviewGuidelines Wiki page and substitute > the entire review process with a single guideline? > > * Use good judgement. I think this is a very bad idea. There is a difference between benign aspects of a spec file such as comments, and aspects that actually affect the outcome of the RPM. Ofcourse *adding* a line to the guidelines that says you should try to use good judgement when something is in question I would encourage. From Axel.Thimm at ATrpms.net Sat Oct 21 02:14:51 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 21 Oct 2006 04:14:51 +0200 Subject: [Fedora-packaging] Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <80d7e4090610191332w6b18e732q32cad66c453a6268@mail.gmail.com> References: <4537BABE.2010602@semitekie.com> <80d7e4090610191332w6b18e732q32cad66c453a6268@mail.gmail.com> Message-ID: <20061021021451.GS32266@neu.nirvana> On Thu, Oct 19, 2006 at 02:32:20PM -0600, Stephen John Smoogen wrote: > On 10/19/06, J French wrote: > >Just wondering if there's any intention of moving the default locations > >for Apache's webroot and database files (MySQl, Postgres, et al) to /srv > >where they belong. > > > > Well it could be possible, but the /srv section is left up to the > individual site to dictate layout and not the vendor (if I read the > FHS correctly. That's correct. Furthermore the FHS supports different hierarchies below /srv depending on the site's needs. For example a server hosting project1.org and project2.org would use /srv/project1.org/www and /srv/project2.org/www So /srv should be kept free of any package bits. I'm copying the packaging list, perhaps it's worth noting in the guide. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Sat Oct 21 10:42:53 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 21 Oct 2006 12:42:53 +0200 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <20061021021451.GS32266@neu.nirvana> References: <4537BABE.2010602@semitekie.com> <80d7e4090610191332w6b18e732q32cad66c453a6268@mail.gmail.com> <20061021021451.GS32266@neu.nirvana> Message-ID: <1161427373.14692.2.camel@rousalka.dyndns.org> Le samedi 21 octobre 2006 ? 04:14 +0200, Axel Thimm a ?crit : > That's correct. Furthermore the FHS supports different hierarchies > below /srv depending on the site's needs. For example a server hosting > project1.org and project2.org would use > > /srv/project1.org/www and > /srv/project2.org/www > > So /srv should be kept free of any package bits. I'm copying the > packaging list, perhaps it's worth noting in the guide. The FHS like many things does not specify a particular policy. This should not stop Fedora from defining one. Much better to have a consistent well-though distro policy rather than free-for-all packager mess -- Nicolas Mailhot From mattdm at mattdm.org Sat Oct 21 10:58:19 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 21 Oct 2006 06:58:19 -0400 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <20061021021451.GS32266@neu.nirvana> References: <4537BABE.2010602@semitekie.com> <80d7e4090610191332w6b18e732q32cad66c453a6268@mail.gmail.com> <20061021021451.GS32266@neu.nirvana> Message-ID: <20061021105819.GA27435@jadzia.bu.edu> On Sat, Oct 21, 2006 at 04:14:51AM +0200, Axel Thimm wrote: > That's correct. Furthermore the FHS supports different hierarchies > below /srv depending on the site's needs. For example a server hosting > project1.org and project2.org would use > /srv/project1.org/www and > /srv/project2.org/www > So /srv should be kept free of any package bits. I'm copying the > packaging list, perhaps it's worth noting in the guide. As noted in the bug, I think that default, package-managed files should be packaged into /usr/share/somewhere, but /srv/www (or /srv/www/something/) should be the default (empty, except maybe a README) document directory. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From Axel.Thimm at ATrpms.net Sat Oct 21 11:00:14 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 21 Oct 2006 13:00:14 +0200 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <1161427373.14692.2.camel@rousalka.dyndns.org> References: <4537BABE.2010602@semitekie.com> <80d7e4090610191332w6b18e732q32cad66c453a6268@mail.gmail.com> <20061021021451.GS32266@neu.nirvana> <1161427373.14692.2.camel@rousalka.dyndns.org> Message-ID: <20061021110014.GE14307@neu.nirvana> On Sat, Oct 21, 2006 at 12:42:53PM +0200, Nicolas Mailhot wrote: > Le samedi 21 octobre 2006 ? 04:14 +0200, Axel Thimm a ?crit : > > > That's correct. Furthermore the FHS supports different hierarchies > > below /srv depending on the site's needs. For example a server hosting > > project1.org and project2.org would use > > > > /srv/project1.org/www and > > /srv/project2.org/www > > > > So /srv should be kept free of any package bits. I'm copying the > > packaging list, perhaps it's worth noting in the guide. > > The FHS like many things does not specify a particular policy. This > should not stop Fedora from defining one. Much better to have a > consistent well-though distro policy rather than free-for-all packager > mess Well-tought IMHO means not to impose any of the possible policies onto the user since different scenarios require different methodologies. So Fedora as a general purpose distibution should not freeze any degrees of freedom here. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Oct 21 11:06:31 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 21 Oct 2006 13:06:31 +0200 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <20061021105819.GA27435@jadzia.bu.edu> References: <4537BABE.2010602@semitekie.com> <80d7e4090610191332w6b18e732q32cad66c453a6268@mail.gmail.com> <20061021021451.GS32266@neu.nirvana> <20061021105819.GA27435@jadzia.bu.edu> Message-ID: <20061021110631.GF14307@neu.nirvana> On Sat, Oct 21, 2006 at 06:58:19AM -0400, Matthew Miller wrote: > On Sat, Oct 21, 2006 at 04:14:51AM +0200, Axel Thimm wrote: > > That's correct. Furthermore the FHS supports different hierarchies > > below /srv depending on the site's needs. For example a server hosting > > project1.org and project2.org would use > > /srv/project1.org/www and > > /srv/project2.org/www > > So /srv should be kept free of any package bits. I'm copying the > > packaging list, perhaps it's worth noting in the guide. > > As noted in the bug, I think that default, package-managed files should be > packaged into /usr/share/somewhere, I agree. > but /srv/www (or /srv/www/something/) should be the default (empty, > except maybe a README) document directory. No, /srv should exist, but otherwise be empty from the vendor's POV (e.g. no package should own/place anything beneath /srv). We should neither impose /srv/, nor /srv//, nor /srv// methods. These are really very specific to the solution needed and prefering any of these will make the other users unhappy, and in this case all three mentioned solution have probably the same or very comparable share of users. Instead provide anything, as you write, under /usr/share, as a template to be copied by the user somewhere under /srv according to his needs (or some similar mechanism). A copy-to-somewhere script could be rpovided, too. For example fedora-install-mediawiki or fedora-install-bugzilla to name two projects that are often used in several incarnations on one system. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Sat Oct 21 11:29:02 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 21 Oct 2006 13:29:02 +0200 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <20061021110631.GF14307@neu.nirvana> References: <4537BABE.2010602@semitekie.com> <80d7e4090610191332w6b18e732q32cad66c453a6268@mail.gmail.com> <20061021021451.GS32266@neu.nirvana> <20061021105819.GA27435@jadzia.bu.edu> <20061021110631.GF14307@neu.nirvana> Message-ID: <1161430142.14692.17.camel@rousalka.dyndns.org> Le samedi 21 octobre 2006 ? 13:06 +0200, Axel Thimm a ?crit : > On Sat, Oct 21, 2006 at 06:58:19AM -0400, Matthew Miller wrote: > > On Sat, Oct 21, 2006 at 04:14:51AM +0200, Axel Thimm wrote: > > > That's correct. Furthermore the FHS supports different hierarchies > > > below /srv depending on the site's needs. For example a server hosting > > > project1.org and project2.org would use > > > /srv/project1.org/www and > > > /srv/project2.org/www > > > So /srv should be kept free of any package bits. I'm copying the > > > packaging list, perhaps it's worth noting in the guide. > > > > As noted in the bug, I think that default, package-managed files should be > > packaged into /usr/share/somewhere, > > I agree. > > > but /srv/www (or /srv/www/something/) should be the default (empty, > > except maybe a README) document directory. > > No, /srv should exist, but otherwise be empty from the vendor's POV > (e.g. no package should own/place anything beneath /srv). We package TFTP, FTP, SMB, CIFS, DAV servers... They all need a default root in their config file. The FHS makes it abundantly clear this root must be somewhere in /srv. We can't refuse to choose a default because: 1. most users want us to choose a default so things "just work" 2. it's not a mere matter of writing a string in a config file: when several apps use the same resource you need to coordinate them, it has security and selinux impacts, etc 3. increasing variability only hurts documentation. If we don't decide people will make random choices in howtos that will be blindly followed because most people don't care and don't want to choose themselves You could make the very same argument for package naming - since there is no standard and any choice will always be suboptimal in some cases why even attempt to write Fedora Naming Guidelines? Well we wrote the damn guidelines and they're bloody useful. We don't have the freedom of the FHS to refuse to make contentious choices. We're responsible for an actual system. That requires making operational decisions. (And BTW we have historically made these decisions, only we chose roots in parts of the filesystem the FHS declared wrong, so maintaining the status-quo won't make us any more FHS compliant quite the contrary) -- Nicolas Mailhot From Axel.Thimm at ATrpms.net Sat Oct 21 13:43:03 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 21 Oct 2006 15:43:03 +0200 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <1161430142.14692.17.camel@rousalka.dyndns.org> References: <4537BABE.2010602@semitekie.com> <80d7e4090610191332w6b18e732q32cad66c453a6268@mail.gmail.com> <20061021021451.GS32266@neu.nirvana> <20061021105819.GA27435@jadzia.bu.edu> <20061021110631.GF14307@neu.nirvana> <1161430142.14692.17.camel@rousalka.dyndns.org> Message-ID: <20061021134303.GA3148@neu.nirvana> On Sat, Oct 21, 2006 at 01:29:02PM +0200, Nicolas Mailhot wrote: > Le samedi 21 octobre 2006 ? 13:06 +0200, Axel Thimm a ?crit : > > On Sat, Oct 21, 2006 at 06:58:19AM -0400, Matthew Miller wrote: > > > On Sat, Oct 21, 2006 at 04:14:51AM +0200, Axel Thimm wrote: > > > > That's correct. Furthermore the FHS supports different hierarchies > > > > below /srv depending on the site's needs. For example a server hosting > > > > project1.org and project2.org would use > > > > /srv/project1.org/www and > > > > /srv/project2.org/www > > > > So /srv should be kept free of any package bits. I'm copying the > > > > packaging list, perhaps it's worth noting in the guide. > > > > > > As noted in the bug, I think that default, package-managed files should be > > > packaged into /usr/share/somewhere, > > > > I agree. > > > > > but /srv/www (or /srv/www/something/) should be the default (empty, > > > except maybe a README) document directory. > > > > No, /srv should exist, but otherwise be empty from the vendor's POV > > (e.g. no package should own/place anything beneath /srv). > > We package TFTP, FTP, SMB, CIFS, DAV servers... > They all need a default root in their config file. There is no root for smb/cifs/nfs. The number of services that really require a root to be able to do something at all are quite limited. > The FHS makes it abundantly clear this root must be somewhere in /srv. Like for imap and nis where the FHS contradicts with itself on this point? I don't think we should interprete the FHS that we are to hardwire stuff into /srv forcing users to abandon their favourite methology. That would lead to admins quitting Fedora due to not being able to use it for their purposes. Or they would ignore /srv and create a new /srv2. Both of which are not what we'd like to happen. Let's try to find a compromise: Would a special subfolder of /srv like /srv/default/{www,ftp,...} make you and me happy? It would have the least impact on user chosen metholodgy [1] and all services could move to there. Deal? BTW the FHS is currently being revised, if we'd like to make a suggestion (for example a special subfolder under /srv designated to be vendor owned) we should hurry up. [1] Unless s/o have a domain called "default", /srv/default is just a suggestion of the top of my head, there may be better ones. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Sat Oct 21 17:32:42 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 21 Oct 2006 13:32:42 -0400 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <20061021110631.GF14307@neu.nirvana> References: <4537BABE.2010602@semitekie.com> <80d7e4090610191332w6b18e732q32cad66c453a6268@mail.gmail.com> <20061021021451.GS32266@neu.nirvana> <20061021105819.GA27435@jadzia.bu.edu> <20061021110631.GF14307@neu.nirvana> Message-ID: <20061021173242.GA7131@jadzia.bu.edu> On Sat, Oct 21, 2006 at 01:06:31PM +0200, Axel Thimm wrote: > No, /srv should exist, but otherwise be empty from the vendor's POV > (e.g. no package should own/place anything beneath /srv). We should > neither impose /srv/, nor /srv//, nor > /srv// methods. These are really very specific to the > solution needed and prefering any of these will make the other users > unhappy, and in this case all three mentioned solution have probably > the same or very comparable share of users. I see it as analogous to /usr/local -- that's the local admin's domain, but Fedora *does* populate it with some typical subdirectories. I don't think it's at all unreasonable to ship with the default document root at /srv/www, which would be empty by default. If you make anything else the document root, many people are just going to edit stuff *there*. Anyone who wants a different arrangement than the default can edit the document root in httpd.conf, no problem, but there'd be a sensible and standard default already. From the FHS: Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv. However /srv should always exist on FHS compliant systems and should be used as the default location for such data. What I'm suggesting covers both parts of this, not just the first. > A copy-to-somewhere script could be rpovided, too. For example > fedora-install-mediawiki or fedora-install-bugzilla to > name two projects that are often used in several incarnations on one > system. For some reason, this doesn't really feel right to me. Nothing else works like this.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ville.skytta at iki.fi Sun Oct 22 19:01:57 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 22 Oct 2006 22:01:57 +0300 Subject: [Fedora-packaging] Disabling debuginfo packages In-Reply-To: <20061019234020.ad2f5142.bugs.michael@gmx.net> References: <20061019234020.ad2f5142.bugs.michael@gmx.net> Message-ID: <1161543717.3527.14.camel@viper.local> On Thu, 2006-10-19 at 23:40 +0200, Michael Schwendt wrote: > I'd like to request the following packaging policy: > > [...] > > If a packager uses something with the same effect than > > %define debug_package %{nil} > > which disables the automatically built "debuginfo" package, the spec file > MUST contain a comment that explains why this is done. +1 From jorton at redhat.com Mon Oct 23 16:11:57 2006 From: jorton at redhat.com (Joe Orton) Date: Mon, 23 Oct 2006 17:11:57 +0100 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <20061021110631.GF14307@neu.nirvana> References: <4537BABE.2010602@semitekie.com> <80d7e4090610191332w6b18e732q32cad66c453a6268@mail.gmail.com> <20061021021451.GS32266@neu.nirvana> <20061021105819.GA27435@jadzia.bu.edu> <20061021110631.GF14307@neu.nirvana> Message-ID: <20061023161157.GA18288@redhat.com> On Sat, Oct 21, 2006 at 01:06:31PM +0200, Axel Thimm wrote: > No, /srv should exist, but otherwise be empty from the vendor's POV > (e.g. no package should own/place anything beneath /srv). We should > neither impose /srv/, nor /srv//, nor > /srv// methods. I completely agree with this. The FHS policy for /srv is explicitly worded to have no policy for /srv, so we cannot use it as packagers. FHS says both that we must not impose any particular directory structure within /srv, and that we must use /srv as the "default location" for storing data used by services. The only way to satisfy that would be to do the equivalent of "DocumentRoot /srv" for every service, which would be simply stupid. joe From mattdm at mattdm.org Mon Oct 23 16:27:06 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 23 Oct 2006 12:27:06 -0400 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <20061023161157.GA18288@redhat.com> References: <4537BABE.2010602@semitekie.com> <80d7e4090610191332w6b18e732q32cad66c453a6268@mail.gmail.com> <20061021021451.GS32266@neu.nirvana> <20061021105819.GA27435@jadzia.bu.edu> <20061021110631.GF14307@neu.nirvana> <20061023161157.GA18288@redhat.com> Message-ID: <20061023162706.GA12971@jadzia.bu.edu> On Mon, Oct 23, 2006 at 05:11:57PM +0100, Joe Orton wrote: > FHS says both that we must not impose any particular directory structure > within /srv, and that we must use /srv as the "default location" for > storing data used by services. The only way to satisfy that would be to > do the equivalent of "DocumentRoot /srv" for every service, which would > be simply stupid. It doesn't say you must not have any particular defaults in srv -- just that applications must not expect it to be in any particular way. That's very different. I think it's entirely reasonable for Fedora to have a default layout, but it needs to be sure to cope properly if the local system does something different. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From nicolas.mailhot at laposte.net Mon Oct 23 17:15:48 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 23 Oct 2006 19:15:48 +0200 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <20061023162706.GA12971@jadzia.bu.edu> References: <4537BABE.2010602@semitekie.com> <80d7e4090610191332w6b18e732q32cad66c453a6268@mail.gmail.com> <20061021021451.GS32266@neu.nirvana> <20061021105819.GA27435@jadzia.bu.edu> <20061021110631.GF14307@neu.nirvana> <20061023161157.GA18288@redhat.com> <20061023162706.GA12971@jadzia.bu.edu> Message-ID: <1161623748.7722.2.camel@rousalka.dyndns.org> Le lundi 23 octobre 2006 ? 12:27 -0400, Matthew Miller a ?crit : > On Mon, Oct 23, 2006 at 05:11:57PM +0100, Joe Orton wrote: > > FHS says both that we must not impose any particular directory structure > > within /srv, and that we must use /srv as the "default location" for > > storing data used by services. The only way to satisfy that would be to > > do the equivalent of "DocumentRoot /srv" for every service, which would > > be simply stupid. > > It doesn't say you must not have any particular defaults in srv -- just that > applications must not expect it to be in any particular way. Replace applications there by third-party applications Obviously Fedora-packaged apps can expect whatever Fedora layout Fedora provides. -- Nicolas Mailhot From mattdm at mattdm.org Mon Oct 23 17:28:32 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 23 Oct 2006 13:28:32 -0400 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <1161623748.7722.2.camel@rousalka.dyndns.org> References: <4537BABE.2010602@semitekie.com> <80d7e4090610191332w6b18e732q32cad66c453a6268@mail.gmail.com> <20061021021451.GS32266@neu.nirvana> <20061021105819.GA27435@jadzia.bu.edu> <20061021110631.GF14307@neu.nirvana> <20061023161157.GA18288@redhat.com> <20061023162706.GA12971@jadzia.bu.edu> <1161623748.7722.2.camel@rousalka.dyndns.org> Message-ID: <20061023172832.GA15508@jadzia.bu.edu> On Mon, Oct 23, 2006 at 07:15:48PM +0200, Nicolas Mailhot wrote: > > > FHS says both that we must not impose any particular directory > > > structure within /srv, and that we must use /srv as the "default > > > location" for storing data used by services. The only way to satisfy > > > that would be to do the equivalent of "DocumentRoot /srv" for every > > > service, which would be simply stupid. > > It doesn't say you must not have any particular defaults in srv -- just > > that applications must not expect it to be in any particular way. > Replace applications there by third-party applications No, I don't think so, actually. > Obviously Fedora-packaged apps can expect whatever Fedora layout Fedora > provides. Why is that obvious? For example, look at /usr/local. Fedora provides a default layout there, but any Fedora-packaged program which has a problem if someone does something different is broken. Similarly, creating a /srv/www and making it the default document root for apache is fine. However, making other packages expect it to be there isn't so good. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Mon Oct 23 17:41:55 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Oct 2006 13:41:55 -0400 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <20061023172832.GA15508@jadzia.bu.edu> References: <4537BABE.2010602@semitekie.com> <1161623748.7722.2.camel@rousalka.dyndns.org> <20061023172832.GA15508@jadzia.bu.edu> Message-ID: <200610231341.55248.jkeating@redhat.com> On Monday 23 October 2006 13:28, Matthew Miller wrote: > For example, look at /usr/local. Fedora provides a default layout there, > but any Fedora-packaged program which has a problem if someone does > something different is broken. And one might say that any package (other than filesystem which creates these dirs) dropping files in /usr/local shouldn't and should fail review. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Oct 23 18:00:18 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 23 Oct 2006 20:00:18 +0200 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <20061023172832.GA15508@jadzia.bu.edu> References: <4537BABE.2010602@semitekie.com> <80d7e4090610191332w6b18e732q32cad66c453a6268@mail.gmail.com> <20061021021451.GS32266@neu.nirvana> <20061021105819.GA27435@jadzia.bu.edu> <20061021110631.GF14307@neu.nirvana> <20061023161157.GA18288@redhat.com> <20061023162706.GA12971@jadzia.bu.edu> <1161623748.7722.2.camel@rousalka.dyndns.org> <20061023172832.GA15508@jadzia.bu.edu> Message-ID: <20061023180018.GI7410@neu.nirvana> On Mon, Oct 23, 2006 at 01:28:32PM -0400, Matthew Miller wrote: > For example, look at /usr/local. Fedora provides a default layout there, but > any Fedora-packaged program which has a problem if someone does something > different is broken. No, that's not "Fedora's" default layout, it is actually the layout as given folder by folder by the FHS, even such folders like /usr/local/games. > Similarly, creating a /srv/www and making it the default document root for > apache is fine. However, making other packages expect it to be there isn't > so good. You shouldn't compare /usr/local with /srv. The former is very strictly dictated by the FHS, while /srv has the special status "free-for-all". The only Fedora'ism (or better said the most prominent one) existing is libexecdir and in this case we're trying to persuade the FHS editors about the need for it and place it into the next FHS. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Mon Oct 23 18:08:36 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 23 Oct 2006 20:08:36 +0200 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <20061023172832.GA15508@jadzia.bu.edu> References: <4537BABE.2010602@semitekie.com> <80d7e4090610191332w6b18e732q32cad66c453a6268@mail.gmail.com> <20061021021451.GS32266@neu.nirvana> <20061021105819.GA27435@jadzia.bu.edu> <20061021110631.GF14307@neu.nirvana> <20061023161157.GA18288@redhat.com> <20061023162706.GA12971@jadzia.bu.edu> <1161623748.7722.2.camel@rousalka.dyndns.org> <20061023172832.GA15508@jadzia.bu.edu> Message-ID: <1161626916.6896.24.camel@rousalka.dyndns.org> Le lundi 23 octobre 2006 ? 13:28 -0400, Matthew Miller a ?crit : > On Mon, Oct 23, 2006 at 07:15:48PM +0200, Nicolas Mailhot wrote: > > > > FHS says both that we must not impose any particular directory > > > > structure within /srv, and that we must use /srv as the "default > > > > location" for storing data used by services. The only way to satisfy > > > > that would be to do the equivalent of "DocumentRoot /srv" for every > > > > service, which would be simply stupid. > > > It doesn't say you must not have any particular defaults in srv -- just > > > that applications must not expect it to be in any particular way. > > Replace applications there by third-party applications > > No, I don't think so, actually. > > > Obviously Fedora-packaged apps can expect whatever Fedora layout Fedora > > provides. > > Why is that obvious? Because it's unreasonable to forbid an entity to rely on its own actions? The FHS wrote its specification in the context of an app installed on a foreign system, not in the context of a distro which controls the whole system The FHS basically writes app authors must write apps so app users can configure whatever /srv/ layout they want. It says no entity can expect another entity to provide any particular /srv/ layout. But in the context of a distribution : ? we are providing a /srv/ layout for ourselves (acting in-stead of users, which is what distributions are supposed to do) ? users are still free to reconfigure apps with whatever policy they prefer if they don't like the Fedora one. I don't see how the document could be read otherwise. The alternative would be to forbid *any* pre-configuration for *any* service the FHS puts in /srv/, which is plain ridiculous (should apps ignore conf files settings and embark in automagical /srv/ exploration heuristics too? that's another absolutist reading) And BTW pre-configuring is *safe*. *No* app author can complain Fedora is providing a particular /srv layout ? the FHS forbids them to expect a particular layout. That includes an empty /srv. -- Nicolas Mailhot From mattdm at mattdm.org Mon Oct 23 18:44:07 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 23 Oct 2006 14:44:07 -0400 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <1161626916.6896.24.camel@rousalka.dyndns.org> References: <4537BABE.2010602@semitekie.com> <80d7e4090610191332w6b18e732q32cad66c453a6268@mail.gmail.com> <20061021021451.GS32266@neu.nirvana> <20061021105819.GA27435@jadzia.bu.edu> <20061021110631.GF14307@neu.nirvana> <20061023161157.GA18288@redhat.com> <20061023162706.GA12971@jadzia.bu.edu> <1161623748.7722.2.camel@rousalka.dyndns.org> <20061023172832.GA15508@jadzia.bu.edu> <1161626916.6896.24.camel@rousalka.dyndns.org> Message-ID: <20061023184407.GA17821@jadzia.bu.edu> On Mon, Oct 23, 2006 at 08:08:36PM +0200, Nicolas Mailhot wrote: > > > Obviously Fedora-packaged apps can expect whatever Fedora layout Fedora > > > provides. > > Why is that obvious? > Because it's unreasonable to forbid an entity to rely on its own > actions? The FHS wrote its specification in the context of an app Yeah, but Fedora is not forbidden from relying on its _own_ actions, but rather from relying on _my_ actions. Although it's perfectly reasonable for Fedora to provide a default, it shouldn't/can't rely on me or you keeping that default, because, as Axel points out, there's many perfectly good ways for arranging this directory depending on system usage. > installed on a foreign system, not in the context of a distro which > controls the whole system This is exactly the point of /srv. The distro does not control the whole system -- the sysadmin does. However, the distro should be constructed to help the sysadmin as much as possible. > The FHS basically writes app authors must write apps so app users can > configure whatever /srv/ layout they want. It says no entity can expect > another entity to provide any particular /srv/ layout. > But in the context of a distribution : > ? we are providing a /srv/ layout for ourselves (acting in-stead of > users, which is what distributions are supposed to do) > ? users are still free to reconfigure apps with whatever policy they > prefer if they don't like the Fedora one. I agree with you so far. However, the phrasing "Fedora-packaged apps can expect whatever Fedora layout" seems to assume that add-on web packages which don't have a good mechanism for being reconfigured other than rebuilding would be free to rely on some layout for /srv. Instead, they should be fixed so they don't have to. Additionally, there should be no risk of any local data in /srv being overwritten on package upgrade. Package-managed files shouldn't be in there. (See the cvsweb and munin rpms in extras, for example.) This is pretty straightforward -- user-edited data and RPM-handled files don't mix well. (The conf file .rpmnew/.rpmsave kludge isn't viable here.) > I don't see how the document could be read otherwise. The alternative > would be to forbid *any* pre-configuration for *any* service the FHS > puts in /srv/, which is plain ridiculous (should apps ignore conf files > settings and embark in automagical /srv/ exploration heuristics too? > that's another absolutist reading) It works pretty well with Apache via the /etc/httpd/conf.d/welcome.conf mechanism.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Mon Oct 23 18:46:13 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 23 Oct 2006 14:46:13 -0400 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <200610231341.55248.jkeating@redhat.com> References: <4537BABE.2010602@semitekie.com> <1161623748.7722.2.camel@rousalka.dyndns.org> <20061023172832.GA15508@jadzia.bu.edu> <200610231341.55248.jkeating@redhat.com> Message-ID: <20061023184613.GA20038@jadzia.bu.edu> On Mon, Oct 23, 2006 at 01:41:55PM -0400, Jesse Keating wrote: > > For example, look at /usr/local. Fedora provides a default layout there, > > but any Fedora-packaged program which has a problem if someone does > > something different is broken. > And one might say that any package (other than filesystem which creates > these dirs) dropping files in /usr/local shouldn't and should fail review. Yes. I'm advocating the "filesystem which creates those dirs" step at most. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From nicolas.mailhot at laposte.net Mon Oct 23 19:05:33 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 23 Oct 2006 21:05:33 +0200 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <20061023184407.GA17821@jadzia.bu.edu> References: <4537BABE.2010602@semitekie.com> <80d7e4090610191332w6b18e732q32cad66c453a6268@mail.gmail.com> <20061021021451.GS32266@neu.nirvana> <20061021105819.GA27435@jadzia.bu.edu> <20061021110631.GF14307@neu.nirvana> <20061023161157.GA18288@redhat.com> <20061023162706.GA12971@jadzia.bu.edu> <1161623748.7722.2.camel@rousalka.dyndns.org> <20061023172832.GA15508@jadzia.bu.edu> <1161626916.6896.24.camel@rousalka.dyndns.org> <20061023184407.GA17821@jadzia.bu.edu> Message-ID: <1161630333.6896.36.camel@rousalka.dyndns.org> Le lundi 23 octobre 2006 ? 14:44 -0400, Matthew Miller a ?crit : > On Mon, Oct 23, 2006 at 08:08:36PM +0200, Nicolas Mailhot wrote: > Although it's perfectly reasonable for > Fedora to provide a default, it shouldn't/can't rely on me or you keeping > that default, because, as Axel points out, there's many perfectly good ways > for arranging this directory depending on system usage. As long as Fedora can provide a default and rely on the sysadmin creating directories, updating conf files, selinux contexts, if he wishes another policy all is fine > > installed on a foreign system, not in the context of a distro which > > controls the whole system > > This is exactly the point of /srv. The distro does not control the whole > system -- the sysadmin does. However, the distro should be constructed to > help the sysadmin as much as possible. Which includes providing default policies. In the APP vs USER divide the distribution is not on one side only. > However, the phrasing "Fedora-packaged apps can expect whatever Fedora > layout" seems to assume that add-on web packages which don't have a good > mechanism for being reconfigured other than rebuilding would be free to rely > on some layout for /srv. Instead, they should be fixed so they don't have > to. Sure. To be clear: ? Matthew the app writer can not hardcode /srv paths in its app or have them set at build time ? Matthew the app packager, working within a distro can and should create whatever directory structure is needed in /srv and preconfigure its package to use it. If the app does not permit anything but hardcoding he should refer upstream > Additionally, there should be no risk of any local data in /srv being > overwritten on package upgrade. Package-managed files shouldn't be in there. But service roots (directories) should be there (including perhaps some %config files such as a default FTP welcome message) > > settings and embark in automagical /srv/ exploration heuristics too? > > that's another absolutist reading) > > It works pretty well with Apache via the /etc/httpd/conf.d/welcome.conf > mechanism.... This is not automagical exploration that's conf file reading, including files auto-dropped by packages -- Nicolas Mailhot From Axel.Thimm at ATrpms.net Mon Oct 23 20:04:11 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 23 Oct 2006 22:04:11 +0200 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <1161630333.6896.36.camel@rousalka.dyndns.org> References: <20061021021451.GS32266@neu.nirvana> <20061021105819.GA27435@jadzia.bu.edu> <20061021110631.GF14307@neu.nirvana> <20061023161157.GA18288@redhat.com> <20061023162706.GA12971@jadzia.bu.edu> <1161623748.7722.2.camel@rousalka.dyndns.org> <20061023172832.GA15508@jadzia.bu.edu> <1161626916.6896.24.camel@rousalka.dyndns.org> <20061023184407.GA17821@jadzia.bu.edu> <1161630333.6896.36.camel@rousalka.dyndns.org> Message-ID: <20061023200411.GJ7410@neu.nirvana> On Mon, Oct 23, 2006 at 09:05:33PM +0200, Nicolas Mailhot wrote: > Le lundi 23 octobre 2006 ? 14:44 -0400, Matthew Miller a ?crit : > > On Mon, Oct 23, 2006 at 08:08:36PM +0200, Nicolas Mailhot wrote: > > > Although it's perfectly reasonable for > > Fedora to provide a default, it shouldn't/can't rely on me or you keeping > > that default, because, as Axel points out, there's many perfectly good ways > > for arranging this directory depending on system usage. > > As long as Fedora can provide a default and rely on the sysadmin > creating directories, updating conf files, selinux contexts, if he > wishes another policy all is fine How, if the distribution defaults are in the way? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Mon Oct 23 20:11:40 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 23 Oct 2006 22:11:40 +0200 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <20061023200411.GJ7410@neu.nirvana> References: <20061021021451.GS32266@neu.nirvana> <20061021105819.GA27435@jadzia.bu.edu> <20061021110631.GF14307@neu.nirvana> <20061023161157.GA18288@redhat.com> <20061023162706.GA12971@jadzia.bu.edu> <1161623748.7722.2.camel@rousalka.dyndns.org> <20061023172832.GA15508@jadzia.bu.edu> <1161626916.6896.24.camel@rousalka.dyndns.org> <20061023184407.GA17821@jadzia.bu.edu> <1161630333.6896.36.camel@rousalka.dyndns.org> <20061023200411.GJ7410@neu.nirvana> Message-ID: <1161634300.6896.39.camel@rousalka.dyndns.org> Le lundi 23 octobre 2006 ? 22:04 +0200, Axel Thimm a ?crit : > On Mon, Oct 23, 2006 at 09:05:33PM +0200, Nicolas Mailhot wrote: > > Le lundi 23 octobre 2006 ? 14:44 -0400, Matthew Miller a ?crit : > > > On Mon, Oct 23, 2006 at 08:08:36PM +0200, Nicolas Mailhot wrote: > > > > > Although it's perfectly reasonable for > > > Fedora to provide a default, it shouldn't/can't rely on me or you keeping > > > that default, because, as Axel points out, there's many perfectly good ways > > > for arranging this directory depending on system usage. > > > > As long as Fedora can provide a default and rely on the sysadmin > > creating directories, updating conf files, selinux contexts, if he > > wishes another policy all is fine > > How, if the distribution defaults are in the way? Just put distributions defaults under /srv/whatever if you're afraid of collisions. With whatever being system if you're reasonable and DoctObnik! or wi.drigco if you're not -- Nicolas Mailhot From mattdm at mattdm.org Mon Oct 23 20:16:02 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 23 Oct 2006 16:16:02 -0400 Subject: [Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?) In-Reply-To: <20061023190430.GA30632@devserv.devel.redhat.com> References: <80d7e4090610191332w6b18e732q32cad66c453a6268@mail.gmail.com> <20061021021451.GS32266@neu.nirvana> <20061021105819.GA27435@jadzia.bu.edu> <20061021110631.GF14307@neu.nirvana> <20061023161157.GA18288@redhat.com> <20061023162706.GA12971@jadzia.bu.edu> <1161623748.7722.2.camel@rousalka.dyndns.org> <20061023172832.GA15508@jadzia.bu.edu> <1161626916.6896.24.camel@rousalka.dyndns.org> <20061023190430.GA30632@devserv.devel.redhat.com> Message-ID: <20061023201602.GA26670@jadzia.bu.edu> On Mon, Oct 23, 2006 at 03:04:30PM -0400, Alan Cox wrote: > /srv is ridiculous from any sane interpretation. It got in purely because > the people actually doing useful work accidentally briefly got outnumbered > by people with no experience and opinions when it was voted on Well, I certainly don't have your experience. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ville.skytta at iki.fi Tue Oct 24 06:51:05 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 24 Oct 2006 09:51:05 +0300 Subject: [Fedora-packaging] Missing the meeting today Message-ID: <1161672665.3527.73.camel@viper.local> I will miss the packaging meeting today, or at least the first half an hour of it or so. V From rc040203 at freenet.de Tue Oct 24 06:56:47 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 24 Oct 2006 08:56:47 +0200 Subject: [Fedora-packaging] Missing the meeting today In-Reply-To: <1161672665.3527.73.camel@viper.local> References: <1161672665.3527.73.camel@viper.local> Message-ID: <1161673007.5244.21.camel@mccallum.corsepiu.local> On Tue, 2006-10-24 at 09:51 +0300, Ville Skytt? wrote: > I will miss the packaging meeting today, or at least the first half an > hour of it or so. Me too ;) I probably won't be able to attend. Ralf From Axel.Thimm at ATrpms.net Tue Oct 24 09:20:34 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 24 Oct 2006 11:20:34 +0200 Subject: [Fedora-packaging] Re: Missing the meeting today In-Reply-To: <1161673007.5244.21.camel@mccallum.corsepiu.local> References: <1161672665.3527.73.camel@viper.local> <1161673007.5244.21.camel@mccallum.corsepiu.local> Message-ID: <20061024092034.GC30838@neu.nirvana> On Tue, Oct 24, 2006 at 08:56:47AM +0200, Ralf Corsepius wrote: > On Tue, 2006-10-24 at 09:51 +0300, Ville Skytt? wrote: > > I will miss the packaging meeting today, or at least the first half an > > hour of it or so. > > Me too ;) > > I probably won't be able to attend. Most probably I'll also not be able to make it. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Tue Oct 24 12:49:09 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 24 Oct 2006 07:49:09 -0500 Subject: [Fedora-packaging] Re: Missing the meeting today In-Reply-To: <20061024092034.GC30838@neu.nirvana> References: <1161672665.3527.73.camel@viper.local> <1161673007.5244.21.camel@mccallum.corsepiu.local> <20061024092034.GC30838@neu.nirvana> Message-ID: <1161694149.2909.456.camel@localhost.localdomain> On Tue, 2006-10-24 at 11:20 +0200, Axel Thimm wrote: > On Tue, Oct 24, 2006 at 08:56:47AM +0200, Ralf Corsepius wrote: > > On Tue, 2006-10-24 at 09:51 +0300, Ville Skytt? wrote: > > > I will miss the packaging meeting today, or at least the first half an > > > hour of it or so. > > > > Me too ;) > > > > I probably won't be able to attend. > > Most probably I'll also not be able to make it. I'm also going to be absent, due to a dentist appt. Looks like we'll reconvene next week. :) ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From jkeating at redhat.com Thu Oct 26 14:47:25 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Oct 2006 10:47:25 -0400 Subject: [Fedora-packaging] --add-category X-Fedora option to desktop-file-install not necessary nor used. Message-ID: <200610261047.25651.jkeating@redhat.com> This just adds noise and cruft to desktop files and spec files. It is not used by anything. Likewise --vendor fedora, but current desktop-file-install requires a vendor even though it isn't in use. We'll be fixing that shortly though. So for now, can I get votes to remove the --add-category X-Fedora line from the guidelines? For the --vendor thing, it should probably stay in for now for older releases since I don't want to see our guidelines get too broken up between what is allowed or disallowed per release. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Thu Oct 26 14:51:58 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 26 Oct 2006 17:51:58 +0300 Subject: [Fedora-packaging] --add-category X-Fedora option to desktop-file-install not necessary nor used. In-Reply-To: <200610261047.25651.jkeating@redhat.com> References: <200610261047.25651.jkeating@redhat.com> Message-ID: <1161874318.3527.141.camel@viper.local> On Thu, 2006-10-26 at 10:47 -0400, Jesse Keating wrote: > So for now, can I get votes to remove the --add-category X-Fedora line from > the guidelines? +1 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Oct 26 14:57:52 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 26 Oct 2006 16:57:52 +0200 Subject: [Fedora-packaging] --add-category X-Fedora option to desktop-file-install not necessary nor used. In-Reply-To: <1161874318.3527.141.camel@viper.local> References: <200610261047.25651.jkeating@redhat.com> <1161874318.3527.141.camel@viper.local> Message-ID: <20061026165752.63fede66@python3.es.egwn.lan> Ville Skytt? wrote : > On Thu, 2006-10-26 at 10:47 -0400, Jesse Keating wrote: > > > So for now, can I get votes to remove the --add-category X-Fedora line from > > the guidelines? > > +1 Always count me in when it's about removing useless stuff! :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Rawhide) - Linux kernel 2.6.18-1.2798.fc6 Load : 0.06 0.09 0.09 From tibbs at math.uh.edu Thu Oct 26 15:05:32 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 26 Oct 2006 10:05:32 -0500 Subject: [Fedora-packaging] --add-category X-Fedora option to desktop-file-install not necessary nor used. In-Reply-To: <200610261047.25651.jkeating@redhat.com> (Jesse Keating's message of "Thu, 26 Oct 2006 10:47:25 -0400") References: <200610261047.25651.jkeating@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> So for now, can I get votes to remove the --add-category X-Fedora JK> line from the guidelines? Could we first understand why it was added in the first place? There must have been a reason, and knowing it should make it easy to decide whether or not it's still reasonable. - J From rdieter at math.unl.edu Thu Oct 26 15:00:46 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 26 Oct 2006 10:00:46 -0500 Subject: [Fedora-packaging] Re: --add-category X-Fedora option to desktop-file-install not necessary nor used. References: <200610261047.25651.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > This just adds noise and cruft to desktop files and spec files. It is not > used by anything. > > Likewise --vendor fedora, but current desktop-file-install requires a > vendor > even though it isn't in use. We'll be fixing that shortly though. --vendor is recommended by the menu spec, but I'm not sure it should be mandatory (I'm leaning toward no). > So for now, can I get votes to remove the --add-category X-Fedora line > from the guidelines? I don't see the facility in this either, +1. -- Rex From jkeating at redhat.com Thu Oct 26 15:22:20 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Oct 2006 11:22:20 -0400 Subject: [Fedora-packaging] --add-category X-Fedora option to desktop-file-install not necessary nor used. In-Reply-To: References: <200610261047.25651.jkeating@redhat.com> Message-ID: <200610261122.20788.jkeating@redhat.com> On Thursday 26 October 2006 11:05, Jason L Tibbitts III wrote: > Could we first understand why it was added in the first place? ?There > must have been a reason, and knowing it should make it easy to decide > whether or not it's still reasonable. The best I've heard so far was carryover from fedora.us... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Thu Oct 26 15:26:17 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 26 Oct 2006 10:26:17 -0500 Subject: [Fedora-packaging] --add-category X-Fedora option to desktop-file-install not necessary nor used. In-Reply-To: <200610261122.20788.jkeating@redhat.com> (Jesse Keating's message of "Thu, 26 Oct 2006 11:22:20 -0400") References: <200610261047.25651.jkeating@redhat.com> <200610261122.20788.jkeating@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> The best I've heard so far was carryover from fedora.us... I guess that if nobody knows of any reason why it should be there, then it doesn't need to be there. I'll +1 to this just on the general principle of removing needless cruft; I've never understood why this might have been useful. - J< From tcallawa at redhat.com Thu Oct 26 17:21:06 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 26 Oct 2006 12:21:06 -0500 Subject: [Fedora-packaging] --add-category X-Fedora option to desktop-file-install not necessary nor used. In-Reply-To: References: <200610261047.25651.jkeating@redhat.com> <200610261122.20788.jkeating@redhat.com> Message-ID: <1161883266.24528.38.camel@dhcp-32-122.ord.redhat.com> On Thu, 2006-10-26 at 10:26 -0500, Jason L Tibbitts III wrote: > >>>>> "JK" == Jesse Keating writes: > > JK> The best I've heard so far was carryover from fedora.us... > > I guess that if nobody knows of any reason why it should be there, > then it doesn't need to be there. > > I'll +1 to this just on the general principle of removing needless > cruft; I've never understood why this might have been useful. +1. Let it die. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From bugs.michael at gmx.net Thu Oct 26 18:24:18 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 26 Oct 2006 20:24:18 +0200 Subject: [Fedora-packaging] --add-category X-Fedora option to desktop-file-install not necessary nor used. In-Reply-To: References: <200610261047.25651.jkeating@redhat.com> <200610261122.20788.jkeating@redhat.com> Message-ID: <20061026202418.36c73448.bugs.michael@gmx.net> On Thu, 26 Oct 2006 10:26:17 -0500, Jason L Tibbitts III wrote: > >>>>> "JK" == Jesse Keating writes: > > JK> The best I've heard so far was carryover from fedora.us... > > I guess that if nobody knows of any reason why it should be there, > then it doesn't need to be there. > > I'll +1 to this just on the general principle of removing needless > cruft; I've never understood why this might have been useful. IIRC, we've had the choice between: X-Red-Hat-Base : for top-level menus, which we never set X-Red-Hat-Extra : for everything else, but fedora.us was not Red Hat So, fedora.us add-on packages introduced the X-Fedora category to allow for future desktop menu features like adding/hiding/moving base and/or add-on package entries (or entire hierarchies) based on special category values. From a.badger at gmail.com Thu Oct 26 18:25:48 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 26 Oct 2006 11:25:48 -0700 Subject: [Fedora-packaging] --add-category X-Fedora option to desktop-file-install not necessary nor used. In-Reply-To: References: <200610261047.25651.jkeating@redhat.com> Message-ID: <1161887148.3009.4.camel@localhost> On Thu, 2006-10-26 at 10:05 -0500, Jason L Tibbitts III wrote: > >>>>> "JK" == Jesse Keating writes: > > JK> So for now, can I get votes to remove the --add-category X-Fedora > JK> line from the guidelines? > > Could we first understand why it was added in the first place? There > must have been a reason, and knowing it should make it easy to decide > whether or not it's still reasonable. Fedora.us had this to say (From google cache): http://tinyurl.com/yjxh6l ''' All Categories must be from the standard set (see below), with the exception that the "Application" category should be included where appropriate (ie. for everything that is supposed to be shown in the menus) for backwards compatibility even though it is not listed as a standard category. Additionally, all Fedora packages must contain the "X-Fedora" category. For packages that exist in Red Hat Linux, the categories must be the same as Red Hat's (+ X-Fedora). For packages that are considered essential for end users, the "X-Red-Hat-Base" Category must be added because that's currently the only way to get them listed in the top level menus instead of "Extras" on RH8 or "More foo..." on RH9. ''' -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu Oct 26 18:32:42 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Oct 2006 14:32:42 -0400 Subject: [Fedora-packaging] --add-category X-Fedora option to desktop-file-install not necessary nor used. In-Reply-To: <20061026202418.36c73448.bugs.michael@gmx.net> References: <200610261047.25651.jkeating@redhat.com> <20061026202418.36c73448.bugs.michael@gmx.net> Message-ID: <200610261432.45055.jkeating@redhat.com> On Thursday 26 October 2006 14:24, Michael Schwendt wrote: > So, fedora.us add-on packages introduced the X-Fedora category to allow > for future desktop menu features like adding/hiding/moving base and/or > add-on package entries (or entire hierarchies) based on special category > values. Given this and Toshio's reply, I still don't see a need/reason to be using this right now. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Thu Oct 26 19:49:39 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 26 Oct 2006 21:49:39 +0200 Subject: [Fedora-packaging] --add-category X-Fedora option to desktop-file-install not necessary nor used. In-Reply-To: <200610261432.45055.jkeating@redhat.com> References: <200610261047.25651.jkeating@redhat.com> <20061026202418.36c73448.bugs.michael@gmx.net> <200610261432.45055.jkeating@redhat.com> Message-ID: <20061026214939.60b3ac2d.bugs.michael@gmx.net> On Thu, 26 Oct 2006 14:32:42 -0400, Jesse Keating wrote: > > So, fedora.us add-on packages introduced the X-Fedora category to allow > > for future desktop menu features like adding/hiding/moving base and/or > > add-on package entries (or entire hierarchies) based on special category > > values. > > Given this and Toshio's reply, I still don't see a need/reason to be using > this right now. Doesn't surprise me, since I didn't mean to justify the existance of X-Fedora. Just explained its origin. From paul at all-the-johnsons.co.uk Sat Oct 28 14:47:25 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 28 Oct 2006 15:47:25 +0100 Subject: [Fedora-packaging] Rawhide desktop-file-install question Message-ID: <1162046845.31449.9.camel@T7.Linux> Hi, I'm getting an error when building for rawhide with anything that needs a desktop-file-install section in the %install section. It now asks for category that the software fits into. Do I need to change the --add-category X-Fedora to say --add-category X-Fedora/IDE (for anjuta or monodevelop) or is it --add-category X-Fedora, IDE? TTFN Paul -- "Der einzige Weg, Leute zu kontrollieren ist sie anzul?gen" - L. Ron "Ich kann kein Science-Fiction schreiben" Hubbard; L?gner, Betr?ger, Fixer und Wohlt?ter zu niemandem -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mtasaka at ioa.s.u-tokyo.ac.jp Sat Oct 28 15:06:00 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 29 Oct 2006 00:06:00 +0900 Subject: [Fedora-packaging] Rawhide desktop-file-install question In-Reply-To: <1162046845.31449.9.camel@T7.Linux> References: <1162046845.31449.9.camel@T7.Linux> Message-ID: <454371D8.2010701@ioa.s.u-tokyo.ac.jp> Paul wrote: > Hi, > > I'm getting an error when building for rawhide with anything that needs > a desktop-file-install section in the %install section. It now asks for > category that the software fits into. > > Do I need to change the --add-category X-Fedora to say --add-category > X-Fedora/IDE (for anjuta or monodevelop) or is it --add-category > X-Fedora, IDE? > desktop-file-utils 0.11-4.fc7 has changed so that it only warns for extra categories so it will be okay without changing the category (in the future this may change). Mamoru Tasaka From ville.skytta at iki.fi Sat Oct 28 15:10:25 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 28 Oct 2006 18:10:25 +0300 Subject: [Fedora-packaging] Rawhide desktop-file-install question In-Reply-To: <1162046845.31449.9.camel@T7.Linux> References: <1162046845.31449.9.camel@T7.Linux> Message-ID: <1162048225.11104.5.camel@viper.local> On Sat, 2006-10-28 at 15:47 +0100, Paul wrote: > Do I need to change the --add-category X-Fedora to say --add-category > X-Fedora/IDE (for anjuta or monodevelop) or is it --add-category > X-Fedora, IDE? As discussed quite a bit here and on fedora-extras-list a couple of days ago, drop the X-Fedora category. https://www.redhat.com/archives/fedora-packaging/2006-October/msg00188.html https://www.redhat.com/archives/fedora-extras-list/2006-October/msg00717.html https://bugzilla.redhat.com/212350 From Axel.Thimm at ATrpms.net Tue Oct 31 15:44:31 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 31 Oct 2006 16:44:31 +0100 Subject: [Fedora-packaging] Re: Missing the meeting today Message-ID: <20061031154431.GA769@neu.nirvana> I'll not be able to join on IRC today. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Oct 31 16:07:35 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 31 Oct 2006 11:07:35 -0500 Subject: [Fedora-packaging] Re: Missing the meeting today In-Reply-To: <20061031154431.GA769@neu.nirvana> References: <20061031154431.GA769@neu.nirvana> Message-ID: <200610311107.36106.jkeating@redhat.com> On Tuesday 31 October 2006 10:44, Axel Thimm wrote: > I'll not be able to join on I> RC today. Neither will I, work function. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Tue Oct 31 17:50:16 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 31 Oct 2006 12:50:16 -0500 Subject: [Fedora-packaging] Re: Missing the meeting today In-Reply-To: <200610311107.36106.jkeating@redhat.com> References: <20061031154431.GA769@neu.nirvana> <200610311107.36106.jkeating@redhat.com> Message-ID: <1162317016.2423.37.camel@cutter> On Tue, 2006-10-31 at 11:07 -0500, Jesse Keating wrote: > On Tuesday 31 October 2006 10:44, Axel Thimm wrote: > > I'll not be able to join on I> RC today. > > > Neither will I, work function. > 'work function' == hallowe'en party. -sv From jkeating at redhat.com Tue Oct 31 18:35:52 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 31 Oct 2006 13:35:52 -0500 Subject: [Fedora-packaging] Re: Missing the meeting today In-Reply-To: <1162317016.2423.37.camel@cutter> References: <20061031154431.GA769@neu.nirvana> <200610311107.36106.jkeating@redhat.com> <1162317016.2423.37.camel@cutter> Message-ID: <200610311335.55723.jkeating@redhat.com> On Tuesday 31 October 2006 12:50, seth vidal wrote: > 'work function' == hallowe'en party. You caught me! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: