Removing Icon: tag in spec files

The Icon: tag was a GNOME dain-bread implementation that has
never  
worked
with rpm packages.

While associating icon's with packages is an entirely
sensible goal, the
current implementation is utterly feeble and useless.

I think I last tried to use Icon: in the summer of '98
within RHL  
5.1. The experience
hurt my brain so badly that I have never ever tried to use
icons since.

I'll leave flags and markers for associating icon's with
packages as  
I bulldoze
the thoroughly rotten current implementation, preparing to 

associating iscons
with, but not in, *.rpm packages.

But the current Icon: implementation with *.spec is going
away.

73 de Jeff
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Mar 29, 2007, at 9:17 AM, Jeff Johnson wrote:

> The Icon: tag was a GNOME dain-bread implementation
that has never  
> worked
> with rpm packages.
>
> While associating icon's with packages is an entirely
sensible  
> goal, the
> current implementation is utterly feeble and useless.
>
> I think I last tried to use Icon: in the summer of '98
within RHL  
> 5.1. The experience
> hurt my brain so badly that I have never ever tried to
use icons  
> since.
>
> I'll leave flags and markers for associating icon's
with packages  
> as I bulldoze
> the thoroughly rotten current implementation, preparing
to  
> associating iscons
> with, but not in, *.rpm packages.
>
> But the current Icon: implementation with *.spec is
going away.
>

Hmmm, I tried to unplug life support for Icon: and the
patient woke up.
Go figger.

It's likely going to be easier to fix Icon: than remove it
entirely.

The attached patch is a healthy start at including a single
GIF icon  
file
in the entire set (i.e. srpms/rpms) of packages from a
build.

There's more to do to, like parsing out the favicon url from
a url that
points somewhere, but I'll let the current bits compost a
bit before
attempting HTML parsing.

FWIW, I already have a proof-of-concept implementation based
on
the rather sane libxml2 HTML parser. I much prefer the wget
state
machine, but alas, GPL poisoned code that the LGPL lunatic
fringe cannot touch.

Enjoy!

73 de Jeff

_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Saturday, 31 March 2007, at 15:21:32 (-0400),
Jeff Johnson wrote:

> Hmmm, I tried to unplug life support for Icon: and the
patient woke
> up.  Go figger.

Just out of curiosity, what happened when you tried to kill
it?

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/ 
<mejkainx.org>
n + 1, Inc., http://www.nplus1.net/    
  Author, Eterm (www.eterm.org)
------------------------------------------------------------
-----------
 "I have gotten into the habit of recording important
meetings.  One
  never knows when an inconvenient truth will fall between
the cracks
  and vanish."               -- Ambassador Londo
Mollari, Babylon Five
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On 4/1/07, Michael Jennings <mejkainx.org> wrote:
> On Saturday, 31 March 2007, at 15:21:32 (-0400),
> Jeff Johnson wrote:
>
> > Hmmm, I tried to unplug life support for Icon: and
the patient woke
> > up.  Go figger.
>
> Just out of curiosity, what happened when you tried to
kill it?
>

Well, the first thing that happened is that I started to
sneeze. I'm allergic
to rotten code mold and loblolly pine pollen.

Then I started to get bored, ripping out dead code without
explosives is
like scaling rust and barnacles off the Titanic. Chip, chip,
chip ... with
a hammer and chisel.

Some of the nearby barnacles, like RPMTAG_DISTTAG and (added
last week)
RPMTAG_REPOTAG started me thinking about the relationship
between
branding and packaging. Packaging is the calcium shell that
protects the
contents within was the easier metaphor, branding as the
feathery tendrils
that reach out and collect ... well that metaphor did not
work any better
than GIF's in a rpm spec file Icon: did.

So what was wrong with Icon:? The part of the implementation
that terrified
me way back when was the GIF licensing scare way (1998?
1999? I fergit ...).
That led to alternative formats like XPM (which rpm handles)
and PNG,
and TIFF, and JPG, and ... A minimal necessary
implementation for
Icon: requires verifying that the octets, indeed, are
meaningful. Otherwise
Icon: is a nearly perfect virus infection route. Verifying
every bleeping
graphical format that exists is not what I wish to be
coding.

FWIW, my terror of PNG et al graphical format verification
led to the
libmagic file
classification currently in rpm, but that's a different
story ...

Another part of what made Icon: nasty to use with rpm was
that the original
implementation was per-binary, not per-source, package.
While per-binary
package is perhaps the natural enginerring design paradigm,
rpmbuild is mostly
implemented around a Spec structure, and per-binary icons
really twisted up the
rpmbuild code.

Which brought me back to branding: A brand mechanism is a
one-to-many
relationship from a producer onto product. Think: ranch
-> cattle. So
per-binary (possibly) different icons as in rpm was flawed
by design
because there's no clear producer, and the semiotics of the
brand
signification is obscured. Sound
engineering solved the wrong problem is another way to say
the same thing.

So I nuked a bunch of per-binary data structures, added
%_icondir like
%_patchdir
and %_sourcedir (i.e. /usr/src/rpm/SOURCES default value),
fiddled up
Local/Remote
fetching (fixing 4-5 places where %_patchdir wasn't
implemented correctly), and
overall reafactored Icon: to be per-source (with per-binary
inheiritance) package.

Good, less code, fewer bugs, cleaner design and prettier
packaging. Lord knows
that using Release: with %{?disttag} and % and all
the other gunk is
more primitive semiotics than an icon. I suggest that icon's
are better brand
identifiers than %{?disttag} and %{?repotag} will ever be.

What still remains to be done is to get Icon: associated
with, but not in,
packages. I can easily hear the screams when the distro icon
is changed
during the last week of a release . Adding
static content is the first step
to a header extension which accomplishes the external
association.

And favicon.ico are a rather simple content distribution
gedanken for
development,
far simpler than pulling Sun java (or other) nosource rpm's
and
re-building locally
because of stupid packaging and licensing problems.

So the patient dinna die ...

73 de Jeff
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Sunday, 01 April 2007, at 08:10:57 (-0400),
Jeff Johnson wrote:

> FWIW, my terror of PNG et al graphical format
verification led to
> the libmagic file classification currently in rpm, but
that's a
> different story ...

That's one heck of a history lesson, thanks. 

What was the original purpose of Icon: anyway?  Something to
display
in a package management GUI?  Is that still the intended
purpose?  I'm
mostly wondering package vs. distro branding....

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/ 
<mejkainx.org>
n + 1, Inc., http://www.nplus1.net/    
  Author, Eterm (www.eterm.org)
------------------------------------------------------------
-----------
 "When my time is up, I want to know that I did one
thing well:  Love
  somebody.  The rest of this is just an expression of that
one
  thing."                 -- Julie Bowen (Aunt Gwen),
"Dawson's Creek"
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On 4/3/07, Michael Jennings <mejkainx.org> wrote:
> On Sunday, 01 April 2007, at 08:10:57 (-0400),
> Jeff Johnson wrote:
>
> > FWIW, my terror of PNG et al graphical format
verification led to
> > the libmagic file classification currently in rpm,
but that's a
> > different story ...
>
> That's one heck of a history lesson, thanks. 
>
> What was the original purpose of Icon: anyway? 
Something to display
> in a package management GUI?  Is that still the
intended purpose?  I'm
> mostly wondering package vs. distro branding....
>

Guessing from who implemented and when (birthing of GNOME)
I'd
suggest that the use was in a package management GUI.

And the flaw was package branding (which is how OSS used to
function) versus
distro/repo branding (which seems to be widely current
today).

Just guesses, RPMTAG_ICON implementation is before my time.

73 de Jeff
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel