Re: [Mageia-dev] [RPM] cauldron core/release unknown-horizons-2011-1.mga2
Le mercredi 13 juillet 2011 01:23:32, Mageia Team a écrit : Name: unknown-horizons Relocations: (not relocatable) Version : 2011 Vendor: Mageia.Org Release : 1.mga2Build Date: Wed Jul 13 01:19:29 2011 Install Date: (not installed) Build Host: ecosse Group : Amusements/Games/Strategy/Real Time Source RPM: (none) Size: 82606743 License: GPLv2+ ; CC-BY-SA 3.0 ; OFL ; Signature : (none) Packager: Mageia Team http://www.mageia.org URL : http://www.unknown-horizons.org Summary : A popular economy and city building 2D RTS game Description : Unknown Horizons is a 2D real-time strategy simulation with an emphasis on economy and city building. Expand your small settlement to a strong and wealthy colony, collect taxes and supply your inhabitants with valuable goods. Increase your power with a well balanced economy and with strategic trade and diplomacy. --- http://www.unknown-horizons.org http://www.unknown-horizons.org/media/screenshot-gallery anaselli anaselli 2011-1.mga2: + Revision: 123512 - Updated to version 2011.2 + matteo matteo - unknown-horizons.spec: spec file polished + stblack stblack - imported package unknown-horizons The group Amusements/Games/Strategy/Real Time doesn't exist in Mageia :) Samuel
Re: [Mageia-dev] [RPM] cauldron core/release unknown-horizons-2011-1.mga2
Le mercredi 13 juillet 2011 01:23:32, Mageia Team a écrit : Name: unknown-horizons Relocations: (not relocatable) Version : 2011 Vendor: Mageia.Org Release : 1.mga2Build Date: Wed Jul 13 01:19:29 2011 Install Date: (not installed) Build Host: ecosse Group : Amusements/Games/Strategy/Real Time Source RPM: (none) Size: 82606743 License: GPLv2+ ; CC-BY-SA 3.0 ; OFL ; Signature : (none) Packager: Mageia Team http://www.mageia.org URL : http://www.unknown-horizons.org Summary : A popular economy and city building 2D RTS game Description : Unknown Horizons is a 2D real-time strategy simulation with an emphasis on economy and city building. Expand your small settlement to a strong and wealthy colony, collect taxes and supply your inhabitants with valuable goods. Increase your power with a well balanced economy and with strategic trade and diplomacy. --- http://www.unknown-horizons.org http://www.unknown-horizons.org/media/screenshot-gallery anaselli anaselli 2011-1.mga2: + Revision: 123512 - Updated to version 2011.2 + matteo matteo - unknown-horizons.spec: spec file polished + stblack stblack - imported package unknown-horizons The group Amusements/Games/Strategy/Real Time doesn't exist in Mageia. 3 different packagers haven't seen this ? :) Samuel
Re: [Mageia-dev] Python Packaging Policy
2011/7/13 Michael scherer m...@zarb.org: I would be in favor of treating python2 and python 3 as 2 differents languages. The rational is that : - we cannot garantee to have support for both - we will likely have some module who would be updated only on python 3 sooner or later - we will need to do upgrade of package at different time, since both python2 and python3 are released at different time. So rather than a complex scheme that will confuse packagers, just consider they are separate, and use the almost same policy ( with s/python/python3/ ) And how do you manage package that support both P2 and P3 ? (same source) Regarding a review of all package, that sound like daunting task :/ yes, but do you see another solution ? we can have a priority list
Re: [Mageia-dev] [RPM] cauldron core/release unknown-horizons-2011-1.mga2
Le mercredi 13 juillet 2011 09:47:57, Samuel Verschelde a écrit : Le mercredi 13 juillet 2011 01:23:32, Mageia Team a écrit : Name: unknown-horizons Relocations: (not relocatable) Version : 2011 Vendor: Mageia.Org Release : 1.mga2Build Date: Wed Jul 13 01:19:29 2011 Install Date: (not installed) Build Host: ecosse Group : Amusements/Games/Strategy/Real Time Source RPM: (none) Size: 82606743 License: GPLv2+ ; CC-BY-SA 3.0 ; OFL ; Signature : (none) Packager: Mageia Team http://www.mageia.org URL : http://www.unknown-horizons.org Summary : A popular economy and city building 2D RTS game Description : Unknown Horizons is a 2D real-time strategy simulation with an emphasis on economy and city building. Expand your small settlement to a strong and wealthy colony, collect taxes and supply your inhabitants with valuable goods. Increase your power with a well balanced economy and with strategic trade and diplomacy. --- http://www.unknown-horizons.org http://www.unknown-horizons.org/media/screenshot-gallery anaselli anaselli 2011-1.mga2: + Revision: 123512 - Updated to version 2011.2 + matteo matteo - unknown-horizons.spec: spec file polished + stblack stblack - imported package unknown-horizons The group Amusements/Games/Strategy/Real Time doesn't exist in Mageia :) Samuel Hmm, I should have received a you're being moderated message that would also have allowed me to cancel this message (sent from wrong address). Has something changed in MLs configuration ? Samuel
Re: [Mageia-dev] [Mageia 2 specifications ] Grub2
On Tue, Jul 12, 2011 at 03:12:52PM +0200, Anne nicolas wrote: Yet another burning subject that needs time to think about it and eventually migrate to. https://bugs.mageia.org/show_bug.cgi?id=2121 Grub 2 is coming now regularly in proposals. What should we do about it : - Stay with Grub 1 - pb ? maintainance ? restrictions ? - Switch to Grub 2 : smooth migration, tests, integration... - another alternative ? As usual, comments, proposals... I think we should offer support for it, ie package, patch the tools ( given the fact that 5 people are ready to do the switch, I guess they are all eager to help on creating a proper package ). But not do a change in the default before Mageia 3. While Grub 2 is working fine ( I use it since 3 years ), there was people complaining about this on ubuntu ( because this changed their habits, because the documentation was sparse ) to warrant not rushing the change. We value quality, and so we can offer grub2 as a option, and make sure it got enough test, even by people on the stable release before deciding. IE, without any test, we should not change, so I would set a deadline to have grub2 ready befre saying we switch. -- Michael Scherer People that want grub 2 should be able to do it like those that use lilo.
Re: [Mageia-dev] [RPM] cauldron core/release unknown-horizons-2011-1.mga2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 13/07/2011 09:49, Samuel Verschelde ha scritto: Le mercredi 13 juillet 2011 01:23:32, Mageia Team a écrit : Name: unknown-horizons Relocations: (not relocatable) Version : 2011 Vendor: Mageia.Org Release : 1.mga2Build Date: Wed Jul 13 01:19:29 2011 Install Date: (not installed) Build Host: ecosse Group : Amusements/Games/Strategy/Real Time Source RPM: (none) Size: 82606743 License: GPLv2+ ; CC-BY-SA 3.0 ; OFL ; Signature : (none) Packager: Mageia Team http://www.mageia.org URL : http://www.unknown-horizons.org Summary : A popular economy and city building 2D RTS game Description : Unknown Horizons is a 2D real-time strategy simulation with an emphasis on economy and city building. Expand your small settlement to a strong and wealthy colony, collect taxes and supply your inhabitants with valuable goods. Increase your power with a well balanced economy and with strategic trade and diplomacy. --- http://www.unknown-horizons.org http://www.unknown-horizons.org/media/screenshot-gallery anaselli anaselli 2011-1.mga2: + Revision: 123512 - Updated to version 2011.2 + matteo matteo - unknown-horizons.spec: spec file polished + stblack stblack - imported package unknown-horizons The group Amusements/Games/Strategy/Real Time doesn't exist in Mageia. 3 different packagers haven't seen this ? :) Samuel I'm sorry Samuel, next time I'll pay more attention. - -- Matteo () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mageia - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOHVPAAAoJED3LowjDDWbNcnMIAKc8TbYyv2sBZZVvd6/YvhIz lKzLl3+T6uvY35dKoBOdY1R96MFF+Tgnxx2uJPqsJ3NZ/sXJp5Qh53ZcRZr/SKgn 15zWJJxQBTSxcBYQdByDyfbaaIU3MICCqlu1EhvDKlfPorC1CPfjRRF7wF/UAWHP +ODPCNQ6H0J+ZhDIF89FQrdKKplkwpZqmX/SKxVupcfXZn7UrFP1kgwdAFSp/bAA lj5/LOxQbfnjTwq8fJDy4FF4UPvfnK1tpYyIJEptCYRYpKfDu+VgYTYstFiaBoyQ k3M7trYfkR0ZDRIK2xhMzXfiJbEpdJ+l3jdLbyytfJke4PQSnFtw39xCS17yq3M= =EEzP -END PGP SIGNATURE-
Re: [Mageia-dev] [RPM] cauldron core/release unknown-horizons-2011-1.mga2
Group : Amusements/Games/Strategy/Real Time Source RPM: (none) The group Amusements/Games/Strategy/Real Time doesn't exist in Mageia. 3 different packagers haven't seen this ? :) Eheheh, too tired to check all :) luckily is cauldron :D Thanks, Angelo signature.asc Description: This is a digitally signed message part.
[Mageia-dev] Generic 64-bit building question
Sorry for polluting the whole list, but as I don't have a mentor...
This is the first time I'm building 64-bit packages, and I'm running into the
following issue.
Requirements such as:
BuildRequires: qt4-devel
BuildRequires: python-devel
expand very well (automatically) on 64-bit into:
lib64qt4-devel
lib64python-devel
However, requirements such as:
BuildRequires: magick-devel
BuildRequires: chm-devel
BuildRequires: wmf-devel
do NOT expand into the existing:
lib64magick-devel
lib64chm-devel
lib64wmf-devel
therefore I have to use:
BuildRequires: %{_lib}magick-devel
BuildRequires: %{_lib}chm-devel
BuildRequires: %{_lib}wmf-devel
Of course(?), magick-devel%{?_isa} etc. does NOT help.
Question 1: why some libraries name do expand on 64-bit, whereas others don't?
Question 2: why some other libraries expand even when incorrect names are given?
E.g.:
BuildRequires: libpoppler-qt4-devel
accepts the installed lib:
lib64poppler-qt4-devel
although the name is incorrect, it should be limited to 32-bit!
Is the building system broken, am I stupid, or both?
Thanks,
R-C aka beranger
Re: [Mageia-dev] Generic 64-bit building question
13.07.2011 11:43, Radu-Cristian FOTESCU kirjutas: do NOT expand into the existing: lib64magick-devel lib64chm-devel lib64wmf-devel Currently there is urpmq --provides for that. For example: $ urpmq --provides lib64magick-devel imagemagick-devel[== 6.6.6.10-5.mga1] ImageMagick-devel[== 6.6.6.10-5.mga1] libmagick-devel[== 6.6.6.10-5.mga1] libMagick-devel[== 6.6.6.10-5.mga1] libMagick5-devel[== 6.6.6.10-5.mga1] pkgconfig(ImageMagick)[== 6.6.6] pkgconfig(ImageMagick++)[== 6.6.6] pkgconfig(Magick++)[== 6.6.6] pkgconfig(MagickCore)[== 6.6.6] pkgconfig(MagickWand)[== 6.6.6] pkgconfig(Wand)[== 6.6.6] devel(libMagick++(64bit)) devel(libMagickCore(64bit)) devel(libMagickWand(64bit)) lib64magick-devel[== 6.6.6.10-5.mga1] lib64magick-devel(x86-64)[== 6.6.6.10-5.mga1] You should use libmagick-devel -- Sander
Re: [Mageia-dev] Generic 64-bit building question
Le mercredi 13 juillet 2011 10:43:43, Radu-Cristian FOTESCU a écrit : Sorry for polluting the whole list, but as I don't have a mentor... That's not pollution, that's an interesting question (for which I have no answer :)). Samuel
Re: [Mageia-dev] new mgarepo version
Le mercredi 13 juillet 2011 00:30:41, nicolas vigier a écrit : Hello. mgarepo version 1.9.11 adds maintdb command : $ mgarepo maintdb --help Usage: Take maintainership of one package : mgarepo maintdb set [package] [login] Remove yourself from maintainer of a package : mgarepo maintdb set [package] nobody See who is maintainer of a package : mgarepo maintdb get [package] See the list of all packages with their maintainer : mgarepo maintdb get I used in in Mageia 1 using the package in updates_testing and it works well. Samuel
Re: [Mageia-dev] Generic 64-bit building question
Radu-Cristian FOTESCU a écrit :
Sorry for polluting the whole list, but as I don't have a mentor...
This is the first time I'm building 64-bit packages, and I'm running into the
following issue.
Requirements such as:
BuildRequires:qt4-devel
BuildRequires:python-devel
expand very well (automatically) on 64-bit into:
lib64qt4-devel
lib64python-devel
However, requirements such as:
BuildRequires:magick-devel
BuildRequires:chm-devel
BuildRequires:wmf-devel
do NOT expand into the existing:
lib64magick-devel
lib64chm-devel
lib64wmf-devel
therefore I have to use:
BuildRequires:%{_lib}magick-devel
BuildRequires:%{_lib}chm-devel
BuildRequires:%{_lib}wmf-devel
Of course(?), magick-devel%{?_isa} etc. does NOT help.
Question 1: why some libraries name do expand on 64-bit, whereas others don't?
Question 2: why some other libraries expand even when incorrect names are given?
E.g.:
BuildRequires:libpoppler-qt4-devel
accepts the installed lib:
lib64poppler-qt4-devel
although the name is incorrect, it should be limited to 32-bit!
Its' spec file must contain a virtual provides :
Provides: libpoppler-qt4-devel
A neat trick used sometimes to simplify requires.
Is the building system broken, am I stupid, or both?
You couldn't know if someone didn't tell you.
I'll try to get you a mentor :)
Thanks,
R-C aka beranger
Regards :)
--
André
Re: [Mageia-dev] Generic 64-bit building question
Le mercredi 13 juillet 2011 11:17:31, Radu-Cristian FOTESCU a écrit : Thanks. So I've got from 2 answers: You should use libmagick-devel and: Its' spec file must contain a virtual provides : Provides: libpoppler-qt4-devel Indeed, libmagick-devel, libwmf-devel, libchm-devel, libpoppler-qt4-devel, etc. do expand/match/find_provides correctly on 64-bit too! But then *why* some names have to be written as: qt4-devel and *not* libqt4-devel python-devel and *not* libpython-devel ? Isn't this an inconsistency? Moreover, excuse me, but I find it stupid to have a 64-bit lib called `libksane-devel`. This is its full 64-bit name, *not* the name from BuildRequires! It's another inconsistency IMHO. Of course, there is urpmq --provides to find out what resolves to the needed devel library, but still... Thank you all! R-C aka beranger Have you seen the discussion entitled [Mageia-dev] Standardising the virtual Provides in -devel packages from 5 days ago ? If Ahmad proposes to standardize them that means that we already know about some inconsistencies and want to improve this. Samuel
Re: [Mageia-dev] Generic 64-bit building question
13.07.2011 12:17, Radu-Cristian FOTESCU kirjutas:
Indeed, libmagick-devel, libwmf-devel, libchm-devel, libpoppler-qt4-devel, etc.
do expand/match/find_provides correctly on 64-bit too!
But then *why* some names have to be written as:
qt4-devel and *not* libqt4-devel
python-devel and *not* libpython-devel
?
Isn't this an inconsistency?
That's why there was discussion started, some time ago, in this list, to
create devel packages so that they will provide %{name}-devel and
lib%{name}-deve.
http://comments.gmane.org/gmane.linux.mageia.devel/6365
Moreover, excuse me, but I find it stupid to have a 64-bit lib called
`libksane-devel`.
This is devel package, not library itself, so it's OK.
--
Sander
Re: [Mageia-dev] Generic 64-bit building question
That's why there was discussion started, some time ago, in this list, to
create devel packages so that they will provide %{name}-devel and
lib%{name}-deve.
http://comments.gmane.org/gmane.linux.mageia.devel/6365
It isn't clear to me whether the situation to be fixed is Mageia-specific or
the inconsistency shows up also in Fedora, openSUSE, etc.
I thought it was about a small number of some peculiar libs, but it looks like
it's a more generic issue.
Moreover, excuse me, but I find it stupid to have a 64-bit lib called
`libksane-devel`.
This is devel package, not library itself, so it's OK.
I must admit I failed to understand your statement.
What's the difference between:
`libksane-devel` -- correct 64-bit name
and
`lib64djvulibre-devel` -- correct 64-bit name
?
Why not `lib64ksane-devel` ?
Thanks,
R-C aka beranger
Re: [Mageia-dev] new mgarepo version
On Wed, 13 Jul 2011, Samuel Verschelde wrote: Le mercredi 13 juillet 2011 00:30:41, nicolas vigier a écrit : Hello. mgarepo version 1.9.11 adds maintdb command : $ mgarepo maintdb --help Usage: Take maintainership of one package : mgarepo maintdb set [package] [login] Remove yourself from maintainer of a package : mgarepo maintdb set [package] nobody See who is maintainer of a package : mgarepo maintdb get [package] See the list of all packages with their maintainer : mgarepo maintdb get I used in in Mageia 1 using the package in updates_testing and it works well. Ok, it's moved to updates now.
Re: [Mageia-dev] Python Packaging Policy
philippe makowski a écrit : 2011/7/13 Michael schererm...@zarb.org: I would be in favor of treating python2 and python 3 as 2 differents languages. The rational is that : - we cannot garantee to have support for both - we will likely have some module who would be updated only on python 3 sooner or later - we will need to do upgrade of package at different time, since both python2 and python3 are released at different time. So rather than a complex scheme that will confuse packagers, just consider they are separate, and use the almost same policy ( with s/python/python3/ ) And how do you manage package that support both P2 and P3 ? (same source) If we use misc's approach, we could minimize the urgency of the conversion. If upstream supports both, we could either add a virtual provides in P2 and P3 for that (to be used only by such packages), or support just P3 (or maybe just P2). I don't know which is best, but I'd still like to help out. Regarding a review of all package, that sound like daunting task :/ yes, but do you see another solution ? we can have a priority list -- André
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
13.07.2011 13:02, Ahmad Samir kirjutas:
Using pkgconfig provides looks like an optimal option, we could start
now, whenever we touch a spec we change to the pkgconfig provides, and
gradually all the specs will be adapted.
And for the packages that don't have .pc files we add:
Provides: %{name}-devel = %{version}-release
Provides: lib%{name}-devel = %{version}-release
or we could add them to all packages whether they have .pc files or
not, but still always use pkgconfig() provides as BR in our specs.
WDYT?
+1
IMHO provides should be added anyway.
Who's gonna update policy? :)
--
Sander
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On Wed, 13 Jul 2011, Ahmad Samir wrote:
https://bugs.mageia.org/show_bug.cgi?id=2065
Using pkgconfig provides looks like an optimal option, we could start
now, whenever we touch a spec we change to the pkgconfig provides, and
gradually all the specs will be adapted.
And for the packages that don't have .pc files we add:
Provides: %{name}-devel = %{version}-release
Provides: lib%{name}-devel = %{version}-release
or we could add them to all packages whether they have .pc files or
not, but still always use pkgconfig() provides as BR in our specs.
Always adding the same provides regardless of what gets added
automatically is probably better and easier. I'd like to modify or clarify
your proposal a bit. When name starts with lib, use %{oname}-devel and
lib%{oname}-devel as provides. oname must be defined in the specfile as
the name without the lib prefix. That is usually already the case and this
macro is used as argument for mklibname.
Christiaan
Re: [Mageia-dev] Generic 64-bit building question
Why not `lib64ksane-devel` ?
You are right, the package name libksane-devel is incorrect. See
http://www.mageia.org/wiki/doku.php?id=libraries
Thanks for the pointer, Christiaan!
OTOH, as a self-apprentice packager, I've collected a number of pages to help
me with understanding the building issues, e.g. rpmlint -i warnings and
errors, etc.
From http://mageia.org/wiki/doku.php?id=packager_start
= http://mageia.org/wiki/doku.php?id=rpm_start
=
http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/index.html
Extras, bookmarked for consulting:
http://wiki.mandriva.com/en/Development/Packaging/Problems (!)
http://wiki.mandriva.com/en/Policies/Library
http://wiki.mandriva.com/en/Development/Howto/RPM (obsolete)
http://wiki.mandriva.com/en/Policies/RpmSpecProposal
http://fedoraproject.org/wiki/Packaging/Guidelines
http://fedoraproject.org/wiki/Common_Rpmlint_issues (!)
http://en.opensuse.org/openSUSE:Packaging_checks (!)
http://www.rpm.org/max-rpm/ (root)
http://www.rpm.org/max-rpm/p5208.html
http://www.rpm.org/max-rpm/s1-rpm-inside-macros.html
http://www.rpm.org/wiki/PackagerDocs/ArchDependencies
http://www.mageia.org/wiki/doku.php?id=libraries
Am I right to do this? Mageia's wiki pages are not clarifying enough.
E.g.
-- it does not say about %{buildroot} vs. $RPM_BUILD_ROOT used consistently,
ie, no mixing of %{buildroot} and $RPM_BUILD_ROOT, see
https://fedoraproject.org/wiki/Packaging/Guidelines#Using_.25.7Bbuildroot.7D_and_.25.7Boptflags.7D_vs_.24RPM_BUILD_ROOT_and_.24RPM_OPT_FLAGS
-- it does not say about desktop-file-install vs.desktop-file-validate see
https://fedoraproject.org/wiki/Packaging/Guidelines#desktop-file-install_usage
-- it does not tell the apprentice packagers about what rpmlint errors or
warnings should *never* be ignored (e.g. explicit-lib-dependency,
binary-or-shlib-defines-rpath, no-cleaning-of-buildroot, no-buildroot-tag,
hardcoded-library-path, etc.)
Actually, it was `invalid-build-requires` that made me inspect the 64-bit
library thing!
-- it does not tell what rpmlint errors/warnings *should* usually be ignored,
e.g.:
1. non-standard-group when the Group is valid in Mageia, e.g.: Graphics, Video,
...
2. no-documentation, no-manual-page-for-binary, manpage-not-compressed,
incorrect-fsf-address, file-not-utf8, name-repeated-in-summary, etc.
I'm still not sure about
library-without-ldconfig-postin/library-without-ldconfig-postun, because as
long as the SPRM was taken from MDV or F15... and as long as the installed
package works...
André, what do you think?
R-C aka beranger
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On 13 July 2011 12:15, Christiaan Welvaart c...@daneel.dyndns.org wrote:
On Wed, 13 Jul 2011, Ahmad Samir wrote:
https://bugs.mageia.org/show_bug.cgi?id=2065
Using pkgconfig provides looks like an optimal option, we could start
now, whenever we touch a spec we change to the pkgconfig provides, and
gradually all the specs will be adapted.
And for the packages that don't have .pc files we add:
Provides: %{name}-devel = %{version}-release
Provides: lib%{name}-devel = %{version}-release
or we could add them to all packages whether they have .pc files or
not, but still always use pkgconfig() provides as BR in our specs.
Always adding the same provides regardless of what gets added automatically
is probably better and easier. I'd like to modify or clarify your proposal a
bit. When name starts with lib, use %{oname}-devel and lib%{oname}-devel
as provides. oname must be defined in the specfile as the name without the
lib prefix. That is usually already the case and this macro is used as
argument for mklibname.
Christiaan
Agreed, liblib* shouldn't exist.
--
Ahmad Samir
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On Wed, 13 Jul 2011, Ahmad Samir wrote:
On 10 July 2011 10:03, Ahmad Samir ahmadsamir3...@gmail.com wrote:
On 8 July 2011 06:37, Ahmad Samir ahmadsamir3...@gmail.com wrote:
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
either both of them in _all_ packages, or one of them in _all_
packages, so that we don't have to check urpmq --provides all the
time. Personally, I am more inclined on having them both, so as not to
break already working specs.
For example:
$ urpmq --provides lib64gudev1.0-devel-166-5.mga1.x86_64
libgudev-devel[== 166-5.mga1]
pkgconfig(gudev-1.0)[== 166]
devel(libgudev-1.0(64bit))
lib64gudev1.0-devel[== 166-5.mga1]
lib64gudev1.0-devel(x86-64)[== 166-5.mga1]
only libgudev-devel, so if I put BR gudev-devel in a spec it won't
work, whereas I'd expect it to work since some other packages have
such similar provides:
$ urpmq --provides lib64dbus-1-devel
libdbus-1-devel[== 1.4.1-3.mga1]
libdbus-devel[== 1.4.1-3.mga1]
dbus-devel[== 1.4.1-3.mga1]
[...]
WDYT?
(If we agree to go one way or the other, will just fix them gradually
over time).
--
Ahmad Samir
Adding to the above, spturtle has suggested using pkgconfig()
provides: https://bugs.mageia.org/show_bug.cgi?id=2065
--
Ahmad Samir
Using pkgconfig provides looks like an optimal option, we could start
now, whenever we touch a spec we change to the pkgconfig provides, and
gradually all the specs will be adapted.
And for the packages that don't have .pc files we add:
Provides: %{name}-devel = %{version}-release
Provides: lib%{name}-devel = %{version}-release
or we could add them to all packages whether they have .pc files or
not, but still always use pkgconfig() provides as BR in our specs.
I think it's better to use %{name}-devel for packages which don't have
pkgconfig files. And keep pkgconfig() provides for packages with .pc
files.
Re: [Mageia-dev] new mgarepo version
Ok, it's moved to updates now. Nicolas are you interested in mgarepo bash_completion? I imported it from mdvsys... Well your changes have to be added though... signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] new mgarepo version
hi, On 11/07/13 00:30 +0200, nicolas vigier wrote: mgarepo version 1.9.11 adds maintdb command : $ mgarepo maintdb --help Usage: Take maintainership of one package : mgarepo maintdb set [package] [login] Remove yourself from maintainer of a package : mgarepo maintdb set [package] nobody See who is maintainer of a package : mgarepo maintdb get [package] See the list of all packages with their maintainer : mgarepo maintdb get great. will there be some automatic assignment, such as 1st to upload a package gets ownership? will it supports multiple assignment, or teams? jérôme
Re: [Mageia-dev] new mgarepo version
On Wed, 13 Jul 2011, Jerome Quelin wrote: hi, On 11/07/13 00:30 +0200, nicolas vigier wrote: mgarepo version 1.9.11 adds maintdb command : $ mgarepo maintdb --help Usage: Take maintainership of one package : mgarepo maintdb set [package] [login] Remove yourself from maintainer of a package : mgarepo maintdb set [package] nobody See who is maintainer of a package : mgarepo maintdb get [package] See the list of all packages with their maintainer : mgarepo maintdb get great. will there be some automatic assignment, such as 1st to upload a package gets ownership? Yes, that's what is done for new packages. will it supports multiple assignment, or teams? It's not supported yet. But I think it could be added.
Re: [Mageia-dev] [RPM] cauldron core/release unknown-horizons-2011-1.mga2
On Wednesday 13 July 2011 09:49:01 Samuel Verschelde wrote: [...] The group Amusements/Games/Strategy/Real Time doesn't exist in Mageia. 3 different packagers haven't seen this ? :) Maybe we should check it via rpmlint on package upload ? -- Balcaen John
Re: [Mageia-dev] new mgarepo version
On 13 July 2011 13:53, nicolas vigier bo...@mars-attacks.org wrote: On Wed, 13 Jul 2011, Angelo Naselli wrote: Ok, it's moved to updates now. Nicolas are you interested in mgarepo bash_completion? I imported it from mdvsys... Yes, I think you can add it. FWIW, I've been using the attached bash-completion file for some months now, however since I am not a bash-completion guru I didn't want to plague anyone else with any things I've messed up with it. @Angelo: Feel free to use anything from it, if any, to add to the file you have (note that I disabled the auto completion of package names in SVN since it's too slow for taste). -- Ahmad Samir mgarepo Description: Binary data
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On Tue, 12 Jul 2011, Ernest N. Wilcox Jr. wrote: Date: Tue, 12 Jul 2011 11:16:24 +0200 From: Wolfgang Bornath molc...@googlemail.com To: Mageia development mailing-list mageia-dev@mageia.org Subject: Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs? Message-ID: CA+h4nj6KtYu8vUFcZ4mWUO08J5ZyxB5XnN2bsSLoqm8R7w6E=w...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 2011/7/12 andre999 and...@laposte.net: Wolfgang Bornath a ?crit : 2011/7/9 andre999and...@laposte.net: Wolfgang Bornath a ?crit : 2011/7/8 Thorsten van Liltv...@gmx.de: Am 08.07.2011 10:42, schrieb Wolfgang Bornath: 2011/7/8 James Kerrj...@jkerr82508.free-online.co.uk: This thread has strayed far from the original question, which could be re-stated as: Should tainted free software and tainted nonfree software be commingled in a single tainted repository? ... Besides, tainted is not only about patents, it's also about software which is illegal in certain countries (like libdvdcss). Ok, a relatively limited application. So in all, maybe a handful of packages at most should be in tainted. So why do we have more than 150 ? Sorry, but I do not understand your way of thinking. If a law exists it exists. It does not matter to a law whether it is likely to be enforced. Period. This is not paranoia, it is a matter of mind set. If robbery would not be prosecuted, would you go out and earn your doe by taking away handbags from old ladies? You would not, because it is wrong. For those who are living in countries where patents are valid and accepted by the law, using a patented software is wrong. So you must accept that there are people who would not do it. Telling them how they should think about it is not ours. That's why we have the tainted repo. -- wobo +1 I live in the USA, and while I do not personally support the concept of software pantents, I also do not want to violate them as long as they are leagally recognized where I live. For me, this is not a matter of risk, but one of ethics, morality, and respect. IMHO, the fact that my Countries Society recognizes patents as being legally binding makes it my responsibility to honor them, so I want to know if a software package may be affected by one or more patent(s) before I install it on my computer. If I know that (for example) package foo is affected by a patent, I can search for the patent holder, and make contact to request permission to ust the software, then abide with their response. This way, I fulfill my obligation to ask permission before using software that is (or may be) affected by some one elses property. I would no more use patented software without permission here in the USA than I would take my neighbor's lawnmower to cut my grass without his permission. I understand that the following may not be practicable, but I would like all software that is affected by a patent (and perhaps other licensing or copyright restrictions) to be placed in a restricted (tainted) repository. Also I would like to see patent (or contact) information in the software package's description to help facilitate my ability to ask permission to use the software. By doing these things, Mageia is doing more to support my ability to live by my personal convictions than to support patent law. I think we should not do that. Because we probably have more useful things to do than documenting patents and helping patent holders. And because it doesn't help users, on the contrary, it makes it more dangerous for them to use the software, because they cannot say they didn't know about the patent.
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On 13 July 2011 14:27, nicolas vigier bo...@mars-attacks.org wrote: On Tue, 12 Jul 2011, Ernest N. Wilcox Jr. wrote: Date: Tue, 12 Jul 2011 11:16:24 +0200 From: Wolfgang Bornath molc...@googlemail.com To: Mageia development mailing-list mageia-dev@mageia.org Subject: Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs? Message-ID: CA+h4nj6KtYu8vUFcZ4mWUO08J5ZyxB5XnN2bsSLoqm8R7w6E=w...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 2011/7/12 andre999 and...@laposte.net: Wolfgang Bornath a ?crit : 2011/7/9 andre999and...@laposte.net: Wolfgang Bornath a ?crit : 2011/7/8 Thorsten van Liltv...@gmx.de: Am 08.07.2011 10:42, schrieb Wolfgang Bornath: 2011/7/8 James Kerrj...@jkerr82508.free-online.co.uk: This thread has strayed far from the original question, which could be re-stated as: Should tainted free software and tainted nonfree software be commingled in a single tainted repository? ... Besides, tainted is not only about patents, it's also about software which is illegal in certain countries (like libdvdcss). Ok, a relatively limited application. So in all, maybe a handful of packages at most should be in tainted. So why do we have more than 150 ? Sorry, but I do not understand your way of thinking. If a law exists it exists. It does not matter to a law whether it is likely to be enforced. Period. This is not paranoia, it is a matter of mind set. If robbery would not be prosecuted, would you go out and earn your doe by taking away handbags from old ladies? You would not, because it is wrong. For those who are living in countries where patents are valid and accepted by the law, using a patented software is wrong. So you must accept that there are people who would not do it. Telling them how they should think about it is not ours. That's why we have the tainted repo. -- wobo +1 I live in the USA, and while I do not personally support the concept of software pantents, I also do not want to violate them as long as they are leagally recognized where I live. For me, this is not a matter of risk, but one of ethics, morality, and respect. IMHO, the fact that my Countries Society recognizes patents as being legally binding makes it my responsibility to honor them, so I want to know if a software package may be affected by one or more patent(s) before I install it on my computer. If I know that (for example) package foo is affected by a patent, I can search for the patent holder, and make contact to request permission to ust the software, then abide with their response. This way, I fulfill my obligation to ask permission before using software that is (or may be) affected by some one elses property. I would no more use patented software without permission here in the USA than I would take my neighbor's lawnmower to cut my grass without his permission. I understand that the following may not be practicable, but I would like all software that is affected by a patent (and perhaps other licensing or copyright restrictions) to be placed in a restricted (tainted) repository. Also I would like to see patent (or contact) information in the software package's description to help facilitate my ability to ask permission to use the software. By doing these things, Mageia is doing more to support my ability to live by my personal convictions than to support patent law. I think we should not do that. Because we probably have more useful things to do than documenting patents and helping patent holders. And because it doesn't help users, on the contrary, it makes it more dangerous for them to use the software, because they cannot say they didn't know about the patent. (However, each package has a URL field, with a link to the upstream web site, that could be a good starting point for a search for those who wanna do it). -- Ahmad Samir
Re: [Mageia-dev] new mgarepo version
FWIW, I've been using the attached bash-completion file for some
months now, however since I am not a bash-completion guru I didn't
want to plague anyone else with any things I've messed up with it.
Great that means it works :)
I'm not a bash-completion guru as well, but i thought it was useful
for someone else, since we're two... that means we could be more :)
@Angelo: Feel free to use anything from it, if any, to add to the file
you have (note that I disabled the auto completion of package names
in SVN since it's too slow for taste).
The attached one has it activated, i believe it is the same as yours but
for that change.
FWIW i find slower urpmi bash_complention, expecially if i want to
install a local package - i always forget ./XXX- you can figure out :)
HTH,
Angelo
# mgarepo(1) completion
#
_cauldron_packages()
{
COMPREPLY=( $( compgen -W '$(svn ls \
svn+ssh://svn.mageia.org/svn/packages/cauldron \
| sed -e s|/$|| )' -- $cur ) )
}
_mgarepo_actions()
{
COMPREPLY=( $( compgen -W 'import create checkout co update info log \
tag submit extract sync commit ci build strip mass-update \
help' -- $cur ) )
}
_mgarepo()
{
local cur prev command options i
COMPREPLY=()
cur=${COMP_WORDS[COMP_CWORD]}
if [[ $COMP_CWORD -eq 1 ]] ; then
_mgarepo_actions
else
prev=${COMP_WORDS[COMP_CWORD-1]}
case $prev in
-@(c|-config))
_filedir
return 0
;;
esac
command=${COMP_WORDS[1]}
if [[ $cur == -* ]]; then
# possible options for the command
case $command in
@(import|create))
options=--revision --distribution \
--branch --message --nocommit
;;
@(checkout|co|info|log))
options=--revision --distribution \
--branch
;;
update)
options=--revision --distribution \
--branch --release \
--spec-line-expression \
--keep-on-failure --message \
--target --nocommit --nosubmit
;;
mass-update)
options=--include --exclude \
--keep-on-failure --nocommit \
--nosubmit
;;
tag)
options=--revision
;;
submit)
options=--revision --distribution \
--branch --target
;;
extract)
options=--revision --distribution \
--branch --destdir --noprefix
;;
@(commit|ci))
options=--sync --message
;;
esac
options=$options --verbose -v --config -c --help
COMPREPLY=( $( compgen -W $options -- $cur ) )
else
case $command in
help)
_mgarepo_actions
return 0
;;
import)
_filedir 'src.rpm'
return 0
;;
@(create|checkout|co|update|info|log|tag|submit|extract))
_cauldron_packages
return 0
;;
@(sync|commit|ci))
_filedir -d
return 0
;;
@(build|strip))
Re: [Mageia-dev] [RPM] cauldron core/release unknown-horizons-2011-1.mga2
mercoledì 13 luglio 2011 alle 13:53, Balcaen John ha scritto: On Wednesday 13 July 2011 09:49:01 Samuel Verschelde wrote: [...] The group Amusements/Games/Strategy/Real Time doesn't exist in Mageia. 3 different packagers haven't seen this ? :) Maybe we should check it via rpmlint on package upload ? Good point Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] new mgarepo version
Le 13/07/2011 00:30, nicolas vigier a écrit : Hello. mgarepo version 1.9.11 adds maintdb command : $ mgarepo maintdb --help Usage: Take maintainership of one package : mgarepo maintdb set [package] [login] Remove yourself from maintainer of a package : mgarepo maintdb set [package] nobody See who is maintainer of a package : mgarepo maintdb get [package] See the list of all packages with their maintainer : mgarepo maintdb get Hi, I'm trying to do a anonymous checkout with mgarepo and ... it doesn't work (anonymous co because I don't have a packager account) What is the right configuration I need to put in my /etc/mgarepo.conf Regards -- Marianne Lombard (Jehane) Mageia User - Mageia french translation team Inside every fat girl, there is a thin girl waiting to get out (and a lot of chocolate) - Terry Pratchett
Re: [Mageia-dev] [RPM] cauldron core/release unknown-horizons-2011-1.mga2
On 13 July 2011 13:53, Balcaen John mik...@mageia.org wrote: On Wednesday 13 July 2011 09:49:01 Samuel Verschelde wrote: [...] The group Amusements/Games/Strategy/Real Time doesn't exist in Mageia. 3 different packagers haven't seen this ? :) Maybe we should check it via rpmlint on package upload ? s/upload/submit/. -- Balcaen John -- Ahmad Samir
Re: [Mageia-dev] new mgarepo version
On 13 July 2011 15:27, Marianne Lombard maria...@tuxette.fr wrote: Le 13/07/2011 00:30, nicolas vigier a écrit : Hello. mgarepo version 1.9.11 adds maintdb command : $ mgarepo maintdb --help Usage: Take maintainership of one package : mgarepo maintdb set [package] [login] Remove yourself from maintainer of a package : mgarepo maintdb set [package] nobody See who is maintainer of a package : mgarepo maintdb get [package] See the list of all packages with their maintainer : mgarepo maintdb get Hi, I'm trying to do a anonymous checkout with mgarepo and ... it doesn't work (anonymous co because I don't have a packager account) What is the right configuration I need to put in my /etc/mgarepo.conf Regards (Reposting what I posted on IRC): $ mkdir -p ~/.mgarepo; cp /etc/mgarepo.conf ~/.mgarepo/config Then edit ~/.mgarepo/config and change: repository = svn+ssh://svn.mageia.org/svn/packages/ binaries-repository = svn+ssh://svn.mageia.org/svn/binrepos to repository = svn://svn.mageia.org/svn/packages/ binaries-repository = svn://svn.mageia.org/svn/binrepos -- Marianne Lombard (Jehane) Mageia User - Mageia french translation team Inside every fat girl, there is a thin girl waiting to get out (and a lot of chocolate) - Terry Pratchett -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release unknown-horizons-2011-1.mga2
On Wed, Jul 13, 2011 at 3:32 PM, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 13 July 2011 13:53, Balcaen John mik...@mageia.org wrote: On Wednesday 13 July 2011 09:49:01 Samuel Verschelde wrote: [...] The group Amusements/Games/Strategy/Real Time doesn't exist in Mageia. 3 different packagers haven't seen this ? :) Maybe we should check it via rpmlint on package upload ? s/upload/submit/. yes this would prevent to build for nothing
Re: [Mageia-dev] [RPM] cauldron core/release unknown-horizons-2011-1.mga2
On Wednesday 13 July 2011 16:32:52 Ahmad Samir wrote: On 13 July 2011 13:53, Balcaen John mik...@mageia.org wrote: On Wednesday 13 July 2011 09:49:01 Samuel Verschelde wrote: [...] The group Amusements/Games/Strategy/Real Time doesn't exist in Mageia. 3 different packagers haven't seen this ? :) Maybe we should check it via rpmlint on package upload ? s/upload/submit/. Indeed, i thought about that but wrote upload. -- Balcaen John
Re: [Mageia-dev] new mgarepo version
Le 13/07/2011 15:34, Ahmad Samir a écrit : (Reposting what I posted on IRC): $ mkdir -p ~/.mgarepo; cp /etc/mgarepo.conf ~/.mgarepo/config Then edit ~/.mgarepo/config and change: repository = svn+ssh://svn.mageia.org/svn/packages/ binaries-repository = svn+ssh://svn.mageia.org/svn/binrepos to repository = svn://svn.mageia.org/svn/packages/ binaries-repository = svn://svn.mageia.org/svn/binrepos It works but the comment in the config file is ... what you MUST not do ## uncomment it in case you don't have a account in the Mageia build system: #mirror = http://svn.mageia.org/svn/packages/cauldron/ I will open the bugreport Marianne -- Marianne Lombard (Jehane) Mageia User - Mageia french translation team Inside every fat girl, there is a thin girl waiting to get out (and a lot of chocolate) - Terry Pratchett
Re: [Mageia-dev] new mgarepo version
On 13 July 2011 16:16, Marianne Lombard maria...@tuxette.fr wrote: Le 13/07/2011 15:34, Ahmad Samir a écrit : (Reposting what I posted on IRC): $ mkdir -p ~/.mgarepo; cp /etc/mgarepo.conf ~/.mgarepo/config Then edit ~/.mgarepo/config and change: repository = svn+ssh://svn.mageia.org/svn/packages/ binaries-repository = svn+ssh://svn.mageia.org/svn/binrepos to repository = svn://svn.mageia.org/svn/packages/ binaries-repository = svn://svn.mageia.org/svn/binrepos It works but the comment in the config file is ... what you MUST not do ## uncomment it in case you don't have a account in the Mageia build system: #mirror = http://svn.mageia.org/svn/packages/cauldron/ I will open the bugreport Marianne Yeah, that's a remnant of repsys, which wouldn't work with our split binrepos, IINM. -- Marianne Lombard (Jehane) Mageia User - Mageia french translation team Inside every fat girl, there is a thin girl waiting to get out (and a lot of chocolate) - Terry Pratchett -- Ahmad Samir
Re: [Mageia-dev] new mgarepo version
hmm command update is wrong, mgarepo update fails mgarepo update error: invalid command 'update' Sorry Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] new mgarepo version
Op woensdag 13 juli 2011 00:30:41 schreef nicolas vigier: Hello. mgarepo version 1.9.11 adds maintdb command : $ mgarepo maintdb --help Usage: Take maintainership of one package : mgarepo maintdb set [package] [login] Remove yourself from maintainer of a package : mgarepo maintdb set [package] nobody See who is maintainer of a package : mgarepo maintdb get [package] See the list of all packages with their maintainer : mgarepo maintdb get Nice! Can we also have a See all your packages (or packages from other user login): mgarepo maintdb show [login] Is this process also available for novice packagers?
Re: [Mageia-dev] new mgarepo version
On Wed, 13 Jul 2011, Maarten Vanraes wrote: Can we also have a See all your packages (or packages from other user login): mgarepo maintdb show [login] It's already possible with : mgarepo maintdb get | grep :login Is this process also available for novice packagers? Novice packagers cannot be maintainer. But content of maintdb is also available at this url : http://pkgsubmit.mageia.org/data/maintdb.txt
[Mageia-dev] Tonight's meeting
Hi, I will not at the mageia packagers meeting, and I'm sorry. I will at the next. Have a good meeting! (I'll read logs)
Re: [Mageia-dev] new mgarepo version
Op woensdag 13 juli 2011 20:46:30 schreef nicolas vigier: On Wed, 13 Jul 2011, Maarten Vanraes wrote: Can we also have a See all your packages (or packages from other user login): mgarepo maintdb show [login] It's already possible with : mgarepo maintdb get | grep :login Is this process also available for novice packagers? yes, good enough, Novice packagers cannot be maintainer. But content of maintdb is also available at this url : http://pkgsubmit.mageia.org/data/maintdb.txt huh, novice packagers cannot be maintainer? I've been maintainer in mandriva before for my packages, even though i was novice? after all, i can't exactly be a burden to my mentor for all those things? Please allow me to be maintainer of those few packages that i have.
Re: [Mageia-dev] new mgarepo version
Op woensdag 13 juli 2011 20:46:30 schreef nicolas vigier: [...] Is this process also available for novice packagers? Novice packagers cannot be maintainer. But content of maintdb is also available at this url : http://pkgsubmit.mageia.org/data/maintdb.txt I would like novices to be allowed to grab maintainership as well for the following 3 reasons: - easier as a padawan to check your packages and followup to see which have to be updated/backported - the day a padawan gets full packager, he would have to set all the packages, and it might not be easy to find them, or even alot of work, if the mentor has alot of them - bug reports would then be assigned to the mentor instead of the novice, which would perhaps give a bit more work towards mentor to notify his novice about it. WDYT?
Re: [Mageia-dev] new mgarepo version
On Tue, Jul 12, 2011 at 19:30, nicolas vigier bo...@mars-attacks.orgwrote: Hello. mgarepo version 1.9.11 adds maintdb command : $ mgarepo maintdb --help Usage: Take maintainership of one package : mgarepo maintdb set [package] [login] Remove yourself from maintainer of a package : mgarepo maintdb set [package] nobody See who is maintainer of a package : mgarepo maintdb get [package] See the list of all packages with their maintainer : mgarepo maintdb get A bit hijacking the thread, but I have a quick question - would it be possible to have repsys on mageia? There is mgarepo on Mandriva for the ones willing to work with Mageia repositories from Mandriva; is it too much to ask for the opposite? (E.g., for the ones willing to work on Mandriva repos from Mageia)? -- Eugeni Dodonov http://eugeni.dodonov.net/
Re: [Mageia-dev] [Mageia 2 specifications] Systemd or not systemd
On Tue, Jul 12, 2011 at 09:48, Colin Guthrie mag...@colin.guthr.ie wrote:
'Twas brillig, and Eugeni Dodonov at 12/07/11 13:15 did gyre and gimble:
If nobody objects, I could help with that. Mandriva certainly gave a
large experience on how to integrate systemd into the system without
killing traditional sysvinit alternative.
It would also be extremely interested to have native systemd services
which use most of systemd features (like sound and alsa scripts, which
we discussed with Colin and Andrey Borzenkov some months ago but never
got to implement properly).
Massive +1 for systemd and massive +1 Eugeni wanting to help out! \o/
I'll try and help out in bits and bobs too, tho' time is always a problem!
Ok, some n00b questions arise from my part, sorry if they seem too basic - I
am only catching up with mga style of development :).
Systemd 30 is out, with lots of nice changes, so I think we should use it
now as we are quite early in the release cycle. It is working on my machine,
but before doing something about it, I prefer to hear opinions :).
Firstly, systemdrequires udev = 172, what is the policy to update it?
According to 'mgarepo maintdb get udev', it has no maintainers, does anyone
objects if I grab/update it as well?
Secondly, what should be the correct way of supporting systemd in a package?
In Mandriva, I thought on adding a --with flag to enable/disable systemd,
but in most cases it does (almost) nothing. All services which want to
support systemd only need to place their files into /lib/systemd - and
that's it. Should we support opting-out of systemd in specs? I believe
fcrozat is having the same dilemma in SuSE now as well, and he settled on
some common packaging macros.
Almost finally, should the systemd files belong to the main package, the
same way as they do with initscripts-based one (e.g., the package would
provide /lib/systemd/system/%{name}.service together with
%_sysconfig/rc.d/init.d/%{name} for example), with no extra subpackages or
flags - or should all systemd-specific files go into %{name}-systemd package
for example? What do you think?
And finally, what does seems to be the best way of starting to use systemd
in cauldron? I have thought on 3 alternatives:
- easy way, only having it packaged, but not
providing/obsoleting/conflicting with sysvinit. This way, it will work when
kernel is booted with init=/bin/systemd (the least invasive way)
- compatible way (like in Mandriva) - it is available, systemd-sysvinit
conflicts with sysvinit, so if someone installs systemd-sysvinit, sysvinit
goes away and systemd is run by default. This seems to be the most sane way
to me (but I could be biased), and it is easiest one for testing
- ultimate way - systemd provides and obsoletes sysvinit and its goodies.
This way, systemd will be the only one (e.g., highlander style). This is how
fedora did it if I am not mistaken, but I am not sure if it the best way.
So, that's it for now from my part..
Opinions?
--
Eugeni Dodonov
http://eugeni.dodonov.net/
Re: [Mageia-dev] [Mageia 2 specifications] Systemd or not systemd
On Wed, Jul 13, 2011 at 22:47, Eugeni Dodonov eug...@dodonov.net wrote: Firstly, systemdrequires udev = 172, what is the policy to update it? According to 'mgarepo maintdb get udev', it has no maintainers, does anyone objects if I grab/update it as well? (I forgot to mention that it is already up and running fine on my machine). -- Eugeni Dodonov http://eugeni.dodonov.net/
