Hi All,
A college of mine wanted to use umbrello in our Universities labs, since the Linux install there are Fedora he asked me about umbrello for Fedora.
Since I could NOT find it, I packaged it, see: https://bugzilla.redhat.com/show_bug.cgi?id=283471
But then I got a comment to the review it was already in Fedora in kdesdk. But then why on earth doesn't kdesdk have a Provides umbrello so that yum install umbrello works? Or even better an umbrello sub-package?
As it currently stands umbrello is just plain unfindable to end users, as you know I'm not some noob. I even searched for in progress reviews of umbrello.
Also I think it is a very bad idea to ship packages with a clearly seperate upstream in some kinda bundle form. Sticking with the umbrello example, in order for the latest version to be included into Fedora, we must wait for a new upstream kdesdk release, which likely won't happen before there is a kdesdk4 in some far away future, as kde3 is as good as EOL.
Notice that umbrello and kdesdk are just an example, this goes for other Aggregation upstreams too.
Since on of Fedora's strenghts is being always up to date with the latest upstream versions, I think using these kind of upstream aggregation projects is a BAD idea as it creates interlocks with regards to versions between clearly seperate projects like kdesdk and umbrello.
If an upstream disolves into something bigger thats a whole different story, I'm talking about the aggregated project still having a clearly alive and active upstream. Actually this is much like having apps with bundled other upstream libs, where we always say these must not be used, and we even delay reviews, waiting for a package and review of the lib as a seperate package if necessary. I say we should extend this rule to bundled clearly seperate upstream apps.
p.s.
On Sa September 8 2007, Hans de Goede wrote:
As it currently stands umbrello is just plain unfindable to end users, as you know I'm not some noob. I even searched for in progress reviews of umbrello.
Also I think it is a very bad idea to ship packages with a clearly seperate upstream in some kinda bundle form. Sticking with the umbrello example, in order for the latest version to be included into Fedora, we must wait for a new upstream kdesdk release, which likely won't happen before there is a kdesdk4 in some far away future, as kde3 is as good as EOL.
Notice that umbrello and kdesdk are just an example, this goes for other Aggregation upstreams too.
Since on of Fedora's strenghts is being always up to date with the latest upstream versions, I think using these kind of upstream aggregation projects is a BAD idea as it creates interlocks with regards to versions between clearly seperate projects like kdesdk and umbrello.
I agree completely.
Regards, Till
On 08/09/2007, Till Maas opensource@till.name wrote:
On Sa September 8 2007, Hans de Goede wrote:
As it currently stands umbrello is just plain unfindable to end users, as you know I'm not some noob. I even searched for in progress reviews of umbrello.
Also I think it is a very bad idea to ship packages with a clearly seperate upstream in some kinda bundle form. Sticking with the umbrello example, in order for the latest version to be included into Fedora, we must wait for a new upstream kdesdk release, which likely won't happen before there is a kdesdk4 in some far away future, as kde3 is as good as EOL.
Notice that umbrello and kdesdk are just an example, this goes for other Aggregation upstreams too.
Since on of Fedora's strenghts is being always up to date with the latest upstream versions, I think using these kind of upstream aggregation projects is a BAD idea as it creates interlocks with regards to versions between clearly seperate projects like kdesdk and umbrello.
I agree completely.
Ditto, though in this case, umbrello happens to *also* be part of kdesdk:
http://uml.sourceforge.net/download.php
The source tarballs are taken straight out of kdesdk CVS, so the Fedora packaging, while needing to be fixed, is understandable.
By the way, 'yum search umbrello' won't work with just a Provides:, and so yum install probably would not either:
https://bugzilla.redhat.com/show_bug.cgi?id=283611
So a stopgap fix might not work, until the package is properly split.
Regards,
On 2007-09-09, 13:18 GMT, Michel Salim wrote:
Since on of Fedora's strenghts is being always up to date with the latest upstream versions, I think using these kind of upstream aggregation projects is a BAD idea as it creates interlocks with regards to versions between clearly seperate projects like kdesdk and umbrello.
Ditto, though in this case, umbrello happens to *also* be part of kdesdk:
This is the situation for all KDE programs -- KDE team in Fedora is apparently so small that they managed to do anything else than just repackaging upstream tarballs (I don't know more about that being GNOMEr, but I have certainly nothing against KDE -- I would use it myself, if not being employed in RH desktop team). You had problem with umbrello, but exactly the same situation is with kmail, knode, and others. See this example:
[root@viklef ~]# yum list kmail knode konqueror konsole kwrite \ kword koffice kspread kopete updates-testing 100% |=========================| 1.9 kB 00:00 livna 100% |=========================| 2.1 kB 00:00 fedora 100% |=========================| 2.1 kB 00:00 adobe-linux-i386 100% |=========================| 951 B 00:00 fedora-debuginfo 100% |=========================| 1.9 kB 00:00 updates-testing-debuginfo 100% |=========================| 1.9 kB 00:00 updates 100% |=========================| 1.9 kB 00:00 texlive 100% |=========================| 951 B 00:00 Error: No matching Packages to list [root@viklef ~]#
Of course, it would be nice to create kmail as a subpackage of kdepim (as it is done in Debian -- http://packages.debian.org/sarge/kmail is a subpackage of source package kdepim -- see "Source" label on the top of the page), but I am afraid it would be asking KDE team to do more work than they are able to do.
Best,
Matěj
On 9/9/07, Michel Salim michel.sylvan@gmail.com wrote:
On 08/09/2007, Till Maas opensource@till.name wrote:
On Sa September 8 2007, Hans de Goede wrote:
As it currently stands umbrello is just plain unfindable to end users, as you know I'm not some noob. I even searched for in progress reviews of umbrello.
Also I think it is a very bad idea to ship packages with a clearly seperate upstream in some kinda bundle form. Sticking with the umbrello example, in order for the latest version to be included into Fedora, we must wait for a new upstream kdesdk release, which likely won't happen before there is a kdesdk4 in some far away future, as kde3 is as good as EOL.
Notice that umbrello and kdesdk are just an example, this goes for other Aggregation upstreams too.
Since on of Fedora's strenghts is being always up to date with the latest upstream versions, I think using these kind of upstream aggregation projects is a BAD idea as it creates interlocks with regards to versions between clearly seperate projects like kdesdk and umbrello.
I agree completely.
Ditto, though in this case, umbrello happens to *also* be part of kdesdk:
http://uml.sourceforge.net/download.php
The source tarballs are taken straight out of kdesdk CVS, so the Fedora packaging, while needing to be fixed, is understandable.
By the way, 'yum search umbrello' won't work with just a Provides:, and so yum install probably would not either:
How about listing the apps in the description?
Arthur Pemberton <pemboa <at> gmail.com> writes:
How about listing the apps in the description?
This is what's done for some of the other kde* packages, it could probably be done here. The main problem with this is that sometimes apps get dropped or replaced (in the upstream collection), or new apps get into the collection, and then the list tends to get out of sync with what's actually in the package.
Kevin Kofler
Michel Salim <michel.sylvan <at> gmail.com> writes:
Ditto, though in this case, umbrello happens to *also* be part of kdesdk:
http://uml.sourceforge.net/download.php
The source tarballs are taken straight out of kdesdk CVS, so the Fedora packaging, while needing to be fixed, is understandable.
Well, as you're saying, kdesdk here is the canonical source, the separate tarballs are taken out of kdesdk SVN, and it is also included in kdesdk, so packaging Umbrello as part of kdesdk fully makes sense.
As for Hans de Goede's worry: a KDE 3.5.8 bugfix release is planned. Given that the latest Umbrello comes straight out of the KDE 3.5 SVN branch, it will also end up in there.
Both monolithic and modular packaging has advantages and disadvantages. The advantages of the monolithic way: * less packages => less packaging work * clearer versioning: You know that you're using KDE 3.5.7, whereas for e.g. GNOME, you have stuff versioned 2.18.0, 2.18.1, 2.18.2, ... and it's hard to figure out what GNOME version this actually corresponds to (and similarly for the new modular X.Org X11).
But of course, the advantages of the modular way (independent updates, better granularity for end-users) have been beaten to death on this list already. The granularity could be obtained in other ways though (e.g. subpackages).
Still, my current position (and as far as I was able to tell from the general feeling when this issue came up in the IRC meetings, also the one of the KDE SIG, feel free to correct me if I'm misrepresenting anyone's opinion here) is that unleashing even a subpackage for every single KDE app would lead to a gigantic mess which would cause more problems than it solves.
Kevin Kofler
On 11/09/2007, Kevin Kofler kevin.kofler@chello.at wrote:
Michel Salim <michel.sylvan <at> gmail.com> writes: Both monolithic and modular packaging has advantages and disadvantages. The advantages of the monolithic way:
- less packages => less packaging work
- clearer versioning: You know that you're using KDE 3.5.7, whereas for e.g.
GNOME, you have stuff versioned 2.18.0, 2.18.1, 2.18.2, ... and it's hard to figure out what GNOME version this actually corresponds to (and similarly for the new modular X.Org X11).
Oh yes. Figuring out which parts of X.org 7.3 is in F8 and which is not, is not exactly trivial.
But of course, the advantages of the modular way (independent updates, better granularity for end-users) have been beaten to death on this list already. The granularity could be obtained in other ways though (e.g. subpackages).
Subpackages give end-users better granularity, but still does not allow for independent updates (unless, taking Umbrello as an example, an urgent Umbrello release is handled by building a separate package that is versioned higher than the bundled kdesdk-umbrello). Gets unwieldy really fast!
(Alternatively, kdesdk maintainer needs to pull the fix pertaining to Umbrello, apply it as a patch, release it and prepare for the grumbles from other kdesdk users who then have to upgrade)
Still, my current position (and as far as I was able to tell from the general feeling when this issue came up in the IRC meetings, also the one of the KDE SIG, feel free to correct me if I'm misrepresenting anyone's opinion here) is that unleashing even a subpackage for every single KDE app would lead to a gigantic mess which would cause more problems than it solves.
Seems reasonable.
Regards,
On 9/11/07, Kevin Kofler kevin.kofler@chello.at wrote:
Still, my current position (and as far as I was able to tell from the general feeling when this issue came up in the IRC meetings, also the one of the KDE SIG, feel free to correct me if I'm misrepresenting anyone's opinion here) is that unleashing even a subpackage for every single KDE app would lead to a gigantic mess which would cause more problems than it solves.
I think as downstream bit maintainers, you've got to stick close to how upstream deals with thier source collection. If KDE as a project continues to prefer monolithic model then I think its best to follow their lead. and use subpackaging as is appropriate.
-jef
2007/9/8, Hans de Goede j.w.r.degoede@hhs.nl:
As it currently stands umbrello is just plain unfindable to end users, as you know I'm not some noob. I even searched for in progress reviews of umbrello.
Heh :) Have you ever tried to install, say mp3-decoding plugins into GStreamer? There are a 4 subpackages with nothing-said-about-content names as gstreamer-plugins-bad, gstreamer-plugins-good etc.
If I grep through "yum list" results I see nothing in this case but I never heard that anybody wants to change this situation.
On Sat, 2007-09-08 at 17:29 +0400, Peter Lemenkov wrote:
2007/9/8, Hans de Goede j.w.r.degoede@hhs.nl:
As it currently stands umbrello is just plain unfindable to end users, as you know I'm not some noob. I even searched for in progress reviews of umbrello.
Heh :) Have you ever tried to install, say mp3-decoding plugins into GStreamer? There are a 4 subpackages with nothing-said-about-content names as gstreamer-plugins-bad, gstreamer-plugins-good etc.
If I grep through "yum list" results I see nothing in this case but I never heard that anybody wants to change this situation.
Well, the above is really a bug to file for livna - but again - ask them to add provides.
-sv
Heh :) Have you ever tried to install, say mp3-decoding plugins into GStreamer? There are a 4 subpackages with nothing-said-about-content names as gstreamer-plugins-bad, gstreamer-plugins-good etc. If I grep through "yum list" results I see nothing in this case but I never heard that anybody wants to change this situation.
Well, the above is really a bug to file for livna - but again - ask them to add provides.
In case of mp3 - yes. But what about flac, ogg, wavpack etc?
[petro@Sulaco ~]$ sudo yum install gstreamer-plugins-ogg fedora 100% |=========================| 2.1 kB 00:00 livna 100% |=========================| 2.1 kB 00:00 updates 100% |=========================| 1.9 kB 00:00 Setting up Install Process Parsing package install arguments Nothing to do [petro@Sulaco ~]$
Lets look a little closer:
====================================
[petro@Sulaco ~]$ yum info gstreamer-plugins-good gstreamer-plugins-base Available Packages Name : gstreamer-plugins-base Arch : ppc Version: 0.10.13 Release: 1.fc7 Size : 831 k Repo : updates Summary: GStreamer streaming media framework base plug-ins Description: GStreamer is a streaming media framework, based on graphs of filters which operate on media data. Applications using this library can do anything from real-time sound processing to playing videos, and just about anything else media-related. Its plugin-based architecture means that new data types or processing capabilities can be added simply by installing new plug-ins.
This package contains a set of well-maintained base plug-ins.
Name : gstreamer-plugins-good Arch : ppc Version: 0.10.5 Release: 6.fc7 Size : 746 k Repo : fedora Summary: GStreamer plug-ins with good code and licensing Description: GStreamer is a streaming media framework, based on graphs of filters which operate on media data. Applications using this library can do anything from real-time sound processing to playing videos, and just about anything else media-related. Its plugin-based architecture means that new data types or processing capabilities can be added simply by installing new plug-ins.
GStreamer Good Plug-ins is a collection of well-supported plug-ins of good quality and under the LGPL license.
[petro@Sulaco ~]$
====================================
So many words about licensing and other evil stuff but nothing about what's inside...
Peter Lemenkov wrote:
Heh :) Have you ever tried to install, say mp3-decoding plugins into GStreamer? There are a 4 subpackages with nothing-said-about-content names as gstreamer-plugins-bad, gstreamer-plugins-good etc. If I grep through "yum list" results I see nothing in this case but I never heard that anybody wants to change this situation.
Well, the above is really a bug to file for livna - but again - ask them to add provides.
In case of mp3 - yes. But what about flac, ogg, wavpack etc?
[petro@Sulaco ~]$ sudo yum install gstreamer-plugins-ogg fedora 100% |=========================| 2.1 kB 00:00 livna 100% |=========================| 2.1 kB 00:00 updates 100% |=========================| 1.9 kB 00:00 Setting up Install Process Parsing package install arguments Nothing to do [petro@Sulaco ~]$
Well in case off gstreamer-plugins-ugly from that other repo it has: Provides: gstreamer-mad = %{version}-%{release}
I agree, not very usefull to a casual user, but I think we all agree the current codec situation is a pain. With that said I'm all for virtual provides for gstreamer plugins to make things easier on the end user, the only problem is what do we put in those virtual provides?
Regards,
Hans
On Sat, 2007-09-08 at 16:34 +0200, Hans de Goede wrote:
Well in case off gstreamer-plugins-ugly from that other repo it has: Provides: gstreamer-mad = %{version}-%{release}
I agree, not very usefull to a casual user, but I think we all agree the current codec situation is a pain. With that said I'm all for virtual provides for gstreamer plugins to make things easier on the end user, the only problem is what do we put in those virtual provides?
For gstreamer, what about "gstreamer-plugin(<pluginname>) = <version>-<release>"? For example:
gstreamer-plugin(oggmux) = 0.10.13-1.fc7 gstreamer-plugin(vorbisenc) = 0.10.13-1.fc7 gstreamer-pligin(vorbisdec) = 0.10.13-1.fc7
Jeff
On Sat, 2007-09-08 at 16:10 -0500, Jeffrey C. Ollie wrote:
For gstreamer, what about "gstreamer-plugin(<pluginname>) = <version>-<release>"? For example:
gstreamer-plugin(oggmux) = 0.10.13-1.fc7 gstreamer-plugin(vorbisenc) = 0.10.13-1.fc7 gstreamer-pligin(vorbisdec) = 0.10.13-1.fc7
Better yet, scrap filenames altogether (use numbers or whatever) and grab all the meta-info from the file itself. The age of overloading of filenames is really starting to show. Maybe the start of the next-gen filesystem (no filenames) can start here, ;). --
Richi Plana
On Sat, 2007-09-08 at 15:12 +0200, Hans de Goede wrote:
Hi All,
A college of mine wanted to use umbrello in our Universities labs, since the Linux install there are Fedora he asked me about umbrello for Fedora.
Since I could NOT find it, I packaged it, see: https://bugzilla.redhat.com/show_bug.cgi?id=283471
But then I got a comment to the review it was already in Fedora in kdesdk. But then why on earth doesn't kdesdk have a Provides umbrello so that yum install umbrello works? Or even better an umbrello sub-package?
File a bug with the maintainer of kdesdk and ask them add provides for each of the programs that it includes.
Do it for all of the items you think is important. I think that's a fair thing to do.
-sv
seth vidal wrote:
On Sat, 2007-09-08 at 15:12 +0200, Hans de Goede wrote:
Hi All,
A college of mine wanted to use umbrello in our Universities labs, since the Linux install there are Fedora he asked me about umbrello for Fedora.
Since I could NOT find it, I packaged it, see: https://bugzilla.redhat.com/show_bug.cgi?id=283471
But then I got a comment to the review it was already in Fedora in kdesdk. But then why on earth doesn't kdesdk have a Provides umbrello so that yum install umbrello works? Or even better an umbrello sub-package?
File a bug with the maintainer of kdesdk and ask them add provides for each of the programs that it includes.
Do it for all of the items you think is important. I think that's a fair thing to do.
I forgot to say in my mail I already did that, see: https://bugzilla.redhat.com/show_bug.cgi?id=283521
But that still doesn't solve the version interlocking of completely unrelated packages.
Regards,
Hans
seth vidal wrote:
On Sat, 2007-09-08 at 15:12 +0200, Hans de Goede wrote:
Hi All,
A college of mine wanted to use umbrello in our Universities labs, since the Linux install there are Fedora he asked me about umbrello for Fedora.
Since I could NOT find it, I packaged it, see: https://bugzilla.redhat.com/show_bug.cgi?id=283471
But then I got a comment to the review it was already in Fedora in kdesdk. But then why on earth doesn't kdesdk have a Provides umbrello so that yum install umbrello works? Or even better an umbrello sub-package?
File a bug with the maintainer of kdesdk and ask them add provides for each of the programs that it includes.
Do it for all of the items you think is important. I think that's a fair thing to do.
I forgot to say in my mail I already did that, see: https://bugzilla.redhat.com/show_bug.cgi?id=283521
But that still doesn't solve the version interlocking of completely unrelated packages.
I agree (though I will start the umbrello review, examining all issues but the kdesdk one, which appear to be slogging out here :) ), but if kdesdk inclused umbrello, even if it does so along with 45 grintwillion other applications etc, until they either split out umbrello or include Provides, would not the umbrello package Conflict, and isn't that a No-No?
I'm all for having it sepearate, don't misunderstand, but don't our efforts depend somewhat on the actions of the kdesdk maintainer?
-Jon
Regards,
Hans
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Jon Ciesla wrote:
seth vidal wrote:
On Sat, 2007-09-08 at 15:12 +0200, Hans de Goede wrote:
Hi All,
A college of mine wanted to use umbrello in our Universities labs, since the Linux install there are Fedora he asked me about umbrello for Fedora.
Since I could NOT find it, I packaged it, see: https://bugzilla.redhat.com/show_bug.cgi?id=283471
But then I got a comment to the review it was already in Fedora in kdesdk. But then why on earth doesn't kdesdk have a Provides umbrello so that yum install umbrello works? Or even better an umbrello sub-package?
File a bug with the maintainer of kdesdk and ask them add provides for each of the programs that it includes.
Do it for all of the items you think is important. I think that's a fair thing to do.
I forgot to say in my mail I already did that, see: https://bugzilla.redhat.com/show_bug.cgi?id=283521
But that still doesn't solve the version interlocking of completely unrelated packages.
I agree (though I will start the umbrello review, examining all issues but the kdesdk one, which appear to be slogging out here :) ), but if kdesdk inclused umbrello, even if it does so along with 45 grintwillion other applications etc, until they either split out umbrello or include Provides, would not the umbrello package Conflict, and isn't that a No-No?
I'm all for having it sepearate, don't misunderstand, but don't our efforts depend somewhat on the actions of the kdesdk maintainer?
Yes they do (depend on the kdesdk maintainer), if I had known in advance that umbrello was already packaged, I wouldn't have started it. So if you could please review one of my packages from the games SIG instead, it will take a while before this gets resolved.
Regards,
Hans
On Sat, 2007-09-08 at 15:54 +0200, Hans de Goede wrote:
seth vidal wrote:
On Sat, 2007-09-08 at 15:12 +0200, Hans de Goede wrote:
Hi All,
A college of mine wanted to use umbrello in our Universities labs, since the Linux install there are Fedora he asked me about umbrello for Fedora.
Since I could NOT find it, I packaged it, see: https://bugzilla.redhat.com/show_bug.cgi?id=283471
But then I got a comment to the review it was already in Fedora in kdesdk. But then why on earth doesn't kdesdk have a Provides umbrello so that yum install umbrello works? Or even better an umbrello sub-package?
File a bug with the maintainer of kdesdk and ask them add provides for each of the programs that it includes.
Do it for all of the items you think is important. I think that's a fair thing to do.
I forgot to say in my mail I already did that, see: https://bugzilla.redhat.com/show_bug.cgi?id=283521
But that still doesn't solve the version interlocking of completely unrelated packages.
No, it doesn't. But since we're past freeze - adding a provide is much easier than breaking the entire package out.
-sv
Hi
On 9/8/07, seth vidal skvidal@fedoraproject.org wrote:
But that still doesn't solve the version interlocking of completely unrelated packages.
No, it doesn't. But since we're past freeze - adding a provide is much easier than breaking the entire package out.
Would this make a good Fedora 9 feature though? That is to say making it easier to remix parts of Fedora, or any other similar application?
-Yaakov
On 9/8/07, Hans de Goede j.w.r.degoede@hhs.nl wrote:
But then I got a comment to the review it was already in Fedora in kdesdk. But then why on earth doesn't kdesdk have a Provides umbrello so that yum install umbrello works? Or even better an umbrello sub-package?
Better search would solve this problem, too:
http://www.redhat.com/archives/fedora-devel-list/2007-May/msg01151.html
(I'm not sure there's a hard line for when you basically have to give up on categorization/naming standards and just rely on search, but I think the Fedora package collection is past it)
On 9/8/07, Hans de Goede j.w.r.degoede@hhs.nl wrote:
But then I got a comment to the review it was already in Fedora in kdesdk. But then why on earth doesn't kdesdk have a Provides umbrello so that yum install umbrello works? Or even better an umbrello sub-package?
Better search would solve this problem, too:
http://www.redhat.com/archives/fedora-devel-list/2007-May/msg01151.html
(I'm not sure there's a hard line for when you basically have to give up on categorization/naming standards and just rely on search, but I think the Fedora package collection is past it)
I must have missed it in May. +1 WouldBeAwesomeUnlessTheresAYumPluginThatWeAlreadyHaveThatWouldDoThis
In which case we build a web front end and Bob's your uncle.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Sat, 2007-09-08 at 12:09 -0400, Colin Walters wrote:
On 9/8/07, Hans de Goede j.w.r.degoede@hhs.nl wrote:
But then I got a comment to the review it was already in Fedora in kdesdk. But then why on earth doesn't kdesdk have a Provides umbrello so that yum install umbrello works? Or even better an umbrello sub-package?Better search would solve this problem, too:
http://www.redhat.com/archives/fedora-devel-list/2007-May/msg01151.html
(I'm not sure there's a hard line for when you basically have to give up on categorization/naming standards and just rely on search, but I think the Fedora package collection is past it)
You don't want 'yum search' to always search every file in the distribution. Searching every file will just take a long time. And, in fact, you will routinely find that what you're searching for in the package is never explicitly listed in any of the file lists.
so that leaves us two options: - we include some sort of keyword tag in the pkg metadata - we include some sort of keyword metadata file in the repodata
Doing either of those and having yum search them if they are available is do-able. We talked about this before, iirc. We just need to decide which one is more palatable and do it.
-sv
On Sat, 2007-09-08 at 12:09 -0400, Colin Walters wrote:
On 9/8/07, Hans de Goede j.w.r.degoede@hhs.nl wrote:
But then I got a comment to the review it was already in Fedora in kdesdk. But then why on earth doesn't kdesdk have a Provides umbrello so that yum install umbrello works? Or even better an umbrello sub-package?Better search would solve this problem, too:
http://www.redhat.com/archives/fedora-devel-list/2007-May/msg01151.html
(I'm not sure there's a hard line for when you basically have to give up on categorization/naming standards and just rely on search, but I think the Fedora package collection is past it)
You don't want 'yum search' to always search every file in the distribution. Searching every file will just take a long time. And, in fact, you will routinely find that what you're searching for in the package is never explicitly listed in any of the file lists.
so that leaves us two options:
- we include some sort of keyword tag in the pkg metadata
- we include some sort of keyword metadata file in the repodata
Doing either of those and having yum search them if they are available is do-able. We talked about this before, iirc. We just need to decide which one is more palatable and do it.
Or, utilize pkgdb for this task. Maybe capture the data at build time with some sort of hook in koji? A tiny delay in each build, while the equivalent of an rpm -qa foo is dumped into pkgdg. This could then make not only searching but finding conflicts a snap. You would even build in a form where you could paste the rpm -qa foo of a new package during the review step and it would check the pkgdb so you know with absolute certainty that the new package does not conflict with something existing, or if it does, you know where.
-sv
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
A college of mine wanted to use umbrello in our Universities labs, since the Linux install there are Fedora he asked me about umbrello for Fedora.
Just in case you are looking for a Qt based UML tool, you can also try out BOUML ('bouml' in Fedora).
Regards, Debarshi
On Sat, 2007-09-08 at 23:50 +0530, Debarshi 'Rishi' Ray wrote:
A college of mine wanted to use umbrello in our Universities labs, since the Linux install there are Fedora he asked me about umbrello for Fedora.
Just in case you are looking for a Qt based UML tool, you can also try out BOUML ('bouml' in Fedora).
Know a good Gnome- or even just Gtk2-based UML tool (that's actually useful for programming)? --
Richi Plana
On Sat, 2007-09-08 at 15:12 +0200, Hans de Goede wrote:
Also I think it is a very bad idea to ship packages with a clearly seperate upstream in some kinda bundle form. Sticking with the umbrello example, in order for the latest version to be included into Fedora, we must wait for a new upstream kdesdk release, which likely won't happen before there is a kdesdk4 in some far away future, as kde3 is as good as EOL.
Read the thread I started entitled "Goal: Increased Modularity". People are saying that Fedora is aimed at distro-makers who want to create spins of their own from Fedora. This is only possible if it actually CAN be broken down into the pieces that you want. Currently, there are no policies which even mention modularity, but most of the developers have come to the same conclusion. There's a faction which believe that it's easier to maintain something when they're all lumped together. Then there are those who believe it's easier for individual volunteers to maintain packages if they're cut down to smaller pieces.
It's clear where my opinions lie. --
Richi Plana
On Sat, 2007-09-08 at 15:01 -0600, Richi Plana wrote:
Read the thread I started entitled "Goal: Increased Modularity". People are saying that Fedora is aimed at distro-makers who want to create spins of their own from Fedora. This is only possible if it actually CAN be broken down into the pieces that you want. Currently, there are no policies which even mention modularity, but most of the developers have come to the same conclusion. There's a faction which believe that it's easier to maintain something when they're all lumped together. Then there are those who believe it's easier for individual volunteers to maintain packages if they're cut down to smaller pieces.
Lumping multiple separately versioned, separately released entities into the same SRPM is broken, period.
If upstream is lumping a ton of stuff into one tarball, its an upstream bug.
Callum Lerwick wrote:
On Sat, 2007-09-08 at 15:01 -0600, Richi Plana wrote:
Read the thread I started entitled "Goal: Increased Modularity". People are saying that Fedora is aimed at distro-makers who want to create spins of their own from Fedora. This is only possible if it actually CAN be broken down into the pieces that you want. Currently, there are no policies which even mention modularity, but most of the developers have come to the same conclusion. There's a faction which believe that it's easier to maintain something when they're all lumped together. Then there are those who believe it's easier for individual volunteers to maintain packages if they're cut down to smaller pieces.
Lumping multiple separately versioned, separately released entities into the same SRPM is broken, period.
If upstream is lumping a ton of stuff into one tarball, its an upstream bug.
Thats a very short way of saying exactly what I was trying to say, thanks!
Regards,
Hans
Hi,
But then I got a comment to the review it was already in Fedora in kdesdk. But then why on earth doesn't kdesdk have a Provides umbrello so that yum install umbrello works?
So one cool feature I learned about a while ago (that you may already know about) with yum is you can do
yum install /usr/bin/umbrello
or whatever the full path to the program is, and it will automatically grab the right package. Of course, that feature is only useful if you already know the name of the binary, and where it's getting installed to.
Also I think it is a very bad idea to ship packages with a clearly seperate upstream in some kinda bundle form.
Couldn't agree more. For a while we shipped gcalctool and zenity in gnome-utils. it was a maintainability nightmare.
--Ray
On Tue, 2007-09-11 at 01:05 -0400, Ray Strode wrote:
Hi,
But then I got a comment to the review it was already in Fedora in kdesdk. But then why on earth doesn't kdesdk have a Provides umbrello so that yum install umbrello works?
So one cool feature I learned about a while ago (that you may already know about) with yum is you can do
yum install /usr/bin/umbrello
or whatever the full path to the program is, and it will automatically grab the right package. Of course, that feature is only useful if you already know the name of the binary, and where it's getting installed to.
Right- yum can install using provides as the key.
This is why I suggested packages containing more than one program should provide the name of the other programs explicitly.
Then:
yum install umbrello
would work.
-sv
On Tue, 2007-09-11 at 09:03 -0400, seth vidal wrote:
Right- yum can install using provides as the key.
This is why I suggested packages containing more than one program should provide the name of the other programs explicitly.
Then:
yum install umbrello
would work.
Would there ever be a danger where overriding package names (via virtual packages) might result in ambiguities? So package names would now mean program names, as well? Would there be a problem if a real package were to be added to the repo (or some repo)? What would yum (or the resolver) base its decision on? I'm not too comfortable with overriding it using the full path ("/usr/bin/umbrello") but at least it disambiguates much better than the other. (And I figure it's too much to put in a language for specifying other parameters such as "yum install --program-name=umbrello" or "--lib=c").
Just posing questions. --
Richi Plana
On Tue, 2007-09-11 at 10:51 -0600, Richi Plana wrote:
On Tue, 2007-09-11 at 09:03 -0400, seth vidal wrote:
Right- yum can install using provides as the key.
This is why I suggested packages containing more than one program should provide the name of the other programs explicitly.
Then:
yum install umbrello
would work.
Would there ever be a danger where overriding package names (via virtual packages) might result in ambiguities? So package names would now mean program names, as well?
you mean if there were multiple things providing 'umbrello' that's just like any other multiple-provider situation.
Would there be a problem if a real package were to be added to the repo (or some repo)? What would yum (or the resolver) base its decision on?
the decision works now as: - best arch for the system - shortest name - first in the list
I'm not too comfortable with overriding it using the full path ("/usr/bin/umbrello") but at least it disambiguates much better than the other. (And I figure it's too much to put in a language for specifying other parameters such as "yum install --program-name=umbrello" or "--lib=c").
yes - that's just not sane.
-sv
On 11/09/2007, Richi Plana myfedora@richip.dhs.org wrote:
On Tue, 2007-09-11 at 09:03 -0400, seth vidal wrote:
Right- yum can install using provides as the key.
This is why I suggested packages containing more than one program should provide the name of the other programs explicitly.
Then:
yum install umbrello
would work.
Would there ever be a danger where overriding package names (via virtual packages) might result in ambiguities? So package names would now mean program names, as well? Would there be a problem if a real package were to be added to the repo (or some repo)? What would yum (or the resolver)
If someone were to provide umbrello as a separate package while the kdesdk package from Fedora still contains it as well, you have a problem anyway, since it will also provide /usr/bin/umbrello.
Unless the 3rd-party umbrello was packaged with this in mind, and install in some other prefix.
Regards,
Ray Strode <halfline <at> gmail.com> writes:
Also I think it is a very bad idea to ship packages with a clearly seperate upstream in some kinda bundle form.
Couldn't agree more. For a while we shipped gcalctool and zenity in gnome-utils. it was a maintainability nightmare.
That's a different situation: you added those extra tarballs to the package. The upstream kdesdk tarball actually _contains_ Umbrello and builds it with no extra magic. (That magic would be needed _not_ to build it there, e.g. the DO_NOT_COMPILE hack.) It is _also_ released separately. And it is maintained upstream as part of kdesvn, the separate releases are actually cut from the KDE 3.5 SVN branch as well.
Kevin Kofler
-
Arthur Pemberton -
Callum Lerwick -
Colin Walters -
Debarshi Ray -
Hans de Goede -
Jef Spaleta -
Jeffrey Ollie -
Jon Ciesla -
Kevin Kofler -
Matej Cepl -
Michel Salim -
Nicolas Mailhot -
Peter Lemenkov -
Ray Strode -
Richi Plana -
Seth Vidal -
Till Maas -
Yaakov Nemoy