Re: [Mageia-dev] Compatibility: %mdkversion macro?
Op zondag 16 januari 2011 01:19:29 schreef Samuel Verschelde:
Le dimanche 16 janvier 2011 00:07:56, Anssi Hannula a écrit :
Hi all!
Should we have a %mdkversion (and %mdkver/%mdvver) that is hardcoded to
201100 for the time being, or should we not have one at all?
Not having it will cause any src.rpms that have any
%if %mdkversion x to fail to build.
I'm strongly in favor of having it for compatibility reasons, so that
most MDV src.rpms keep building on Mageia for the time being, including
those provided by any 3rd party packagers.
Not having the macro will cause us to lose that compatibility for very
little benefit, IMO. It could maybe be removed after several releases,
but not before.
However, it seems blino disagreed with this, and he thinks we should not
have these macros at all.
What do other people think?
If not having those macros means we can't compile mdv SRPMS on mageia, then
I'd prefer we keep it.
Regards
Samuel Verschelde
i would prefer to have some kind of %{_vendor}%{_vendor_release} type of
thing, we could easily have mandriva and mageia use the same tags for this.
after all, there will be a time where we will need similar compatibility. and
it's be easier for later to possibly have similar .spec files with other
vendors: PLF? OpenSuse, Fedora, ...
Re: [Mageia-dev] Compatibility: %mdkversion macro?
In data domenica 16 gennaio 2011 00:07:56, Anssi Hannula ha scritto: Hi all! Should we have a %mdkversion (and %mdkver/%mdvver) that is hardcoded to 201100 for the time being, or should we not have one at all? Not having it will cause any src.rpms that have any %if %mdkversion x to fail to build. I'm strongly in favor of having it for compatibility reasons, so that most MDV src.rpms keep building on Mageia for the time being, including those provided by any 3rd party packagers. Not having the macro will cause us to lose that compatibility for very little benefit, IMO. It could maybe be removed after several releases, but not before. I believe you're right at the moment, now that we're importing things, but after the very first time, starts becoming nonsense since i believe we're going to work on our packages distro per distro not taking every time srpms from mandriva as we're doing now. However, it seems blino disagreed with this, and he thinks we should not have these macros at all. the good should be to have some common macros the allows us to build packages form one distro to other. I ported in my rhel 4 and 5 mkrel to get most compatibility to mandriva specs. But now fedora (hope rhel 6 as well) uses %dist so why not to use a common point to that macro and extend compatibility? What do other people think? I think we should think to a transition solution at least... -- Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Compatibility: %mdkversion macro?
Le dimanche 16 janvier 2011 11:26:54, Angelo Naselli a écrit : In data domenica 16 gennaio 2011 00:07:56, Anssi Hannula ha scritto: Hi all! Should we have a %mdkversion (and %mdkver/%mdvver) that is hardcoded to 201100 for the time being, or should we not have one at all? Not having it will cause any src.rpms that have any %if %mdkversion x to fail to build. I'm strongly in favor of having it for compatibility reasons, so that most MDV src.rpms keep building on Mageia for the time being, including those provided by any 3rd party packagers. Not having the macro will cause us to lose that compatibility for very little benefit, IMO. It could maybe be removed after several releases, but not before. I believe you're right at the moment, now that we're importing things, but after the very first time, starts becoming nonsense since i believe we're going to work on our packages distro per distro not taking every time srpms from mandriva as we're doing now. Well, it may be a naïve hope, but I thought I could maintain the same spec file for Mandriva and Mageia for my packages. It's not just a matter of importing SRPMS from Mandriva to Mageia. However, it seems blino disagreed with this, and he thinks we should not have these macros at all. the good should be to have some common macros the allows us to build packages form one distro to other. I ported in my rhel 4 and 5 mkrel to get most compatibility to mandriva specs. But now fedora (hope rhel 6 as well) uses %dist so why not to use a common point to that macro and extend compatibility? OK with that. Samuel
[Mageia-dev] Python Packaging Policy
Hi, I though that I can find more time to work on this week end, but unfortunately it was not the case. The Mandriva doc is really not a good starter (http://wiki.mandriva.com/en/Python_packaging_policy) so I propose to use the Fedora one (http://fedoraproject.org/wiki/Packaging:Python) with some cleaning. Can we provide same macros as in In Fedora 13 and greater ? Do you see any major problem with the Fedora policy ?
Re: [Mageia-dev] Importing RPM Spec File Syntax
On Sat, Jan 15, 2011 at 02:10:08PM +0100, Maarten Vanraes wrote: Op zaterdag 15 januari 2011 14:01:51 schreef John Balcaen: [...] Regarding the spec we've got at least a major difference in our kde's spec For example not all the %define are localized at the top of the spec,especially thoses for macro libname : it's easier for me to have some of them in the same part.Maybe it's due to our will massive libification, but having more then 15 %define for macro libname without knowing which package is affected. Also maybe others can find useful to have the %files list for every package listed under their description (instead of having all of them after the %prep,%build etc part ) Regards, Personally, i agree regarding the %files part to be under their respective %description and having build stuff on the bottom part. I like that idea. regarding defines, i don't understand completely, but i am in favor of having all defines up top. Well, I think mikala’s got a point there. Experience showed that having defines put where they are relevant simply improved readability. OTOH, the spec does not say anything apart “it should be on top”. I think we should not enforce define on top if we have no valid reason to have it like this. Also, a way to improve readability regarding subpackages is to systematically add a line of comment between them like this : #--- I’ll add a section about subpackages, because they’re not mentionned in the current policy. Regards, -- Rémy CLOUARD () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments pgpDGnwg3nQCF.pgp Description: PGP signature
Re: [Mageia-dev] mageia sound tasks
Hi, 'Twas brillig, and Sascha Schneider at 21/12/10 21:06 did gyre and gimble: Wiki updated http://www.mageia.org/wiki/doku.php?id=soundstudio Sorry I've been a little quiet of late. Email backlog + work commitments + $EXCUSE. I've added a comment to the wiki page about the suggestion of editing /etc/sysconfig/pulseaudio. This file is more or less outdated now. I should probably tidy things up and remove it. Nowadays we use Sound Profiles which should be an ideal scenario to allow you to package up various tweaks and tricks with symlinks and get them activated automatically when the user switches to a different sound profile. The sound profiles are based on the alternatives system. See: update-alternatives --display soundprofile Ultimately you can read the current profile.conf here: CONFIG=/etc/sound/profiles/current/profile.conf But to create a new profile, just the pulseaudio package. It's basically just a matter of creating a folder /etc/sound/profiles/myprofile When you register it with the alternatives system you give it a priority. I would suggest that if the package containing the soundstudio profile is not installed by default then it can have a higher priority than the pulseaudio one, and thus automatically activate when installed. Things like udev rules and such like could be installed by the package but only activated when the profile is actually active (e.g. via symlinks) - you may want to put dummy udev rules in place for the other profiles too to make the symlinks always resolve. Also disabling libcanberra (by exporting CANBERRA_DRIVER=null) would also be sensible - event sounds and such like are obviously highly pointless/evil when doing pro-audio work! Currently the driver is changed via this mechanism for a pure alsa profile (CANBERRA_DRIVER=alsa). HTHs Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] mageia sound tasks
The idea with the sound-profile really sounds good, didn't knew about that. Regards, sascha 2011/1/16 Colin Guthrie mag...@colin.guthr.ie: Hi, 'Twas brillig, and Sascha Schneider at 21/12/10 21:06 did gyre and gimble: Wiki updated http://www.mageia.org/wiki/doku.php?id=soundstudio Sorry I've been a little quiet of late. Email backlog + work commitments + $EXCUSE. I've added a comment to the wiki page about the suggestion of editing /etc/sysconfig/pulseaudio. This file is more or less outdated now. I should probably tidy things up and remove it. Nowadays we use Sound Profiles which should be an ideal scenario to allow you to package up various tweaks and tricks with symlinks and get them activated automatically when the user switches to a different sound profile. The sound profiles are based on the alternatives system. See: update-alternatives --display soundprofile Ultimately you can read the current profile.conf here: CONFIG=/etc/sound/profiles/current/profile.conf But to create a new profile, just the pulseaudio package. It's basically just a matter of creating a folder /etc/sound/profiles/myprofile When you register it with the alternatives system you give it a priority. I would suggest that if the package containing the soundstudio profile is not installed by default then it can have a higher priority than the pulseaudio one, and thus automatically activate when installed. Things like udev rules and such like could be installed by the package but only activated when the profile is actually active (e.g. via symlinks) - you may want to put dummy udev rules in place for the other profiles too to make the symlinks always resolve. Also disabling libcanberra (by exporting CANBERRA_DRIVER=null) would also be sensible - event sounds and such like are obviously highly pointless/evil when doing pro-audio work! Currently the driver is changed via this mechanism for a pure alsa profile (CANBERRA_DRIVER=alsa). HTHs Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
[Mageia-dev] What to do for software having MDV/Mandriva in name
Hi, I am supposed to be the maintainers of this software, required by base of the system: perl-MDV-Distribconf-4.02-1mdv2010.1.src.rpm perl-MDV-Packdrakeng-1.13-5mdv2010.1.src.rpm Should we remove the 'MDV' part ? Notice changing this is not only about the rpm itself, MDV is part of the software and changing is not an easy task. Also the software is provided (at time, and until we do not redo ours) by Mandriva and has been upload to CPAN under this name. So I am favor to import it with this name (we didn't rename RPM because it mean RedHat Package Manager...). Does everyone agree with that ? -- Olivier Thauvin CNRS - LATMOS ♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖ pgp7uV0vz6Uvf.pgp Description: PGP signature
Re: [Mageia-dev] What to do for software having MDV/Mandriva in name
On 1/16/11, Olivier Thauvin nanar...@nanardon.zarb.org wrote: So I am favor to import it with this name (we didn't rename RPM because it mean RedHat Package Manager...). At the risk of being called pedantic, RPM _now_ stands for RPM Package Manager in all its GNU recursive acronym goodness (GNU's Not Unix, WINE Is Not an Emulator, etc.) for precisely the reason you raise, so people would not use/drop it because of the RedHat name. Where MDK or drak is part of the application name (and hence the package name), it should not be changed because that is its name and Mandriva did, in fact, create it. When Mageia writes its own applications (mageiahelp, diskmagia, mageiasound) or forks the MDK/drak application (and starts separate, non-cooperative development), then change the name. Otherwise, it might be seen as if we are trying to hide something if only the name appears to change just to obscure the Mandriva origins.. For items that are simply branded, those names should be changed, but not necessarily in the first Mageia release unless copyrighted items are involved. -- Hoyt
Re: [Mageia-dev] Compatibility: %mdkversion macro?
On Saturday, January 15, 2011 04:07:56 pm Anssi Hannula wrote: Hi all! Should we have a %mdkversion (and %mdkver/%mdvver) that is hardcoded to 201100 for the time being, or should we not have one at all? Not having it will cause any src.rpms that have any %if %mdkversion x to fail to build. I'm strongly in favor of having it for compatibility reasons, so that most MDV src.rpms keep building on Mageia for the time being, including those provided by any 3rd party packagers. Not having the macro will cause us to lose that compatibility for very little benefit, IMO. It could maybe be removed after several releases, but not before. However, it seems blino disagreed with this, and he thinks we should not have these macros at all. What do other people think? There is also an %exclude in the file section that doesn't work on mageia -- Thomas
Re: [Mageia-dev] Compatibility: %mdkversion macro?
On Mon, Jan 17, 2011 at 5:51 AM, Thomas Spuhler tho...@btspuhler.com wrote: On Saturday, January 15, 2011 04:07:56 pm Anssi Hannula wrote: Hi all! Should we have a %mdkversion (and %mdkver/%mdvver) that is hardcoded to 201100 for the time being, or should we not have one at all? Not having it will cause any src.rpms that have any %if %mdkversion x to fail to build. I'm strongly in favor of having it for compatibility reasons, so that most MDV src.rpms keep building on Mageia for the time being, including those provided by any 3rd party packagers. Not having the macro will cause us to lose that compatibility for very little benefit, IMO. It could maybe be removed after several releases, but not before. However, it seems blino disagreed with this, and he thinks we should not have these macros at all. What do other people think? There is also an %exclude in the file section that doesn't work on mageia -- Thomas no this doesn't work with latest rpm, in mageia AND in mandriva. Fom rpm devs POV, this is now how it should work
