Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
Hi On Mon, Jan 5, 2015 at 12:18 AM, Chris Murphy wrote: > > So what exactly is the problem the target audience has? They want > GNOME Packages to be included again by default so they have both an > application GUI installer, and a packages GUI installer? That is potentially one way to address it. I think it is somewhat confusing to have two different interfaces for dealing with software and it also means that the additional metadata included in GNOME Software won't be available for command line utilities but it might be a marginal improvement over not having any UI at all for the rest of the packages. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
On Sun, Jan 4, 2015 at 8:15 PM, Rahul Sundaram wrote: > Hi > > On Sun, Jan 4, 2015 at 9:43 PM, Chris Murphy < wrote: >> >> There's already an application that does this, it's GNOME >> Packages or use yum/dnf. > > > If this was the answer, there wouldn't be so many repeated discussions about > it. Users don't differentiate between say htop and geany as much as the > designers seem to have assumed. They treat them both as essentially > "applications". However it doesn't fit the definition that GNOME Software > has and ends up being not included. There are also users who love the > ratings and additional metadata that GNOME Software brings and they > wouldn't get any of that with GNOME Packages or yum. dnf search is even more > limiting since it doesn't offer even the rudimentary filtering by name that > yum offers. GNOME Packages also is not included by default. In other > words, GNOME Software solves a problem very well but unfortunately doesn't > solve the problems that the target audience has that much. I don't think the solution is merging the GNOME Software and Packages UI's into one nutty experience. So what exactly is the problem the target audience has? They want GNOME Packages to be included again by default so they have both an application GUI installer, and a packages GUI installer? That doesn't seem unreasonable on the face of it. I think that's the idea presently being floated. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
/*Aleksandar Kurtakov */ wrote on Sun, 4 Jan 2015 02:55:17 -0500 (EST): - Original Message - From: "Hedayat Vatankhah" To: "Development discussions related to Fedora" Sent: Friday, January 2, 2015 11:15:58 PM Subject: Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments <...> GNOME Software is not that useful for a developer. As Rechard himself said, he'll need a package manager anyway. So, If Workstation product really targets developers, specially the ones who don't want to use terminal, it MUST include a graphical package manager. There are developers unaware of the concept of package manager which does not help. Gnome Software is actually useful once the add-ons functionality is fully expanded on applications. Works need to be done allowing a seamless integration. Add-ons cannot cover development libraries, unless every library is an add-on for all IDEs! It can be done dynamic aka install devel packages on request by IDEs - see https://rgrunber.fedorapeople.org/eclipse_packagekit_1.ogv It's great, but it is not address my concerns, because: 1) If its going to be the only method for installing -devel packages, it should always work: it should be able to install a missing library or header file (consider a makefile only project). Also, not everybody uses correct package name in their configure script, some people use corresponding Debian package name (with a lib prefix and even sometimes full debian package name: libfoo-dev); so partial/non-exact matching should be also implemented. 2) More importantly, it doesn't address my main concern at all: what if I want to create a new project, and I'm looking for a good XML library, or would like to see what Fedora has to offer in this area? Even if I've found a great library in Internet, I should create a test in my configure/cmake checks for that library and see if PK will find it. It doesn't look like a user friendly way to search for a development library! It's a workaround around a missing UI. Looking for development libraries, see their ranking and even reading user's reviews is all completely useful for a developer, which aligns perfectly with what Software offers for applications. Regards, Hedayat Alexander Kurtakov Red Hat Eclipse team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: allowing programs to open ports
Hi On Sun, Jan 4, 2015 at 6:32 PM, Kevin Kofler wrote: > Björn Persson wrote: > > I bet! I worry that the questions would quickly become annoying. But if > > ports are going to be blocked by default, then there needs to be some > > way for non-sysadmin users to open them. > > No, why? The ports just need to be closed, period. Non-sysadmin users > shouldn't be allowed to open any ports. That won't work in a world where users *are* the sysadmins as well. Even in a small business where one has a sysadmin, they aren't focused on internal issues all that much. Users are expected to cope up. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
Hi On Sun, Jan 4, 2015 at 9:43 PM, Chris Murphy < wrote: > There's already an application that does this, it's GNOME > Packages or use yum/dnf. > If this was the answer, there wouldn't be so many repeated discussions about it. Users don't differentiate between say htop and geany as much as the designers seem to have assumed. They treat them both as essentially "applications". However it doesn't fit the definition that GNOME Software has and ends up being not included. There are also users who love the ratings and additional metadata that GNOME Software brings and they wouldn't get any of that with GNOME Packages or yum. dnf search is even more limiting since it doesn't offer even the rudimentary filtering by name that yum offers. GNOME Packages also is not included by default. In other words, GNOME Software solves a problem very well but unfortunately doesn't solve the problems that the target audience has that much. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
On 01/04/2015 06:46 PM, Kevin Kofler wrote: Gary Scarborough wrote: Is workstation being aimed at new users or developers? And is the goal the same for Gnome? If Gnome is aiming to cater to new users, then is it the right primary DE for fedora? There seems to be a misalignment here. I've been pointing out that misalignment from day 1. Nobody seems to care. IMHO, developers are much better served with the KDE Spin: * Plasma is more configurable and more adapted to the power users that developers inevitably are, * Apper (the package management GUI installed by default on the KDE spin) does not hide development packages the way GNOME Software (the package management GUI installed by default on the Workstation product) does, * Qt and kdelibs / KDE Frameworks are a better development platform than GTK+ (and yes, I've used both), * KDevelop is a better IDE than anything GNOME has to offer. The choice of GNOME as a desktop environment completely contradicts the claimed target of "developers". Kevin Kofler The Workstation product is generally aimed at developers as per the Target Audience section of the Workstation PRD[1], and the Workstation working group decided on GNOME as the desktop to use to accomplish the goals laid out in the PRD. Although the Workstation PRD sets out a lot of developer-centric goals, the choice of GNOME as the default desktop and the discussion around the not-so-devleoper-centric GNOME Software app and other GNOME features make it seem like the Workstation product is kind of awkwardly straddling the line between a shiny new developer-centric "Workstation" product and the old "Desktop" default GNOME-based spin (whose goals are not really enumerated in the PRD.) In that light I can see how it may look like the choice of GNOME for the Workstation product seem contradictory. Are there any plans to promote the KDE spin to a product? Reading the Workstation PRD and taking into account their choice of GNOME as the default environment, it looks like there are wide open "Average User," "Power User," and "Cross-Platform Development (via Qt)" target audiences that a new KDE-based "Fedora Desktop" or similar product could easily cater to. Rich [1] https://fedoraproject.org/wiki/Workstation/Workstation_PRD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
On Sun, Jan 4, 2015 at 9:57 AM, Rahul Sundaram wrote: > Hi > > On Sun, Jan 4, 2015 at 8:46 AM, Richard Hughes wrote: >> >> We're not filtering out packages that don't qualify as applications. >> GNOME Software only searches the AppStream metadata > > > Yes. My suggestion was to change that How? What does this look like? Call me clueless, but I think that totally defeats the major points behind Software. It's an opt-in application, that shouldn't change or it's going to make it ugly, incoherent, and pointless. The UX is intentionally designed to show applications, not packages. And certainly not conflate both by showing both side by side. But to wholesale revert back to showing a pile of packages – no thanks. There's already an application that does this, it's GNOME Packages or use yum/dnf. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] 2015-01-05 @16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2015-01-05 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! Hope everyone had a happy and safe winter solstice event of their choice. Now it's time for the most significant and exciting happening of all: the first QA meeting of a new Gregorian calendar year! I know, I'm excited too. roshi and I had a quick chat about the idea of starting up blocker bug review for the F22 cycle this week, in the interests of reducing the number of long meetings later in the cycle by starting earlier - so let's see what folks think of that. I don't have any other specific topics for the agenda - please reply to this mail if you do! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Blocker bug review planning 3. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review Request: python-sane
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/02/2015 01:10 PM, Sandro Mani wrote: > Hi, > > python-pillow split off the sane library into a separate project, > review request for the package is here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1178191 > > Happy to review in exchange. > > Thanks, Sandro > > I will take this. Mukundan. - -- GPG key: 00E8658D -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJUqewrAAoJEIfjPv0A6GWNtxMQAJlSrv/k7yMJGnh3U/x3yu6u lV+1Uf+hV2x0Zi/OSi9Ijm/PhL2fdHxXh3Lhy0P7m99CJRENXqbKshKNpDb9MnF4 e2jnVRY9uxGJxI1vZN5Mxiuzv+khZa7H3r3n7u9lRiY0Ksmtt7nNJNEBsEsHyRrY TQQj50Iby8tpZBi1kmnHpUW83bI4PP/RkyGUDqSrW39GjEf/tFLuQsPnytPt1H3T B1poS+jFUPh1C8McQ7IouofZ5lezY0JAO9PNw3XkypwhlFmbVpxwHaxcHk3EOPdx i2NNpwC6Zo9q9B6gWAxnJWjh50a0DDYKwuXsChnxLFoze5diCUECLvDabOOsqBmW d8FU+T4cEuqCOIbBdb3oXVUF7r5CXlrvGom7/nWOBnzCNQQ1VLAUkQM+vdwHOiuS IEyZVlBDUoavGlp6rpe0nLPLS29qFepxxzDRM+D6BSsNnW52Lt8uHvMVuzALJM4f Di3OVo2Y7jomuN8I3S7f1MDeCHfm+4Qze8K1x2K0bgQJWbw8UYJdQVMNKfsxLiPm 7ePC8XAXWc0Eo8pVNlJ8L1Uj9+hAxXdER+sMdccSLP5rUgP+zLLJely4IdudEM/I roJ0iip9wRcci2i62PzCdaPf5bgBH88WFCWVZyagLrvVBvKsSh17/RPdPp6M7m1+ l8rUQJF/KLpc07iyLVpC =WMrR -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
Gary Scarborough wrote: > Is workstation being aimed at new users or developers? And is the goal > the same for Gnome? If Gnome is aiming to cater to new users, then is it > the right primary DE for fedora? There seems to be a misalignment here. I've been pointing out that misalignment from day 1. Nobody seems to care. IMHO, developers are much better served with the KDE Spin: * Plasma is more configurable and more adapted to the power users that developers inevitably are, * Apper (the package management GUI installed by default on the KDE spin) does not hide development packages the way GNOME Software (the package management GUI installed by default on the Workstation product) does, * Qt and kdelibs / KDE Frameworks are a better development platform than GTK+ (and yes, I've used both), * KDevelop is a better IDE than anything GNOME has to offer. The choice of GNOME as a desktop environment completely contradicts the claimed target of "developers". Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: allowing programs to open ports
Björn Persson wrote: > I bet! I worry that the questions would quickly become annoying. But if > ports are going to be blocked by default, then there needs to be some > way for non-sysadmin users to open them. No, why? The ports just need to be closed, period. Non-sysadmin users shouldn't be allowed to open any ports. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
retire: seam-conversation, seam-parent, seam-solder, openjpa
Hi, I want retire: seam-conversation, seam-parent, seam-solder I do not have many reasons to keep them still And if someone can take care of openjpa package or can give a help as co-maintainer. https://issues.apache.org/jira/browse/OPENJPA-2386 Unusable and not buildable with Java8. As last resort I will have to pick up too, and the packages that require it. regards - gil -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yet another frustration with Fedora package management
Hi On Sun, Jan 4, 2015 at 1:33 PM, Hedayat Vatankhah wrote: > > So, I thought that maybe every package *likes* to have its specific > settings method; and therefore I proposed to have a global configuration > which configures main package manager policy. > I agree with the problem. However I don't think the solution you are proposing is the right one 1) dnf forked yum which was supposed to be just a project name but dnf developers have changed their mind and want dnf to be the new permanent name. I disagree with this decision but unless FESCo intervenes which seems unlikely, dnf will essentially replace yum in the near future and when more newer functionality of RPM such as soft dependencies get used, yum will have to stop getting used after the temporary transition period. So after the transition, you will only have to deal with dnf.conf 2) PackageKit should ideally respect yum.conf or dnf.conf instead of requiring its own configuration file for shared common options. Perhaps you can talk to Richard Hughes about that Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yet another frustration with Fedora package management
/*Reindl Harald */ wrote on Sun, 04 Jan 2015 19:19:20 +0100: Am 04.01.2015 um 19:13 schrieb Hedayat Vatankhah: <...> DNF is using "/etc/dnf/dnf.conf" which is one reason more to finally rename it back to YUM when it starts to replace it instead demand users all over the world change working configs, but that's a different topic nobody cares about if other sofwtare like Packagekit ignore that global options of the package manager just file bugreport for them >>> I wonder if having a single packages.conf is THAT hard!!! for DNF, YUM, Packagekit and what not else? surely, the same way hard to just proceed the configuration of yum.conf, they all would needed to be changed I'm fine with using yum.conf if everybody respects it, but I didn't propose it because: 1) There are some options in yum.conf that DNF/PK doesn't recognize 2) DNF has some specific options in dnf.conf which yum doesn't support 3) PK/GNOME Software have ... well I'm yet to completely discover but at least they have some options controlled by gsettings! and some in /etc/PackageKit/ which is completely unique to itself! So, I thought that maybe every package *likes* to have its specific settings method; and therefore I proposed to have a global configuration which configures main package manager policy. Regards, Hedayat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yet another frustration with Fedora package management
Am 04.01.2015 um 19:13 schrieb Hedayat Vatankhah: /*Reindl Harald */ wrote on Sun, 04 Jan 2015 19:11:01 +0100: Am 04.01.2015 um 19:02 schrieb Hedayat Vatankhah: /*Rex Dieter */ wrote on Sat, 03 Jan 2015 16:58:32 -0600: Hedayat Vatankhah wrote: <...> Suggestion: Please add a single configuration file to configure common package manager options I think you answered your own question => modify the .repo files Thank you!!! Yes, I know that I can do it, but its nothing but ridiculous. And, as I said, this is an unsafe approach: first I excluded it from one repo, then I discovered that I should add another repository, and then another one. What if this package is in 50 repos? Or you want to set metadata_expire for 50 repos? I wonder if having a single packages.conf is THAT hard!!! WTF don't you read other answers before continue to rant? just edit "yum.conf" instead demand a useless "packages.conf" duplicating what is already there Have you read my first email carefully? yum.conf is only used by yum, DNF and PackageKit/Gnome software don't care about it. DNF is using "/etc/dnf/dnf.conf" which is one reason more to finally rename it back to YUM when it starts to replace it instead demand users all over the world change working configs, but that's a different topic nobody cares about if other sofwtare like Packagekit ignore that global options of the package manager just file bugreport for them >>> I wonder if having a single packages.conf is THAT hard!!! for DNF, YUM, Packagekit and what not else? surely, the same way hard to just proceed the configuration of yum.conf, they all would needed to be changed signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yet another frustration with Fedora package management
/*Reindl Harald */ wrote on Sun, 04 Jan 2015 19:11:01 +0100: Am 04.01.2015 um 19:02 schrieb Hedayat Vatankhah: /*Rex Dieter */ wrote on Sat, 03 Jan 2015 16:58:32 -0600: Hedayat Vatankhah wrote: <...> Suggestion: Please add a single configuration file to configure common package manager options I think you answered your own question => modify the .repo files Thank you!!! Yes, I know that I can do it, but its nothing but ridiculous. And, as I said, this is an unsafe approach: first I excluded it from one repo, then I discovered that I should add another repository, and then another one. What if this package is in 50 repos? Or you want to set metadata_expire for 50 repos? I wonder if having a single packages.conf is THAT hard!!! WTF don't you read other answers before continue to rant? just edit "yum.conf" instead demand a useless "packages.conf" duplicating what is already there Have you read my first email carefully? yum.conf is only used by yum, DNF and PackageKit/Gnome software don't care about it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yet another frustration with Fedora package management
Am 04.01.2015 um 19:02 schrieb Hedayat Vatankhah: /*Rex Dieter */ wrote on Sat, 03 Jan 2015 16:58:32 -0600: Hedayat Vatankhah wrote: <...> Suggestion: Please add a single configuration file to configure common package manager options I think you answered your own question => modify the .repo files Thank you!!! Yes, I know that I can do it, but its nothing but ridiculous. And, as I said, this is an unsafe approach: first I excluded it from one repo, then I discovered that I should add another repository, and then another one. What if this package is in 50 repos? Or you want to set metadata_expire for 50 repos? I wonder if having a single packages.conf is THAT hard!!! WTF don't you read other answers before continue to rant? just edit "yum.conf" instead demand a useless "packages.conf" duplicating what is already there signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yet another frustration with Fedora package management
/*Rex Dieter */ wrote on Sat, 03 Jan 2015 16:58:32 -0600: Hedayat Vatankhah wrote: <...> Suggestion: Please add a single configuration file to configure common package manager options I think you answered your own question => modify the .repo files Thank you!!! Yes, I know that I can do it, but its nothing but ridiculous. And, as I said, this is an unsafe approach: first I excluded it from one repo, then I discovered that I should add another repository, and then another one. What if this package is in 50 repos? Or you want to set metadata_expire for 50 repos? I wonder if having a single packages.conf is THAT hard!!! Hedayat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
Hi On Sun, Jan 4, 2015 at 8:46 AM, Richard Hughes wrote: > We're not filtering out packages that don't qualify as applications. > GNOME Software only searches the AppStream metadata Yes. My suggestion was to change that Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: File location
On Sun, Jan 4, 2015 at 2:41 PM, Anshu Prateek wrote: > hi, > > I am working on packaging an upstream (aerospike) which presently puts some > of its file in /opt/aerospike. > > The two main folders in use (by upstream) are > > /opt/aerospike/sys/udf/lua - This has the user defined lua functions > shipped with the package. > /opt/aerospike/usr/udf/ - This will have the user's custom UDFs. Looks like all these are users-defined contents, so is it OK to read these from anywhere? I mean if you can allow users to specify the location during the make install, that'd be better. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
On 4 January 2015 at 02:45, Rahul Sundaram wrote: > Another alternative would be for GNOME Software to show packages perhaps > optionally and deprioritize packages in the listing We're not filtering out packages that don't qualify as applications. GNOME Software only searches the AppStream metadata (just the pre-prepared things that qualify as applications) and then manually matches up any desktop files that exist locally to packages using PackageKit. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20150104 changes
Compose started at Sun Jan 4 05:15:03 UTC 2015 Broken deps for i386 -- [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [aeskulap] aeskulap-0.2.2-0.19beta1.fc22.i686 requires libofstd.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires liboflog.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg8.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg16.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg12.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmnet.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmjpeg.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimgle.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimage.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmdata.so.3.6 [boswars] boswars-2.7-5.fc22.i686 requires libtolua++-5.1.so [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [fawkes] fawkes-lua-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-katana-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-pantilt-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-roomba-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-skiller-0.5.0-19.fc22.i686 requires libtolua++-5.1.so [gcc-python-plugin] gcc-python2-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python2-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 [glances] glances-2.2.1-2.fc22.noarch requires python-psutil >= 0:2.0.0 [guacamole-server] libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-utils.so.1.2 libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-core.so.1.2 libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-codec.so.1.2 libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-cache.so.1.2 [nifti2dicom] nifti2dicom-0.4.9-1.fc22.i686 requires libitksys-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libitkopenjpeg-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libitkdouble-conversion-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libitkNetlibSlatec-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKznz-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKniftiio-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKgiftiio-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKWatersheds-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKVtkGlue-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKVideoIO-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKVideoCore-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKVTK-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKVNLInstantiation-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKStatistics-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKSpatialObjects-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKReview-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKQuadEdgeMesh-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKPolynomials-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKPath-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKOptimizersv4-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKOptimizers-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKNrrdIO-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKMetaIO-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKMesh-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKLabelMap-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKKLMRegionGrowing-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOXML-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOVTK-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOTransformMatlab-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOTransformInsightLegacy-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOTransformHDF5-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOTransformBase-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOTIFF-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOStimulate-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOSpatialObjects-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOSiemens-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOPNG-4.6.so.
Re: File location
On 01/04/2015 10:34 AM, Nico Kadel-Garcia wrote: On Sun, Jan 4, 2015 at 3:01 AM, Ralf Corsepius wrote: On 01/04/2015 07:41 AM, Anshu Prateek wrote: hi, I am working on packaging an upstream (aerospike) which presently puts some of its file in /opt/aerospike. The two main folders in use (by upstream) are /opt/aerospike/sys/udf/lua - This has the user defined lua functions shipped with the package. /opt/aerospike/usr/udf/ - This will have the user's custom UDFs. What will be the right place in FHS to put the above two directories when packaging for Fedora? Should these go into /usr/share/aerospike or some place in /var? I think the useful place to put it is to get aerospike to publish their SRPM, especially their spec files. Let me cut a long story short: /opt/ is the appropriate place for other SW-vendors to install add-on packages into, but it's an entirely inappropriate place to for OS-vendors (such as Fedora) to put their packages into. Or conversely: It's strictly prohibited for Fedora to install package into /opt, because this path is reserved for add-on packages. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: File location
On Sun, Jan 4, 2015 at 3:01 AM, Ralf Corsepius wrote:
> On 01/04/2015 07:41 AM, Anshu Prateek wrote:
>>
>> hi,
>>
>> I am working on packaging an upstream (aerospike) which presently puts
>> some of its file in /opt/aerospike.
>>
>> The two main folders in use (by upstream) are
>>
>> /opt/aerospike/sys/udf/lua - This has the user defined lua functions
>> shipped with the package.
>> /opt/aerospike/usr/udf/ - This will have the user's custom UDFs.
>>
>> What will be the right place in FHS to put the above two directories
>> when packaging for Fedora? Should these go into /usr/share/aerospike or
>> some place in /var?
I think the useful place to put it is to get aerospike to publish
their SRPM, especially their spec files. I'm looking at the RHEL rpm
for their c-client tool, and it shoves some things in /op, and some in
/usr/lib for the 64-bit version, which rather violates the /usr/lib64
location for the libraries.
> Impossible to tell without having seen the sources and without knowing the
> contents. /usr/share/, /usr/lib/,
> /usr/{lib,lib64}/ would seem likely candidates.
I looked at this once before and it started making me twitch. Anyone
who publishes a system specific tarball, and puts the sources and
several RPM's *inside* the same tarbal but can't be bothered to
include a .spec or SRPM is just being goofy.
> Packages installing to /opt are not allowed in Fedora. In most cases, such
> packages are simply incorrectly configured.
>
> Ralf
The "FileSystem Hierarchy", "File Hierarchy System", and its other
three-letter descriptions had their last official release in 2004.
It's in the process of an update to version 3.0. The beta version is
at http://www.linuxbase.org/betaspecs/fhs/fhs.html. It's pretty clear
that "/opt is reserved for the installation of add-on application
software packages.".
It's common for third party packages that require their own
non-system-standard libraries and binaries for Perl, Python, MySQL,
HTTPD, and god knows Python and Ruby use /opt to have a modular
installation that does not step on your system libraries. God knows
that commercial software vendors use it, and even some open source
vendors like Opscode use it for "chef" software.
Also note that Fedora does not follow the FHS word-for-word. The
merging of /bin with /usr/bin, /sbin with /usr/sbin, etc. is a clear
violation of even the latest proposed FHS. And the use of
"/var/run/meda" for user-owned mounted media, built into "systemd", is
a pretty clear violation of the specification for all three "/var",
"/run", and "/media. Getting violated 3 ways at once, well, I hope it
was thrilling for *everyone*.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: File location
On 01/04/2015 07:41 AM, Anshu Prateek wrote:
hi,
I am working on packaging an upstream (aerospike) which presently puts
some of its file in /opt/aerospike.
The two main folders in use (by upstream) are
/opt/aerospike/sys/udf/lua - This has the user defined lua functions
shipped with the package.
/opt/aerospike/usr/udf/ - This will have the user's custom UDFs.
What will be the right place in FHS to put the above two directories
when packaging for Fedora? Should these go into /usr/share/aerospike or
some place in /var?
Impossible to tell without having seen the sources and without knowing
the contents. /usr/share/, /usr/lib/,
/usr/{lib,lib64}/ would seem likely candidates.
Packages installing to /opt are not allowed in Fedora. In most cases,
such packages are simply incorrectly configured.
Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
- Original Message - > From: "Alec Leamas" > To: "Development discussions related to Fedora" > > Sent: Saturday, January 3, 2015 10:19:30 PM > Subject: Re: Ramblings and questions regarding Fedora,but stemming > from gnome-software and desktop environments > > On 03/01/15 20:26, Hedayat Vatankhah wrote: > > > > > > /*Luya Tshimbalanga*/ wrote on Fri, 02 Jan 2015 17:29:14 -0800: > > > > >>> Add-ons cannot cover development libraries, unless every library is > >>> an add-on for all IDEs! > > >> Then is IDE packaging issue. When it comes of using a development > >> applications, the software should suggest installing the missing > >> library. If Gnome Video is able to prompt uses to install missing > >> component, then why shouldn't be possible for IDE application to do > >> the same? > >> Granted I don't know well the functionality but the logic is > >> application should detect and suggest adding the missing function. > > > Hmm... that's weird, I can't understand what you mean. Gnome Video's job > > is very easy: a video has a special format, and there are specific > > plugins to enable playing that. However, assume that I need an XML > > library for C++: > > 1. How can I tell the IDE that I need an XML library? > > 2. What should IDE do if there are 5 different XML libraries for C++? > > How should I tell it which one I want, specially if I don't know what > > should I use already, and want to see what is available out there? > > > > To me, it seems like implementing a special purpose software manager > > inside IDE with almost all functionality GNOME Software provides. As I > > said in another post, user reviews/rating for development libraries > > (like what GNOME Software provides for applications) can be really > > helpful when a developer wants to choose a library for a specific purpose. > > In other words: there is a difference between the toolchain and project > dependencies. > > The toolchain e. g. eclipse + gcc etc. can be probably partly be fixed > using IDE dependencies, DevAssistant and similar setups reflecting > general tool-set dependencies, agreed. > > OTOH, the dependencies for a specific project cannot really be handled > this way. Such libraries are specific for the code you build, not the > tools. Making them dependencies of e. g., eclipse just doesn't make any > sense. Yeah, it doesn't make sense to make dependencies of eclipse but usually when something is missing it's not that hard to find what to install programatically. Pointing again to the video for eclipse https://rgrunber.fedorapeople.org/eclipse_packagekit_2.ogv . I remember something about Anjuta being able to do something similar but can't find it now. Of course this can not cover every "creative" build environment but such approach works well for video codecs so it's not impossible. Alexander Kurtakov Red Hat Eclipse team > > > Cheers! > > --alec > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
