[gobolinux-users] what is going on with revisions and recipes and binaries?

[Michael Homer]

On 10/24/07, Isaac Dupree <isaacdupree at charter.net> wrote:
> Freshen tells me most things have at least Recipe, and version -r1, -r2
> or whatever.  Sometimes there are exceptions, probably indicating
> recipes were not uploaded first and accurately...  EnhancedSkel is also
> "binary"-only, but it's special?
>
> Some updates with KDE recently have had many of these effects... here is
> a selection of Freshen output for me, plus my interpretations of what
> needs doing (Xine-Lib plus KDE pieces)
>
> [IUX] KDE-Libs 3.5.8-r1                               3.5.7-r1
> correct
> [IUX] KDE-Base 3.5.8                                     3.5.3
> needs -r1
> [IUX] KDE-PIM 3.5.8                                      3.5.3
> needs -r1
> [IUX] KDE-Graphics 3.5.8                                 3.5.3
> needs -r1
> [IUX] Xine-Lib 1.1.7                                     1.1.6
> needs -r1
> [IUX] KDE-Multimedia 3.5.7                               3.5.3
> needs upgrade to 3.5.8, and -r1
> [IUX] KDE-Utils 3.5.8                                    3.5.3
> needs -r1
> [IUB] KDE-Network 3.5.8                                  3.5.3
> needs recipe to be provided, and -r1
The versions displayed involve a little bit of guesswork; the issue is
that while recipes always have revisions available, packages don't.
Those are the cases that list as bare "3.5.8": the package is named
KDE-Base--3.5.8--i686.tar.bz2, while the other is called
KDE-Libs--3.5.8-r1--i686.tar.bz2. In the bare case, Freshen assumes
it's -r1 and uses that internally (so you won't be upgraded from 3.5.8
to 3.5.8-r1; I decided that was better even when it's possible the
package corresponds to -r2), but displays it as it was provided,
because calling "InstallPackage KDE-Base 3.5.8-r1" will fail, while
"3.5.8" will pick up a revision if there is one.

I really consider this a bug in how packages are named; I think they
should all have revisions explicitly. I'm not sure why some end up
with them and some don't.

> Is there some way to see a list of all official packages that don't have
> corresponding official recipes, not just the ones Freshen finds?  (when
> the package was created from a recipe, and the program is GPL'ed, this
> really shouldn't happen...)
I don't think there is, but it wouldn't be too hard to hack up on the
command line using the manifest files. The problem would be figuring
out which revision (if any) the package corresponds to if it isn't
specified.
-Michael