sane dependencies -- a positive look at 'fix your packages'

[Andy Hanton]

I think that the 'Kind request: fix your packages' thread is going off
course by discussing how to fix what we have instead of what we need to
implement to make Sean's vision possible while making it possible to
support older systems easily.

I think that we need development tools that work more like the tools on
Mac OS classic. Macs didn't actually have libraries so they got some
very cool features for free. You can actually build an application on
Mac OS 9 and run it on Mac OS 1. You don't need a chroot environment or
any other fancy setup. All you need to do is stick to the API that Mac
OS 1.0 supported and it just works. The bad part was that if you used a
function that wasn't supported the application would crash at runtime.
Because Linux has library versioning it should be able to get the
flexibility of compiling easily for older systems while knowing for sure
that the binary will work on the old systems.

On Linux the dependencies of a library or binary get inflated by the
system. For example all binaries built on Redhat 9 depend on libc 2.3
but they usually don't depend on any new APIs introduced in 2.3. If
each developer compiled against the minimal library versions necessary
then the resulting binaries would be nearly universal when used with an
rpm repository. For example it would be possible to compile abiword 2.0
with gnome support on RedHat 9 or Fedora 1.0 and have the same binary
run on redhat 7.3. The package manager would automatically the gnome2
platform libraries from the Fedora 1.0 release and install them.
Although it would require more disk space, end users would probably
prefer to have only one Linux/i386 binary just like there is only one
Windows binary.

I am not a compiler guru, so I don't know how we get there. It might be
a good idea to compile the core of the OS inside a LSB chroot. Another
possibility might be using pkg-config to request a specific minor
version of a library. It might look something like gcc -o foo foo.c
`pkg-config --cflags --libs gtk+-2.0:2.0 libgnome-2.0:2.0 libc-2:2.2`

The library would implement this by specifying a preprocessor macro to
set with the requested library version number. Then it would add ifdefs
to the headers so that only the symbols available in the particular
version would be available. It would be cool to support aliases for
different versions. For example gtk+-2.0:LSB_2_0 might be equivalent to
gtk+-2.0:2.0.

There might be some extra linker magic necessary, but since RedHat
employs lots of compiler tool chain experts I don't think it would be
impossible. It might be possible to reuse whatever tools the LSB
project is using to generate stub libraries for each minor version of
every library.

To make the automatic dependency fetching work right the repository
should probably provide a mapping between library names and package
names. I would think that it would be easy to write a script that would
extract this information from all the rpms in a yum or apt-get
repository and write it to a file with a standardized name and
location.

In this setup a few programs that can optionally use a feature that a
newer distribution has would need to be compiled more than once.
Packagers wouldn't need to figure out the dependency information because
the developer would have already done that work. Unfortunately, if a
single binaries could be built to run on any recent Linux system, then
the author of the code would probably package the binary themselves.
Some Fedora developers would need to find a new way to spend their free
time. ;-)

[Ulrich Drepper]

Post by Andy Hanton
On Linux the dependencies of a library or binary get inflated by the
system. For example all binaries built on Redhat 9 depend on libc 2.3
but they usually don't depend on any new APIs introduced in 2.3.

That's wrong. The versioning mechanism always picks the minimum
required versions. There is no automatic inflation. The fact that most
apps linked against glibc 2.3 will also require GLIBC_2.3 is that some
fundamental interfaces changed.

Post by Andy Hanton
It might look something like gcc -o foo foo.c
`pkg-config --cflags --libs gtk+-2.0:2.0 libgnome-2.0:2.0 libc-2:2.2`

That's something I never want to see. Compiling against old headers and
linking with old libraries always means a) more bugs and b) less optimal
results. For instance, compile some code using conditional variables
with old headers and new headers, and compare the resulting performance
and memory consumption (and maybe even stability).

If I have the possibility to have better binaries I am not willing to
give this up just because some people clinch to their old installations
and demand equal treatment when it comes to package updates.

[Michael Schwendt]

Post by Andy Hanton
I think that the 'Kind request: fix your packages' thread is going off
course by discussing how to fix what we have instead of what we need to
implement to make Sean's vision possible while making it possible to
support older systems easily.

What exactly is Sean's vision? It might be just me, but I don't think
that became clear in the controversy due to misunderstandings (e.g.
with regard to optional [versioned] build requirements). Maybe someone
can sum up a few major flaws in current "RPM packaging" with regard to
packagers and package users and outline the changes that are supposed
to improve the situation.

Btw, if you're asking for major efforts to make the life easier for a
tiny group of users, who stick to an old distribution and who want to
install the latest and greatest software in form of prebuilt packages
nevertheless, I think that's a hopeless venture due to API and ABI
changes.

- --
Michael, who doesn't reply to top posts and complete quotes anymore.

[Sean Middleditch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Andy Hanton
I think that the 'Kind request: fix your packages' thread is going off
course by discussing how to fix what we have instead of what we need to
implement to make Sean's vision possible while making it possible to
support older systems easily.

What exactly is Sean's vision? It might be just me, but I don't think
that became clear in the controversy due to misunderstandings (e.g.
with regard to optional [versioned] build requirements). Maybe someone
can sum up a few major flaws in current "RPM packaging" with regard to
packagers and package users and outline the changes that are supposed
to improve the situation.

Most basic theme of my misunderstood ;-) ranting - only one package per
application, ever. Package always works, save asking for dependencies,
of which there are also only one package for each. Only in cases of
true (but hopefully avoidable) platform incompatibility should this be
broken.

Given the autopackage project, RPMs and their (possible) problems may in
the future just be relegated to low-level system stuff, which is another
solution, but one not yet ready.

Btw, if you're asking for major efforts to make the life easier for a
tiny group of users, who stick to an old distribution and who want to
install the latest and greatest software in form of prebuilt packages
nevertheless, I think that's a hopeless venture due to API and ABI
changes.
- --
Michael, who doesn't reply to top posts and complete quotes anymore.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD4DBQE/ftXv0iMVcrivHFQRAoT1AJiZmB6ltNT9oLtKiaBnlGWj5RoAAJ0VryrW
W1TGtmWBb1dTZeQXr1eZfA==
=xHlQ
-----END PGP SIGNATURE-----
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

[Michael Schwendt]

Post by Sean Middleditch
Given the autopackage project, RPMs and their (possible) problems may in
the future just be relegated to low-level system stuff, which is another
solution, but one not yet ready.

This one? http://autopackage.org/faq.html Doesn't look promising
in the middle of the FAQ.

- --
Michael, who doesn't reply to top posts and complete quotes anymore.

[Andy Hanton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Sean Middleditch
Given the autopackage project, RPMs and their (possible) problems may in
the future just be relegated to low-level system stuff, which is another
solution, but one not yet ready.

This one? http://autopackage.org/faq.html Doesn't look promising
in the middle of the FAQ.

They aren't the only ones working on this stuff. The zero-install
project (http://zero-install.sf.net/) seems to be trying for a more
interesting solution. They actually link software to libraries using a
caching http filesystem. For example, an application that needs gtk2
would link to /uri/0install/www.gtk.org/gtk2/libgtk-x11-2.0.so. So it
doesn't need the funny hacks autopackage uses to detect what the user
has installed. The user can double click the application and all the
dependencies are downloaded automatically and doing so never breaks
anything else on the system.

[Nicolas Mailhot]

Post by Andy Hanton

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Sean Middleditch
Given the autopackage project, RPMs and their (possible) problems may in
the future just be relegated to low-level system stuff, which is another
solution, but one not yet ready.

This one? http://autopackage.org/faq.html Doesn't look promising
in the middle of the FAQ.

They aren't the only ones working on this stuff. The zero-install
project (http://zero-install.sf.net/) seems to be trying for a more
interesting solution. They actually link software to libraries using a
caching http filesystem. For example, an application that needs gtk2
would link to /uri/0install/www.gtk.org/gtk2/libgtk-x11-2.0.so. So it
doesn't need the funny hacks autopackage uses to detect what the user
has installed. The user can double click the application and all the
dependencies are downloaded automatically and doing so never breaks
anything else on the system.

And how do you trust the result ?
RPMs at least are signed.
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20031004/961b19a6/attachment.bin

[Andy Hanton]

Post by Nicolas Mailhot

Post by Andy Hanton

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Sean Middleditch
Given the autopackage project, RPMs and their (possible) problems may in
the future just be relegated to low-level system stuff, which is another
solution, but one not yet ready.

This one? http://autopackage.org/faq.html Doesn't look promising
in the middle of the FAQ.

They aren't the only ones working on this stuff. The zero-install
project (http://zero-install.sf.net/) seems to be trying for a more
interesting solution. They actually link software to libraries using a
caching http filesystem. For example, an application that needs gtk2
would link to /uri/0install/www.gtk.org/gtk2/libgtk-x11-2.0.so. So it
doesn't need the funny hacks autopackage uses to detect what the user
has installed. The user can double click the application and all the
dependencies are downloaded automatically and doing so never breaks
anything else on the system.

And how do you trust the result ?
RPMs at least are signed.

I would assume that the daemon that runs the /uri filesystem would check
signatures on downloads. I don't think it does yet but there is no
reason that it couldn't. Some effort would be necessary to set up a web
of trust so that the user didn't have to decide if the keys were valid.

I believe that the zero-install system actually downloads the contents
of directories as tarballs, so the could just sign the tarball for each
release. I don't really see how that is any worse than what rpm
offers.

There is already a per user daemon in the system responsible for
displaying download progress bars and stuff. If the signature checking
failed it could present the user with a nice dialog saying that the
software couldn't be run.

[Andy Hanton]

Post by Nicolas Mailhot

Post by Andy Hanton

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Sean Middleditch
Given the autopackage project, RPMs and their (possible) problems may in
the future just be relegated to low-level system stuff, which is another
solution, but one not yet ready.

This one? http://autopackage.org/faq.html Doesn't look promising
in the middle of the FAQ.

They aren't the only ones working on this stuff. The zero-install
project (http://zero-install.sf.net/) seems to be trying for a more
interesting solution. They actually link software to libraries using a
caching http filesystem. For example, an application that needs gtk2
would link to /uri/0install/www.gtk.org/gtk2/libgtk-x11-2.0.so. So it
doesn't need the funny hacks autopackage uses to detect what the user
has installed. The user can double click the application and all the
dependencies are downloaded automatically and doing so never breaks
anything else on the system.

And how do you trust the result ?
RPMs at least are signed.

I would assume that the daemon that runs the /uri filesystem would check
signatures on downloads. I don't think it does yet but there is no
reason that it couldn't. Some effort would be necessary to set up a web
of trust so that the user didn't have to decide if the keys were valid.

I believe that the zero-install system actually downloads the contents
of directories as tarballs, so the could just sign the tarball for each
release. I don't really see how that is any worse than what rpm
offers.

There is already a per user daemon in the system responsible for
displaying download progress bars and stuff. If the signature checking
failed it could present the user with a nice dialog saying that the
software couldn't be run.

[Michael Schwendt]

Post by Andy Hanton
They aren't the only ones working on this stuff. The zero-install
project (http://zero-install.sf.net/) seems to be trying for a more
interesting solution. They actually link software to libraries using a
caching http filesystem. For example, an application that needs gtk2
would link to /uri/0install/www.gtk.org/gtk2/libgtk-x11-2.0.so.

Treat me like a dumb user, please. In which way is that better than
the current dependency on libgtk-x11-2.0.so.0? What problems is it
supposed to fix?

Post by Andy Hanton
So it
doesn't need the funny hacks autopackage uses to detect what the user
has installed.

$ rpm --redhatprovides libgtk-x11-2.0.so.0
gtk2-2.2.1-4

Post by Andy Hanton
The user can double click the application and all the
dependencies are downloaded automatically and doing so never breaks
anything else on the system.

We do have that feature already, don't we?

- --
Michael, who doesn't reply to top posts and complete quotes anymore.

[Andy Hanton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Andy Hanton
They aren't the only ones working on this stuff. The zero-install
project (http://zero-install.sf.net/) seems to be trying for a more
interesting solution. They actually link software to libraries using a
caching http filesystem. For example, an application that needs gtk2
would link to /uri/0install/www.gtk.org/gtk2/libgtk-x11-2.0.so.

Treat me like a dumb user, please. In which way is that better than
the current dependency on libgtk-x11-2.0.so.0? What problems is it
supposed to fix?

The idea is that the same library could be used on debian or Suse or
whatever. Basically it effects end users, but it doesn't really solve
any problems for Fedora developers.

Post by Andy Hanton
So it
doesn't need the funny hacks autopackage uses to detect what the user
has installed.

$ rpm --redhatprovides libgtk-x11-2.0.so.0
gtk2-2.2.1-4

It doesn't really help as much for common libraries. The idea is that
library authors can maintain their own binaries. Application authors
can be sure that the end user's system will be able to find the library
because the url is embedded in the binary.

Try rpm --redhatprovides libenchant.so.1.0.0 on a redhat 9 box.
/uri/0install/www.abisource.com/enchant/libenchant.so.1.0.0
would clearly be better in that case.

I think the idea that we can package all the dependencies that could
ever exist is unrealistic. Even if we become like debian with 10,000
packages that won't solve the cross distribution problem. You can't
tell your grandmother who runs Suse to go to the web page and download
an rpm because suse hasn't packaged all the dependencies.

Post by Andy Hanton
The user can double click the application and all the
dependencies are downloaded automatically and doing so never breaks
anything else on the system.

We do have that feature already, don't we?

No, we don't. With zero-install the user never actually uses a package
management system.

Here is how it works:
1.download an application from the author's web page
2. double click the archive to untar it
3. double-click the application and it runs

Basically the user does not need to think about finding a binary for
their specific distribution or understand dependencies or package
management. It provides Mac OS X type simplicity on Linux.

[Michael Schwendt]

Post by Andy Hanton
It doesn't really help as much for common libraries. The idea is that
library authors can maintain their own binaries. Application authors
can be sure that the end user's system will be able to find the library
because the url is embedded in the binary.

So, in other words I would depend on arbitrary sites to supply prebuilt
libraries rather than getting software from trusted community
repositories? Would those prebuilt libraries be of the same poor quality
than what is offered on the average upstream site? The average upstream
site features contributed packages. Contributed by individuals. The same
individual who would contribute their packages to a community project,
provided that such a community project is available.

Post by Andy Hanton
Try rpm --redhatprovides libenchant.so.1.0.0 on a redhat 9 box.
/uri/0install/www.abisource.com/enchant/libenchant.so.1.0.0
would clearly be better in that case.

Not clear at all. Why would I need that library? Why wouldn't it be
found automatically when I install an application with e.g. Yum? Why
hasn't anyone created a src.rpm for it? Aha, the software is complicated
to install from source? There we have the real problem.

Post by Andy Hanton
I think the idea that we can package all the dependencies that could
ever exist is unrealistic.

Only what is popular or worthwhile gets packaged by someone.
Everything else can be rebuilt from source.

Post by Andy Hanton
Even if we become like debian with 10,000
packages that won't solve the cross distribution problem.

Ah, cross-distribution. *cough* Who makes sure that app A from site B
and lib D from site E for distribution C work smoothly on distribution
F where inter-library dependencies are satisfied with packages from
site G? Where is the testing and quality assurance in this scenario?

Post by Andy Hanton
You can't
tell your grandmother who runs Suse to go to the web page and download
an rpm because suse hasn't packaged all the dependencies.

Isn't that what Fedora Extras tries to target? The chance for the
community to package the popular stuff and maintain it as long as
their is enough interest in it?

Post by Andy Hanton
With zero-install the user never actually uses a package
management system.
1.download an application from the author's web page
2. double click the archive to untar it
3. double-click the application and it runs

Scary scenario. Even more scary when the application asks for
superuser privileges in order to perform some ordinary integration
tasks. The scenario gets threatening when the author of the
application focuses on prebuilt binaries as primary distribution
channel and neglects the source code level. Oh, and don't dare to
report a bug to the author when you run a different distribution.

- --
Michael, who doesn't reply to top posts and complete quotes anymore.

[Havoc Pennington]

Post by Michael Schwendt

Post by Andy Hanton
Even if we become like debian with 10,000
packages that won't solve the cross distribution problem.

Ah, cross-distribution. *cough* Who makes sure that app A from site B
and lib D from site E for distribution C work smoothly on distribution
F where inter-library dependencies are satisfied with packages from
site G? Where is the testing and quality assurance in this scenario?

The solution to end-user dependency problems is very simple, and it is
the same one used on Windows.

Here it is: don't have any dependencies that don't come with the OS.
Bundle everything internal to your app.

This is what almost all proprietary software for Linux does.

It's also what an LSB-compliant package _must_ do. But of course, nobody
seems to make LSB-compliant packages, instead they just complain about
how packages are distribution-dependent. ;-) People, this is the whole
point of the LSB...

For software that comes with the OS and lives in the Fedora Project, we
should be able to do better; redhat-config-packages doesn't make you see
dependencies really, and it could be made even better than it is.

Here is one way to think about it from a UI standpoint. The user model
is that there's "the application" which can be installed, uninstalled,
moved around, and launched.

Unfortunately, for moving around and launching you're using a .desktop
file. For install/uninstall you're using the r-c-p "comps group" concept
sometimes, and "foo.rpm" files sometimes. So there are three
implementation details leaking out, where the simple user model would
have only 1 concept.

So ways to improve this might include:

- a way to bundle a set of RPMs into a single user-visible file,
so you can have an "uninstalled app" visible in the file manager

- have ways to install/uninstall a package by manipulating the thing
implemented now as a .desktop file (the menu/filemanager entry)

- try to ensure packages for "end user apps" always have names that
match the primary desktop file in the package; so e.g. the Gnumeric
.rpm package would show up in file manager as "Gnumeric Spreadsheet"
and once installed you get same in menu

Those are just some possibilities, not well-researched proposals. The
general idea is to fix the "leakiness" of the current abstraction;
ideally, a naive end user doesn't have to learn 3 implementation details
when a single concept of "an application" should be sufficient.

Havoc

[Nicolas Mailhot]

Post by Havoc Pennington
- a way to bundle a set of RPMs into a single user-visible file,
so you can have an "uninstalled app" visible in the file manager

Actually the smart thing would be to distribute apt/yum/up2date profiles
that match an usage, and let them the package manager download the parts
that are not installed yet and all second, third, fourth... -level
dependencies.

I'll be strongly suspicious of any application-level bundling. Upstream
projects just do not care enough to get all peripheral stuff right. OTOH
some way to specify weak user-level dependencies (like "my doc is in pdf
- get yourself a pdf reader") would help many people ("hard"
dependencies ie stuff that is required by the code to work being handled
the usual rpm way).

Cheers,
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20031005/fd2b0e32/attachment.bin

[Havoc Pennington]

Post by Nicolas Mailhot
Actually the smart thing would be to distribute apt/yum/up2date profiles
that match an usage, and let them the package manager download the parts
that are not installed yet and all second, third, fourth... -level
dependencies.

That's the comps file approach redhat-config-packages uses now,
essentially. Just need to have an idea of a comps file as a standalone
thing with a MIME handler perhaps.

Havoc

[Nicolas Mailhot]

Post by Havoc Pennington

Post by Nicolas Mailhot
Actually the smart thing would be to distribute apt/yum/up2date profiles
that match an usage, and let them the package manager download the parts
that are not installed yet and all second, third, fourth... -level
dependencies.

That's the comps file approach redhat-config-packages uses now,
essentially. Just need to have an idea of a comps file as a standalone
thing with a MIME handler perhaps.

Sure. I realised after posting that was exactly what anaconda already
did at installation time;)
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20031005/eb7b7b04/attachment.bin

[Nicolas Mailhot]

Post by Havoc Pennington

Post by Nicolas Mailhot
Actually the smart thing would be to distribute apt/yum/up2date profiles
that match an usage, and let them the package manager download the parts
that are not installed yet and all second, third, fourth... -level
dependencies.

That's the comps file approach redhat-config-packages uses now,
essentially. Just need to have an idea of a comps file as a standalone
thing with a MIME handler perhaps.

Sure. I realised after posting that was exactly what anaconda already
did at installation time;)
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20031005/eb7b7b04/attachment-0002.bin

[Havoc Pennington]

Post by Nicolas Mailhot
Actually the smart thing would be to distribute apt/yum/up2date profiles
that match an usage, and let them the package manager download the parts
that are not installed yet and all second, third, fourth... -level
dependencies.

That's the comps file approach redhat-config-packages uses now,
essentially. Just need to have an idea of a comps file as a standalone
thing with a MIME handler perhaps.

Havoc

[Mike Hearn]

Post by Havoc Pennington
The solution to end-user dependency problems is very simple, and it is
the same one used on Windows.

I've come late to this thread, blame freshers week at my university :)

Anyway, I respectfully disagree. We're in a fundamentally different
scenario to that of Win32 developers, namely that:

a) We're massively outnumbered
b) Linux users tend to have a lot more software installed than Windows
users do
c) Software is a lot more modular

Simply bundling everything with the app really is not acceptable,
especially for dialup users. Example: Gaim for Linux - RPM is 1.7mb (i
think), Gaim for Windows - self extracting EXE with GTK+ is 6.7mb

OK, so that makes little difference when you have half a megabit piped
into your house or room, but it makes all the difference for the
majority of the world who don't. Obviously Gaim is a program with few
dependencies.

Another simple example - statically linking the Jamboree gnome music
player would change the size of the binary from 600k to 24mb, which is
clearly insane.

Now, you can say "Linux is a platform, which consists of libraries A, B
and C - do not depend on anything else". That approach basically works,
but is kind of difficult to force through. One mans essential library is
anothers bloat, it may be that some libraries cannot commit to the ABI
guarantees needed etc. I have 151 packages installed with "lib" in their
name, it'd be pretty hard to get them all into even a tiered platform,
though it could be done.

Post by Havoc Pennington
It's also what an LSB-compliant package _must_ do. But of course, nobody
seems to make LSB-compliant packages, instead they just complain about
how packages are distribution-dependent. ;-) People, this is the whole
point of the LSB...

Well, have you tried to make an LSB compliant package? It is really
quite hard. For instance, a standard compile of any non-trivial C app on
RH9 will pull in the thread-local locale model stuff from glibc 2.3.

You can use the lsb tools to statically link everything needed, but it
really does have to be *everything*, you cannot say "well everybody has
GTK, i'll skip that" - the way the tools work mean the build will fail
if you link against libraries that were not LSB compiled themselves.
That's not really intentional, it's just because ld wants to completely
close the symbol set. We figured out a way around that with apbuild, but
the LSB weren't interested of course - they *want* people to be forced
to only use their base set (they need to be able to guarantee what an
LSB app is and isn't).

Not to mention that the LSB headers are not the same as the glibc ones,
for instance I once tried to compile DBUS (i think v0.1 or something
quite old now) as an LSB app to see what it was like, but the build
failed due to obscure bugs in the LSB headers. Something to do with
sunrpc iirc, which was wierd but there you go. I should try again
sometime, as I reported the bug.

Then you have to be able to make an RPMv3 package that meets their
stringent restrictions etc...

So back to my original example, an LSB package of Jamboree would have
taken most of the day to download on a 56kbit connection, as opposed to
approx 5 mins for a non-LSB package that simply depended on the right
libraries.

Post by Havoc Pennington
Unfortunately, for moving around and launching you're using a .desktop
file. For install/uninstall you're using the r-c-p "comps group" concept
sometimes, and "foo.rpm" files sometimes.

Yes, this is not ideal. The way I was planning to tackle this (when
someday autopackage doesn't suck) was to embed package information into
the .desktop file, then teach Nautilus/Konqueror about that. They could
read the .desktop file, see that the relevant program was not installed
and perhaps gray it out to show that it'd take some time to launch
(because it'd need to be downloaded). The launcher, when clicked, takes
care of download, verification, installation, dep resolution and so on.

You could also use the launcher to uninstall, though the idea of garbage
collecting packages appeals to me in some vague way.

In this scenario you have only one concept as a user, that of "the
application" (or launcher) - you can click it, email it to friends, drop
it on a disk etc, and the details of what CPU arch and deps you have etc
are sorted out by the system.

It's kind of like the MacOS X AppFolders system UI wise, except without
the massive bloat and suckyness that accompanies a pure NeXT style
system.

Post by Havoc Pennington
- a way to bundle a set of RPMs into a single user-visible file,
so you can have an "uninstalled app" visible in the file manager

Too large for dialup users I think :(

Post by Havoc Pennington
- have ways to install/uninstall a package by manipulating the thing
implemented now as a .desktop file (the menu/filemanager entry)

Seems the easiest way forward, though it'd be easier still if there were
standards for packaging.

Post by Havoc Pennington
- try to ensure packages for "end user apps" always have names that
match the primary desktop file in the package; so e.g. the Gnumeric
.rpm package would show up in file manager as "Gnumeric Spreadsheet"
and once installed you get same in menu

Kind of icky. What happens if you click an installed RPM? It'd look like
it should run the app, but then how do you remove it? It also relies on
something that could be broken quite easily (the name mapping).

Post by Havoc Pennington
Those are just some possibilities, not well-researched proposals. The
general idea is to fix the "leakiness" of the current abstraction;
ideally, a naive end user doesn't have to learn 3 implementation details
when a single concept of "an application" should be sufficient.

Right. I quite like the idea of a non-technical user browsing to
frozen-bubble.org, and seeing the icon embedded in the web page. They
drag it to the panel, or perhaps even just click it in the webpage
directly. The button starts glowing or something to indicate that the
computer is working, and the process of installation gets going in the
background. When it's done, the icon goes coloured, maybe with some
pretty sparkly effect to indicate "newness", and the program launches.

The app is now available from the menu, the web page, can be dragged to
the panel/desktop/whatever. User decides frozen bubble is really cute,
and opens up their chat program and drops the icon (the application, in
effect) into the chat window, where it appears the other end grayed out
and the process begins again. If that other user is on PowerPC and lives
the opposite end of the planet, no problems, the right download is
selected from the right mirror.

A lot of work, obviously, but all doable. First of all you need an easy
way to build distro-neutral packages. From my experiences, I'd say the
LSB is not it....

thanks -mike

[Sean Middleditch]

Post by Mike Hearn
Another simple example - statically linking the Jamboree gnome music
player would change the size of the binary from 600k to 24mb, which is
clearly insane.

Statically linking isn't the answer proposed at all. Anyone trying to
do that will make the situation *much* worse.

I'm ASSuming Havoc meant bundling with as how many Windows apps do it -
they come (metaphorically speaking) as a bundle of RPMs, and the
dependencies are then installed as needed.

With our world of up2date/yum/apt we don't need to bundle the
dependencies. We just need to not keep breaking them so they stop
working unless you recompile half the machine. i.e., if mydep 1.1 isn't
API/ABI compatable with mydep 1.0, they must be coinstallable, and the
library versions updated.

Post by Mike Hearn
Now, you can say "Linux is a platform, which consists of libraries A, B
and C - do not depend on anything else". That approach basically works,
but is kind of difficult to force through. One mans essential library is

LSB is just this, and many distros are LSB compliant these days.

Post by Mike Hearn
anothers bloat, it may be that some libraries cannot commit to the ABI
guarantees needed etc. I have 151 packages installed with "lib" in their
name, it'd be pretty hard to get them all into even a tiered platform,
though it could be done.

Those that can't keep a stable ABI simply need to reflect this in some
meaningful way to both developers and users - soversions and
co-installable data, big warning labels, etc.

Post by Mike Hearn

Post by Havoc Pennington
It's also what an LSB-compliant package _must_ do. But of course, nobody
seems to make LSB-compliant packages, instead they just complain about
how packages are distribution-dependent. ;-) People, this is the whole
point of the LSB...

Well, have you tried to make an LSB compliant package? It is really
quite hard. For instance, a standard compile of any non-trivial C app on
RH9 will pull in the thread-local locale model stuff from glibc 2.3.

This sounds like it needs to be fixed; i.e., an easy way to disable
that. I know apps linked against older libcs work on RH9 (usually, the
occasional odd app fails, which is quite unfortunate).

Post by Mike Hearn
You can use the lsb tools to statically link everything needed, but it
really does have to be *everything*, you cannot say "well everybody has
GTK, i'll skip that" - the way the tools work mean the build will fail
if you link against libraries that were not LSB compiled themselves.
That's not really intentional, it's just because ld wants to completely
close the symbol set. We figured out a way around that with apbuild, but
the LSB weren't interested of course - they *want* people to be forced
to only use their base set (they need to be able to guarantee what an
LSB app is and isn't).

Which is good. The LSB just needs to define more packages. But that's
just LSB. LSB is, again, most useful for commercial software. When
talking open-source apps, we have a lot more leeway. Namely, the
upstream devs can provide the "standard". Example, so long as the GTK
devs don't break their excellent track record of sane API/ABI
versioning, and so long as people package it properly (which, so far, is
the case on RH/Fedora), software can rely on GTK.

The same goes for any other dependency in which the upstream authors
apply proper release techniques.

Post by Mike Hearn
Not to mention that the LSB headers are not the same as the glibc ones,
for instance I once tried to compile DBUS (i think v0.1 or something
quite old now) as an LSB app to see what it was like, but the build
failed due to obscure bugs in the LSB headers. Something to do with
sunrpc iirc, which was wierd but there you go. I should try again
sometime, as I reported the bug.

LSB, I should note, also isn't for low-level system stuff. It's really
for monolithic apps. I don't even see the point in installing something
like, say, apache, as an LSB package - its not really the target
audience.

Post by Mike Hearn
Then you have to be able to make an RPMv3 package that meets their
stringent restrictions etc...
So back to my original example, an LSB package of Jamboree would have
taken most of the day to download on a 56kbit connection, as opposed to
approx 5 mins for a non-LSB package that simply depended on the right
libraries.

Post by Havoc Pennington
Unfortunately, for moving around and launching you're using a .desktop
file. For install/uninstall you're using the r-c-p "comps group" concept
sometimes, and "foo.rpm" files sometimes.

Yes, this is not ideal. The way I was planning to tackle this (when
someday autopackage doesn't suck) was to embed package information into
the .desktop file, then teach Nautilus/Konqueror about that. They could
read the .desktop file, see that the relevant program was not installed
and perhaps gray it out to show that it'd take some time to launch
(because it'd need to be downloaded). The launcher, when clicked, takes
care of download, verification, installation, dep resolution and so on.

That would be interesting. The problem is, then, every single app that
possibly exists in the application/dependency archive would be in the
menues. Ick.

While I understand the use cases, as I've said on the autopackage lists,
and real Application Manager is needed (which I've some new ideas for,
i'll post those to the ap list).

Post by Mike Hearn
You could also use the launcher to uninstall, though the idea of garbage
collecting packages appeals to me in some vague way.

Which isn't really possible. The best you could do is inform the user
that the system doesn't *appear* to be using the app anymore (no users
have a launcher for it, if you can even determine that easily) and let
them optionally uninstall it.

The same is true to libraries/dependencies - sure, normal users might
not need them if no other packages are using them, but hackers/admins
probably have a lot of stuff installed from source. So automatic
dependency "garbage" collection isn't really feasible, at least not
without lots and lots of user interaction and such.

Post by Mike Hearn
In this scenario you have only one concept as a user, that of "the
application" (or launcher) - you can click it, email it to friends, drop
it on a disk etc, and the details of what CPU arch and deps you have etc
are sorted out by the system.
It's kind of like the MacOS X AppFolders system UI wise, except without
the massive bloat and suckyness that accompanies a pure NeXT style
system.

Post by Havoc Pennington
- a way to bundle a set of RPMs into a single user-visible file,
so you can have an "uninstalled app" visible in the file manager

Too large for dialup users I think :(

It could be useful for on-disk management, corporate deployment, CDs,
etc. But probably not useful enough if the tools just become more
intelligent; i.e., if I click on a package in Nautilus and
redhat-install-packages sees I'm missing a dependency, it should try
looking in the folder the main package is in to find them. That would
make a lot of "off the 'net" RPM installations easier, for one. If the
package could point to URLs that have a list of packages for dependency
resolution, it would get even cooler (tho then GPG security and such
would probably be more important - I can just see the "Trust content
from Macromedia" dialogs and such one's accustomed to in Windows... but
then, blindly trusting an entire distro which is community based and in
which nearly anyone can eventually get access to upload packages, those
incessant dialogs are probably a better approach...)

Post by Mike Hearn

Post by Havoc Pennington
- have ways to install/uninstall a package by manipulating the thing
implemented now as a .desktop file (the menu/filemanager entry)

Seems the easiest way forward, though it'd be easier still if there were
standards for packaging.

yay standards! ;-)

Post by Mike Hearn

Post by Havoc Pennington
- try to ensure packages for "end user apps" always have names that
match the primary desktop file in the package; so e.g. the Gnumeric
.rpm package would show up in file manager as "Gnumeric Spreadsheet"
and once installed you get same in menu

Kind of icky. What happens if you click an installed RPM? It'd look like
it should run the app, but then how do you remove it? It also relies on
something that could be broken quite easily (the name mapping).

Fortunately, the file name of an RPM is completely arbitrary. In large
collections with comps file (or whatever), "specific" naming is
possible; but if I want to put an RPM of some single piece of software
on my site, I'm quite free to call it anything.

Post by Mike Hearn

Post by Havoc Pennington
Those are just some possibilities, not well-researched proposals. The
general idea is to fix the "leakiness" of the current abstraction;
ideally, a naive end user doesn't have to learn 3 implementation details
when a single concept of "an application" should be sufficient.

Right. I quite like the idea of a non-technical user browsing to
frozen-bubble.org, and seeing the icon embedded in the web page. They
drag it to the panel, or perhaps even just click it in the webpage
directly. The button starts glowing or something to indicate that the
computer is working, and the process of installation gets going in the
background. When it's done, the icon goes coloured, maybe with some
pretty sparkly effect to indicate "newness", and the program launches.

Hmm, a bit farther than I had in mind, but it would certainly work; one
can imagine the "RPM Installer" Mozilla plugin. ;-)

If we even get to the point tho where the user can click the website
icon, and the Browser pops up a "Install Application?" dialog that
downloads and installs without the glitz, we'd be a long way ahead of
where we are now (click icon, get RPM, watch it not work, realize some
goof made the libinsane1 on OS release 2 completely incompatible with
libinsane1 on OS release 1, spend time figuring out whether the lib or
the app is easier to rebuild, find out the rebuild needs tons of build
dependencies which the tools don't bother to grab for you, etc. etc.).

Post by Mike Hearn
The app is now available from the menu, the web page, can be dragged to
the panel/desktop/whatever. User decides frozen bubble is really cute,
and opens up their chat program and drops the icon (the application, in
effect) into the chat window, where it appears the other end grayed out
and the process begins again. If that other user is on PowerPC and lives
the opposite end of the planet, no problems, the right download is
selected from the right mirror.

That would certainly be nifty. Really, all that would require a small
.desktop-like file describing the package, and the mirror-net its on.
The install app just finds a mirror, looks up the real package (and
dependencies, possibly querying not only the app's mirror but also the
distro's repository), etc. Heck, I think there are a couple (not nearly
done) apps that do just this, minus the high-level of desktop
integration.

Post by Mike Hearn
A lot of work, obviously, but all doable. First of all you need an easy
way to build distro-neutral packages. From my experiences, I'd say the
LSB is not it....

Agreed. Most of the responsibility has to lay with the upstream
developers. If the authors of libfoobar are goofs and refuse to put the
3 seconds of effort forth to make their software at least co-installable
with other versions, than any upstream dev who relies on libfoobar is
just as guilty of bad practices.

A good guide on packaging might help resolve a number of such
situation. One of the biggest problems with RPMs isn't even that the
software is actually incompatible, just that the packaging *makes* it
incompatible; packages putting things in different locations, packages
that conflict with each other in order to provide different optional
featuresets (why in all the world should a user have to unisntall an app
to add features? sounds dumb, but yet we have to do it many times,
because make packages like someapp-nofeatures, someapp-feature1,
someapp-feature2, someapp-allfeatures, etc. not necessary!)

Evangelism on the importance of proper development practices could be
useful, too. Probably the only place I've seen describing library
versioning in detail is the innards of the libtool manual. No wonder
lots of devs don't do it right, eh? Something like the war on drugs is
needed: DARP, Developers Against Ramshackle Packages. ;-)

Post by Mike Hearn
thanks -mike
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

[Mike Hearn]

Post by Sean Middleditch
LSB is just this, and many distros are LSB compliant these days.

Yeah, but LSB is really really LCD. No GUI libs (yet) for instance.

Post by Sean Middleditch
This sounds like it needs to be fixed; i.e., an easy way to disable
that. I know apps linked against older libcs work on RH9 (usually, the
occasional odd app fails, which is quite unfortunate).

That's what apbuild/apgcc do - ideally of course upgrading glibc would
be just like any other library but for some reason it isn't, so we have
to wind back the clock a little bit. Fortunately thread-local locales is
a features mostly useful for servers I think, so client side apps don't
need to worry about losing it.

Post by Sean Middleditch
That would be interesting. The problem is, then, every single app that
possibly exists in the application/dependency archive would be in the
menues. Ick.

No, only stuff the user had installed.

Post by Sean Middleditch
While I understand the use cases, as I've said on the autopackage lists,
and real Application Manager is needed (which I've some new ideas for,
i'll post those to the ap list).

Please do so. I'm not sold that we need any specific app management
program - it's the sort of thing users just never think about (much like
uninstalling stuff they no longer use).

Post by Sean Middleditch
Which isn't really possible. The best you could do is inform the user
that the system doesn't *appear* to be using the app anymore (no users
have a launcher for it, if you can even determine that easily) and let
them optionally uninstall it.
The same is true to libraries/dependencies - sure, normal users might
not need them if no other packages are using them, but hackers/admins
probably have a lot of stuff installed from source. So automatic
dependency "garbage" collection isn't really feasible, at least not
without lots and lots of user interaction and such.

Maybe.... still, it's been done in Java/C# for ages, despite the
difficulties. It seems unintuitive that it's possible with objects but
not packages.

Post by Sean Middleditch
Evangelism on the importance of proper development practices could be
useful, too. Probably the only place I've seen describing library
versioning in detail is the innards of the libtool manual. No wonder
lots of devs don't do it right, eh? Something like the war on drugs is
needed: DARP, Developers Against Ramshackle Packages. ;-)

Yeah, I want to do this too at some point, probably as part of the
packagers/developers guide we're writing for AP. There is a good paper
by Ulrich Drepper on writing DSOs, but it's basically impossible to find
unless somebody shows you. Other bad techniques are compile time
options, non-relocatability and so on. Developer education is definately
a part of the solution.

thanks -mike

[Nicolas Mailhot]

Post by Mike Hearn

Post by Sean Middleditch
That would be interesting. The problem is, then, every single app that
possibly exists in the application/dependency archive would be in the
menues. Ick.

No, only stuff the user had installed.

Please keep unstalling/uninstalling out of menus.

Windows only does it because for a long time they installation manager
panel missed most apps (and still misses some of them). So people had to
put uninstall links somewhere else. Really it's amazing how people
forget history and comme to accept ugly workarounds as the natural way
to do things.

We don't need no windowish in-your-face uninstall solutions, we don't
need popup eulas, change-install-location dialogs,
here-is-the-disc-size-I-need-please-check windows,
you-think-I'm-installed-but-check-my-20-pages-readme popups,
don't-bother-with-permissions-and-run-everything-as-admin

(I case people wonder - I've just documented the installation of an app
that used a custom installer clearly written by a brainwashed
monopolysoft user. Just documenting this single installation took as
many pages as the ones devoted to updating the whole multi-hundred rpm
system)

Anyway I don't know why I bother - just do your thing and I'll watch HiG
people shot it down.

Post by Mike Hearn

Post by Sean Middleditch
While I understand the use cases, as I've said on the autopackage lists,
and real Application Manager is needed (which I've some new ideas for,
i'll post those to the ap list).

Please do so. I'm not sold that we need any specific app management
program - it's the sort of thing users just never think about (much like
uninstalling stuff they no longer use).

Sure - why use a single consistent working solution when you can let
everyone reinvent incompatible wheels ?

Post by Mike Hearn

Post by Sean Middleditch
Which isn't really possible. The best you could do is inform the user
that the system doesn't *appear* to be using the app anymore (no users
have a launcher for it, if you can even determine that easily) and let
them optionally uninstall it.
The same is true to libraries/dependencies - sure, normal users might
not need them if no other packages are using them, but hackers/admins
probably have a lot of stuff installed from source. So automatic
dependency "garbage" collection isn't really feasible, at least not
without lots and lots of user interaction and such.

Maybe.... still, it's been done in Java/C# for ages, despite the
difficulties. It seems unintuitive that it's possible with objects but
not packages.

Well I can tell you we have *nothing* to learn from java packaging,
quite the contrary. In fact the java world right now is a motherload of
bad packaging examples.

Post by Mike Hearn

Post by Sean Middleditch
Evangelism on the importance of proper development practices could be
useful, too. Probably the only place I've seen describing library
versioning in detail is the innards of the libtool manual. No wonder
lots of devs don't do it right, eh? Something like the war on drugs is
needed: DARP, Developers Against Ramshackle Packages. ;-)

Yeah, I want to do this too at some point, probably as part of the
packagers/developers guide we're writing for AP. There is a good paper
by Ulrich Drepper on writing DSOs, but it's basically impossible to find
unless somebody shows you. Other bad techniques are compile time
options, non-relocatability and so on. Developer education is definately
a part of the solution.

Developer education will *always* be a problem. Developing and packaging
are just two different CS specialities (just like developing and QA).
Some people will do both, most won't, expecting every single developer
to be able to package things is just a recipe for bad packaging.

Cheers,
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20031012/63cc9dc5/attachment.bin

[Julien Olivier]

(snip)

Post by Nicolas Mailhot
Well I can tell you we have *nothing* to learn from java packaging,
quite the contrary. In fact the java world right now is a motherload of
bad packaging examples.

I think Mike was talking of Java's memory management (automatic removal
of unused objects), not package management.

I could be wrong though...

[Nicolas Mailhot]

Post by Julien Olivier
(snip)

Post by Nicolas Mailhot
Well I can tell you we have *nothing* to learn from java packaging,
quite the contrary. In fact the java world right now is a motherload of
bad packaging examples.

I think Mike was talking of Java's memory management (automatic removal
of unused objects), not package management.
I could be wrong though...

I understood it this way too;)
I just didn't want anyone to translate it into "java packaging is good"
(which just proves you can have terrific developers and piss-poor
packagers)

Cheers,
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20031012/03bdfe17/attachment.bin

[Nicolas Mailhot]

Post by Julien Olivier
(snip)

Post by Nicolas Mailhot
Well I can tell you we have *nothing* to learn from java packaging,
quite the contrary. In fact the java world right now is a motherload of
bad packaging examples.

I think Mike was talking of Java's memory management (automatic removal
of unused objects), not package management.
I could be wrong though...

I understood it this way too;)
I just didn't want anyone to translate it into "java packaging is good"
(which just proves you can have terrific developers and piss-poor
packagers)

Cheers,
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20031012/03bdfe17/attachment-0002.bin

[Mike Hearn]

Post by Nicolas Mailhot
Please keep unstalling/uninstalling out of menus.

We intend to. Currently we use the .desktop specs Actions part to do
uninstall/upgrade etc, unfortunately no desktop supports it yet. At some
point I'll sit down and hack out support for Gnome if nobody else does,
I expect somebody is up for doing it in KDE. Right clicking on a menu
item has piss poor discoverability of course. I'm warming to Seths
application manager program a bit.

Post by Nicolas Mailhot
We don't need no windowish in-your-face uninstall solutions, we don't
need popup eulas

This is getting rather offtopic, but the "makeinstaller" utility prints
warnings if you use the EULA functionality (not fully implemented yet)..

Post by Nicolas Mailhot
, change-install-location dialogs,

Don't have one, if you want to change the prefix you have to use the
command line...

Post by Nicolas Mailhot
here-is-the-disc-size-I-need-please-check windows,

... automatic

Post by Nicolas Mailhot
you-think-I'm-installed-but-check-my-20-pages-readme popups,

... not done

Post by Nicolas Mailhot
don't-bother-with-permissions-and-run-everything-as-admin

... can choose (user vs root)

Post by Nicolas Mailhot
(I case people wonder - I've just documented the installation of an app
that used a custom installer clearly written by a brainwashed
monopolysoft user. Just documenting this single installation took as
many pages as the ones devoted to updating the whole multi-hundred rpm
system)

We're aiming for a 100% automatic install. User interaction is possible
but treated very carefully.

Post by Nicolas Mailhot
Anyway I don't know why I bother - just do your thing and I'll watch HiG
people shot it down.

You do that. Just remember that most of us have read the HIG and taken
it to heart.

Post by Nicolas Mailhot
Sure - why use a single consistent working solution when you can let
everyone reinvent incompatible wheels ?

There would be a consistant working solution, but so far I've not been
able to come up with one that I feel integrates nicely. We'll prolly end
up doing an "app manager" (which BTW should really be standards based),
but even so this is kind of hackish IMHO - for the user the model is
that the launcher IS the application, so integrating app management with
the launcher feels like the right way to do things.

thanks -mike

[Sean Middleditch]

Post by Nicolas Mailhot

Post by Mike Hearn

Post by Sean Middleditch
That would be interesting. The problem is, then, every single app that
possibly exists in the application/dependency archive would be in the
menues. Ick.

No, only stuff the user had installed.

Please keep unstalling/uninstalling out of menus.
Windows only does it because for a long time they installation manager
panel missed most apps (and still misses some of them). So people had to
put uninstall links somewhere else. Really it's amazing how people
forget history and comme to accept ugly workarounds as the natural way
to do things.

I think perhaps you aren't following Mike's intent - the Windows way,
adding big menu options for "Uninstall", is not what he meant. More,
when you context-click on an app in the menu, several options pop up
(copy launcher, remove from menu, etc.) - one of those would (could) be
"Uninstall application". Completely out of the way unless you're
looking for it.

Post by Nicolas Mailhot
We don't need no windowish in-your-face uninstall solutions, we don't
need popup eulas, change-install-location dialogs,
here-is-the-disc-size-I-need-please-check windows,
you-think-I'm-installed-but-check-my-20-pages-readme popups,
don't-bother-with-permissions-and-run-everything-as-admin

In many cases, we *do* need some of those. We *do* need EULA support,
for example, since applications I install often have them. Whether or
not you think they're evil, others need an installer that supports them
(versus the RPM way, which requires packagers to wrap the RPM in a shell
script which I then have to run in a command line to open, agree to the
EULA, and then install) as they use applications that have them, and
need to continue doing so.

Post by Nicolas Mailhot
(I case people wonder - I've just documented the installation of an app
that used a custom installer clearly written by a brainwashed
monopolysoft user. Just documenting this single installation took as
many pages as the ones devoted to updating the whole multi-hundred rpm
system)

Ya... let's keep this to technical facts, not "brainwashed Free Software
user" paranoia. Thanks. ;-)

Installation problems on Linux I've run into are almost always because
of RPM. If RPMs usually supported more than on particular snapshot of a
particular distro, if RPMs actually worked on all distros, and if RPM
had abilities to ask users install questions, select software
components, agree to legally-required EULAs (there's doubt that even the
GPL is really valid if the user is never forced to agree to it, or even
*see* it, to use the software), etc. then software developers probably
wouldn't need to rely on hacked-up installers.

As is, even most of the companies that ship RPMs generally need to wrap
them in shell scripts or other hacks in order to "add" the features RPM
denies them. Look at the Macromedia Flash, Adobe Acrobat Reader, or Sun
Java installs (I think those are the ones that use wrapped RPMs), for
example.

Post by Nicolas Mailhot
Anyway I don't know why I bother - just do your thing and I'll watch HiG
people shot it down.

Post by Mike Hearn

Post by Sean Middleditch
While I understand the use cases, as I've said on the autopackage lists,
and real Application Manager is needed (which I've some new ideas for,
i'll post those to the ap list).

Please do so. I'm not sold that we need any specific app management
program - it's the sort of thing users just never think about (much like
uninstalling stuff they no longer use).

Sure - why use a single consistent working solution when you can let
everyone reinvent incompatible wheels ?

That isn't the intent. The idea is to put the "single working solution"
somewhere other than a monolithic GUI manager. Altho, personally, I
still think the GUI manager is a necessity.

Post by Nicolas Mailhot

Post by Mike Hearn

Post by Sean Middleditch
Which isn't really possible. The best you could do is inform the user
that the system doesn't *appear* to be using the app anymore (no users
have a launcher for it, if you can even determine that easily) and let
them optionally uninstall it.
The same is true to libraries/dependencies - sure, normal users might
not need them if no other packages are using them, but hackers/admins
probably have a lot of stuff installed from source. So automatic
dependency "garbage" collection isn't really feasible, at least not
without lots and lots of user interaction and such.

Maybe.... still, it's been done in Java/C# for ages, despite the
difficulties. It seems unintuitive that it's possible with objects but
not packages.

There are *huge* differences, unfortunately, between an application
running and applications spread all over the file system. Garbage
collection in Java/C# doesn't happen across two apps connected over the
network, yet application garbage collection would need that for mounted
shares/volumes. Memory garbage collectors also have access to all
objects in existence, and (in good implementations) know when object
relationships are formed or broken - an application garbage collector
would need to somehow find out whenever any reference to an app has
changed. Memory collectors also don't support fancy memory tricks like
"hidden" pointers and such, but an application garbage collector would
need to know about "fancy tricks" like users using an app from the
command line or a script and not .desktop files.

Memory GC and application GC are really just two completely different
things.

Post by Nicolas Mailhot
Well I can tell you we have *nothing* to learn from java packaging,
quite the contrary. In fact the java world right now is a motherload of
bad packaging examples.

Post by Mike Hearn

Post by Sean Middleditch
Evangelism on the importance of proper development practices could be
useful, too. Probably the only place I've seen describing library
versioning in detail is the innards of the libtool manual. No wonder
lots of devs don't do it right, eh? Something like the war on drugs is
needed: DARP, Developers Against Ramshackle Packages. ;-)

Yeah, I want to do this too at some point, probably as part of the
packagers/developers guide we're writing for AP. There is a good paper
by Ulrich Drepper on writing DSOs, but it's basically impossible to find
unless somebody shows you. Other bad techniques are compile time
options, non-relocatability and so on. Developer education is definately
a part of the solution.

Developer education will *always* be a problem. Developing and packaging
are just two different CS specialities (just like developing and QA).
Some people will do both, most won't, expecting every single developer
to be able to package things is just a recipe for bad packaging.

Developers don't necessarily need to package. They *do* need to not be
so boneheaded as to make packaging impossible. i.e., when the packager
comes along and finds out that the only way to get "lite version" and
"full version" of the application packaged is to make them conflict with
each other, thus requiring a user to uninstall and reinstall the app to
"enable" features, the packager should bring the issue up with the
developer, who then should go, "oh, oops, will fix this!" and resolve
the problem on his end, allowing the packager to make sane, working
packagers that people besides l337 h4ck3r5 and sysadmins can install and
use.

As is now, the developer tends not to give a flying hoot (or just not
know any better), the packager can't resolve the issue with the
developer (or they themselves don't really understand the problem), and
we end up with tons of packages that don't really work unless installed
in one specific OS setup, when the moon is full, the stars are aligned
properly, the wind is blowing from the south-southeast at 45 knots, and
you've your ritual RPM body paint on with shell script incants written
all over your forehead.

Evangelism and education can help this. Simply not packaging brain-dead
broken software helps too; or, at least, understand that packages of
software like that should be the *exception*, not the rule. We'll
probably always have a couple pieces of popular software written by
dinks that think Linux should only be for the technologically elite and
kept away from "dr00ling lusers," but hopefully we can keep that to a
minimum.

Post by Nicolas Mailhot
Cheers,

[Nicolas Mailhot]

Post by Sean Middleditch

Post by Nicolas Mailhot
(I case people wonder - I've just documented the installation of an app
that used a custom installer clearly written by a brainwashed
monopolysoft user. Just documenting this single installation took as
many pages as the ones devoted to updating the whole multi-hundred rpm
system)

Ya... let's keep this to technical facts, not "brainwashed Free Software
user" paranoia. Thanks. ;-)

Sure.
Call all the useless screens I've had to document parano?a if you wish.
I do know the exact cost user-wise of the two approaches, because I had
to document it, and then validate the doc with test users.
I do not assume anything. I spent lots of time validating this. Did you?

Post by Sean Middleditch
Installation problems on Linux I've run into are almost always because
of RPM. If RPMs usually supported more than on particular snapshot of a
particular distro, if RPMs actually worked on all distros, and if RPM
had abilities to ask users install questions, select software
components, agree to legally-required EULAs (there's doubt that even the
GPL is really valid if the user is never forced to agree to it, or even
*see* it, to use the software), etc

No.
There is absolutely no doubt in any lawyer mind that click-thoughts are
totally irrelevant legally (or at least in most of the sane world).

The function they serve is purely to frighten users into doing slavishly
whatever the vendor wants them to do (see the Dell EULA-in-BIOS story -
the EULA was so extreme there was no way anyone could reasonably abide
by it). Plus of course they target specifically the US legal system,
even for software that distributed half a world away.

Post by Sean Middleditch
. then software developers probably
wouldn't need to rely on hacked-up installers.

Yep. And most of the people here would be using something else. You put
the garbage into the installer - sane people will jump out of your ship.

Post by Sean Middleditch
As is, even most of the companies that ship RPMs generally need to wrap
them in shell scripts or other hacks in order to "add" the features RPM
denies them. Look at the Macromedia Flash, Adobe Acrobat Reader, or Sun
Java installs (I think those are the ones that use wrapped RPMs), for
example.

So what ?
A commercial house will put whatever it can get by in the installer.
The big difference between Windows and Linux is so far it can get by
with a lot less dirty tricks.

(and don't bring the thing Sun calls a java rpm in the discussion - I
can assure you I spent enough time refactoring it into sanity I know it
by heart)

The nice RH people have proved over time you can package anything in
rpms - from web server to office suites, from home-developed apps to big
commercial bloatware (oo)

All the things you're clamouring for *have not a single technical
justification*. Period. You don't want them because the user needs or
wants them, or because they will improve the system. You want them so
people can use Linux just like another windows, with just the same
habits that ruin everyday windows user life, and so commercial houses
can issue the same junk as they are used to.

And you can write all you want about it not being as bad as I describe
it. A lot of other people here have enough daily exposition to that
other OS to know what it can do and how.
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20031013/3ffd694d/attachment.bin

[Sean Middleditch]

On Mon, 2003-10-13 at 12:01, Nicolas Mailhot wrote:

<snip tons of yammering>

Post by Nicolas Mailhot
The nice RH people have proved over time you can package anything in
rpms - from web server to office suites, from home-developed apps to big
commercial bloatware (oo)
All the things you're clamouring for *have not a single technical
justification*. Period. You don't want them because the user needs or

Software components: Take a look at OOo, Mozilla, GNOME, etc. - a user
installing these has to manually pick apart and selected packages. A
user-friendly approach would, upon opening the installer, give them
options to select among options - i.e., do I want just the browser, or
the mailer as well, or the browser, mailer, calendar but not the chat
program, etc.

When we get into managing packages, the user will see a list of things
like:
mozilla-browser
mozilla-mailnews
mozilla-chat
mozilla
mozilla-nspr
mozilla-nss
etc.

That's just insane. Those are all "Mozilla", just different
sub-components. When you toss in things like virtual packages that
exist solely to depend on everything (common in Debian, less common in
RPMs), the user model *really* starts to suffer.

What happens when an application spans multiple CDs? I have tons of
software like that - games, music composition applications, etc. - how
does RPM handle that? Oh, right, it *doesn't*. Unless the author
breaks the app into multiple RPMs, which is (a) insane, and (b) pollutes
the package space.

Post by Nicolas Mailhot
wants them, or because they will improve the system. You want them so
people can use Linux just like another windows, with just the same
habits that ruin everyday windows user life, and so commercial houses
can issue the same junk as they are used to.

Seriously, this is nothing but paranoid rambling. I'm not going to
waste time trying to debate with a raving zealot - discussion over.

[Sean Middleditch]

On Mon, 2003-10-13 at 12:01, Nicolas Mailhot wrote:

<snip tons of yammering>

Post by Nicolas Mailhot
The nice RH people have proved over time you can package anything in
rpms - from web server to office suites, from home-developed apps to big
commercial bloatware (oo)
All the things you're clamouring for *have not a single technical
justification*. Period. You don't want them because the user needs or

Software components: Take a look at OOo, Mozilla, GNOME, etc. - a user
installing these has to manually pick apart and selected packages. A
user-friendly approach would, upon opening the installer, give them
options to select among options - i.e., do I want just the browser, or
the mailer as well, or the browser, mailer, calendar but not the chat
program, etc.

When we get into managing packages, the user will see a list of things
like:
mozilla-browser
mozilla-mailnews
mozilla-chat
mozilla
mozilla-nspr
mozilla-nss
etc.

That's just insane. Those are all "Mozilla", just different
sub-components. When you toss in things like virtual packages that
exist solely to depend on everything (common in Debian, less common in
RPMs), the user model *really* starts to suffer.

What happens when an application spans multiple CDs? I have tons of
software like that - games, music composition applications, etc. - how
does RPM handle that? Oh, right, it *doesn't*. Unless the author
breaks the app into multiple RPMs, which is (a) insane, and (b) pollutes
the package space.

Post by Nicolas Mailhot
wants them, or because they will improve the system. You want them so
people can use Linux just like another windows, with just the same
habits that ruin everyday windows user life, and so commercial houses
can issue the same junk as they are used to.

Seriously, this is nothing but paranoid rambling. I'm not going to
waste time trying to debate with a raving zealot - discussion over.

[Roozbeh Pournader]

Post by Sean Middleditch
(there's doubt that even the
GPL is really valid if the user is never forced to agree to it, or even
*see* it, to use the software)

I'm sorry, you are very mistaken. GPL is completely irrelevant to the
*user*, it's only relevant if you want to *copy* the software.

And if you want to copy the software, you are automatically bound by the
copyright "law" (whether or not you've seen an EULA), which doesn't give
you the right to copy the software for some certain purposes. If
somebody copies the software without seeing the license, he may have
already been breaking the law.

In short, if you don't see the license, you may *use* the software for
any purpose (which is allowed by GPL), but you may not *copy* it. If you
see it, you may do whatever it allows you to do.

I agree that certain proprietary pieces of software need EULAs, but
we're not talking about GPL, or most of Free Software licenses for that
matter.

Roozbeh

[Nicolas Mailhot]

Post by Sean Middleditch

Post by Nicolas Mailhot
(I case people wonder - I've just documented the installation of an app
that used a custom installer clearly written by a brainwashed
monopolysoft user. Just documenting this single installation took as
many pages as the ones devoted to updating the whole multi-hundred rpm
system)

Ya... let's keep this to technical facts, not "brainwashed Free Software
user" paranoia. Thanks. ;-)

Sure.
Call all the useless screens I've had to document parano?a if you wish.
I do know the exact cost user-wise of the two approaches, because I had
to document it, and then validate the doc with test users.
I do not assume anything. I spent lots of time validating this. Did you?

Post by Sean Middleditch
Installation problems on Linux I've run into are almost always because
of RPM. If RPMs usually supported more than on particular snapshot of a
particular distro, if RPMs actually worked on all distros, and if RPM
had abilities to ask users install questions, select software
components, agree to legally-required EULAs (there's doubt that even the
GPL is really valid if the user is never forced to agree to it, or even
*see* it, to use the software), etc

No.
There is absolutely no doubt in any lawyer mind that click-thoughts are
totally irrelevant legally (or at least in most of the sane world).

The function they serve is purely to frighten users into doing slavishly
whatever the vendor wants them to do (see the Dell EULA-in-BIOS story -
the EULA was so extreme there was no way anyone could reasonably abide
by it). Plus of course they target specifically the US legal system,
even for software that distributed half a world away.

Post by Sean Middleditch
. then software developers probably
wouldn't need to rely on hacked-up installers.

Yep. And most of the people here would be using something else. You put
the garbage into the installer - sane people will jump out of your ship.

Post by Sean Middleditch
As is, even most of the companies that ship RPMs generally need to wrap
them in shell scripts or other hacks in order to "add" the features RPM
denies them. Look at the Macromedia Flash, Adobe Acrobat Reader, or Sun
Java installs (I think those are the ones that use wrapped RPMs), for
example.

So what ?
A commercial house will put whatever it can get by in the installer.
The big difference between Windows and Linux is so far it can get by
with a lot less dirty tricks.

(and don't bring the thing Sun calls a java rpm in the discussion - I
can assure you I spent enough time refactoring it into sanity I know it
by heart)

The nice RH people have proved over time you can package anything in
rpms - from web server to office suites, from home-developed apps to big
commercial bloatware (oo)

All the things you're clamouring for *have not a single technical
justification*. Period. You don't want them because the user needs or
wants them, or because they will improve the system. You want them so
people can use Linux just like another windows, with just the same
habits that ruin everyday windows user life, and so commercial houses
can issue the same junk as they are used to.

And you can write all you want about it not being as bad as I describe
it. A lot of other people here have enough daily exposition to that
other OS to know what it can do and how.
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20031013/3ffd694d/attachment-0002.bin

[Roozbeh Pournader]

Post by Sean Middleditch
(there's doubt that even the
GPL is really valid if the user is never forced to agree to it, or even
*see* it, to use the software)

I'm sorry, you are very mistaken. GPL is completely irrelevant to the
*user*, it's only relevant if you want to *copy* the software.

And if you want to copy the software, you are automatically bound by the
copyright "law" (whether or not you've seen an EULA), which doesn't give
you the right to copy the software for some certain purposes. If
somebody copies the software without seeing the license, he may have
already been breaking the law.

In short, if you don't see the license, you may *use* the software for
any purpose (which is allowed by GPL), but you may not *copy* it. If you
see it, you may do whatever it allows you to do.

I agree that certain proprietary pieces of software need EULAs, but
we're not talking about GPL, or most of Free Software licenses for that
matter.

Roozbeh

[Julien Olivier]

(snip)

Post by Nicolas Mailhot
Well I can tell you we have *nothing* to learn from java packaging,
quite the contrary. In fact the java world right now is a motherload of
bad packaging examples.

I think Mike was talking of Java's memory management (automatic removal
of unused objects), not package management.

I could be wrong though...

[Mike Hearn]

Post by Nicolas Mailhot
Please keep unstalling/uninstalling out of menus.

We intend to. Currently we use the .desktop specs Actions part to do
uninstall/upgrade etc, unfortunately no desktop supports it yet. At some
point I'll sit down and hack out support for Gnome if nobody else does,
I expect somebody is up for doing it in KDE. Right clicking on a menu
item has piss poor discoverability of course. I'm warming to Seths
application manager program a bit.

Post by Nicolas Mailhot
We don't need no windowish in-your-face uninstall solutions, we don't
need popup eulas

This is getting rather offtopic, but the "makeinstaller" utility prints
warnings if you use the EULA functionality (not fully implemented yet)..

Post by Nicolas Mailhot
, change-install-location dialogs,

Don't have one, if you want to change the prefix you have to use the
command line...

Post by Nicolas Mailhot
here-is-the-disc-size-I-need-please-check windows,

... automatic

Post by Nicolas Mailhot
you-think-I'm-installed-but-check-my-20-pages-readme popups,

... not done

Post by Nicolas Mailhot
don't-bother-with-permissions-and-run-everything-as-admin

... can choose (user vs root)

Post by Nicolas Mailhot
(I case people wonder - I've just documented the installation of an app
that used a custom installer clearly written by a brainwashed
monopolysoft user. Just documenting this single installation took as
many pages as the ones devoted to updating the whole multi-hundred rpm
system)

We're aiming for a 100% automatic install. User interaction is possible
but treated very carefully.

Post by Nicolas Mailhot
Anyway I don't know why I bother - just do your thing and I'll watch HiG
people shot it down.

You do that. Just remember that most of us have read the HIG and taken
it to heart.

Post by Nicolas Mailhot
Sure - why use a single consistent working solution when you can let
everyone reinvent incompatible wheels ?

There would be a consistant working solution, but so far I've not been
able to come up with one that I feel integrates nicely. We'll prolly end
up doing an "app manager" (which BTW should really be standards based),
but even so this is kind of hackish IMHO - for the user the model is
that the launcher IS the application, so integrating app management with
the launcher feels like the right way to do things.

thanks -mike

[Sean Middleditch]

Post by Nicolas Mailhot

Post by Mike Hearn

Post by Sean Middleditch
That would be interesting. The problem is, then, every single app that
possibly exists in the application/dependency archive would be in the
menues. Ick.

No, only stuff the user had installed.

Please keep unstalling/uninstalling out of menus.
Windows only does it because for a long time they installation manager
panel missed most apps (and still misses some of them). So people had to
put uninstall links somewhere else. Really it's amazing how people
forget history and comme to accept ugly workarounds as the natural way
to do things.

I think perhaps you aren't following Mike's intent - the Windows way,
adding big menu options for "Uninstall", is not what he meant. More,
when you context-click on an app in the menu, several options pop up
(copy launcher, remove from menu, etc.) - one of those would (could) be
"Uninstall application". Completely out of the way unless you're
looking for it.

Post by Nicolas Mailhot
We don't need no windowish in-your-face uninstall solutions, we don't
need popup eulas, change-install-location dialogs,
here-is-the-disc-size-I-need-please-check windows,
you-think-I'm-installed-but-check-my-20-pages-readme popups,
don't-bother-with-permissions-and-run-everything-as-admin

In many cases, we *do* need some of those. We *do* need EULA support,
for example, since applications I install often have them. Whether or
not you think they're evil, others need an installer that supports them
(versus the RPM way, which requires packagers to wrap the RPM in a shell
script which I then have to run in a command line to open, agree to the
EULA, and then install) as they use applications that have them, and
need to continue doing so.

Post by Nicolas Mailhot
(I case people wonder - I've just documented the installation of an app
that used a custom installer clearly written by a brainwashed
monopolysoft user. Just documenting this single installation took as
many pages as the ones devoted to updating the whole multi-hundred rpm
system)

Ya... let's keep this to technical facts, not "brainwashed Free Software
user" paranoia. Thanks. ;-)

Installation problems on Linux I've run into are almost always because
of RPM. If RPMs usually supported more than on particular snapshot of a
particular distro, if RPMs actually worked on all distros, and if RPM
had abilities to ask users install questions, select software
components, agree to legally-required EULAs (there's doubt that even the
GPL is really valid if the user is never forced to agree to it, or even
*see* it, to use the software), etc. then software developers probably
wouldn't need to rely on hacked-up installers.

As is, even most of the companies that ship RPMs generally need to wrap
them in shell scripts or other hacks in order to "add" the features RPM
denies them. Look at the Macromedia Flash, Adobe Acrobat Reader, or Sun
Java installs (I think those are the ones that use wrapped RPMs), for
example.

Post by Nicolas Mailhot
Anyway I don't know why I bother - just do your thing and I'll watch HiG
people shot it down.

Post by Mike Hearn

Post by Sean Middleditch
While I understand the use cases, as I've said on the autopackage lists,
and real Application Manager is needed (which I've some new ideas for,
i'll post those to the ap list).

Please do so. I'm not sold that we need any specific app management
program - it's the sort of thing users just never think about (much like
uninstalling stuff they no longer use).

Sure - why use a single consistent working solution when you can let
everyone reinvent incompatible wheels ?

That isn't the intent. The idea is to put the "single working solution"
somewhere other than a monolithic GUI manager. Altho, personally, I
still think the GUI manager is a necessity.

Post by Nicolas Mailhot

Post by Mike Hearn

Post by Sean Middleditch
Which isn't really possible. The best you could do is inform the user
that the system doesn't *appear* to be using the app anymore (no users
have a launcher for it, if you can even determine that easily) and let
them optionally uninstall it.
The same is true to libraries/dependencies - sure, normal users might
not need them if no other packages are using them, but hackers/admins
probably have a lot of stuff installed from source. So automatic
dependency "garbage" collection isn't really feasible, at least not
without lots and lots of user interaction and such.

Maybe.... still, it's been done in Java/C# for ages, despite the
difficulties. It seems unintuitive that it's possible with objects but
not packages.

There are *huge* differences, unfortunately, between an application
running and applications spread all over the file system. Garbage
collection in Java/C# doesn't happen across two apps connected over the
network, yet application garbage collection would need that for mounted
shares/volumes. Memory garbage collectors also have access to all
objects in existence, and (in good implementations) know when object
relationships are formed or broken - an application garbage collector
would need to somehow find out whenever any reference to an app has
changed. Memory collectors also don't support fancy memory tricks like
"hidden" pointers and such, but an application garbage collector would
need to know about "fancy tricks" like users using an app from the
command line or a script and not .desktop files.

Memory GC and application GC are really just two completely different
things.

Post by Nicolas Mailhot
Well I can tell you we have *nothing* to learn from java packaging,
quite the contrary. In fact the java world right now is a motherload of
bad packaging examples.

Post by Mike Hearn

Post by Sean Middleditch
Evangelism on the importance of proper development practices could be
useful, too. Probably the only place I've seen describing library
versioning in detail is the innards of the libtool manual. No wonder
lots of devs don't do it right, eh? Something like the war on drugs is
needed: DARP, Developers Against Ramshackle Packages. ;-)

Yeah, I want to do this too at some point, probably as part of the
packagers/developers guide we're writing for AP. There is a good paper
by Ulrich Drepper on writing DSOs, but it's basically impossible to find
unless somebody shows you. Other bad techniques are compile time
options, non-relocatability and so on. Developer education is definately
a part of the solution.

Developer education will *always* be a problem. Developing and packaging
are just two different CS specialities (just like developing and QA).
Some people will do both, most won't, expecting every single developer
to be able to package things is just a recipe for bad packaging.

Developers don't necessarily need to package. They *do* need to not be
so boneheaded as to make packaging impossible. i.e., when the packager
comes along and finds out that the only way to get "lite version" and
"full version" of the application packaged is to make them conflict with
each other, thus requiring a user to uninstall and reinstall the app to
"enable" features, the packager should bring the issue up with the
developer, who then should go, "oh, oops, will fix this!" and resolve
the problem on his end, allowing the packager to make sane, working
packagers that people besides l337 h4ck3r5 and sysadmins can install and
use.

As is now, the developer tends not to give a flying hoot (or just not
know any better), the packager can't resolve the issue with the
developer (or they themselves don't really understand the problem), and
we end up with tons of packages that don't really work unless installed
in one specific OS setup, when the moon is full, the stars are aligned
properly, the wind is blowing from the south-southeast at 45 knots, and
you've your ritual RPM body paint on with shell script incants written
all over your forehead.

Evangelism and education can help this. Simply not packaging brain-dead
broken software helps too; or, at least, understand that packages of
software like that should be the *exception*, not the rule. We'll
probably always have a couple pieces of popular software written by
dinks that think Linux should only be for the technologically elite and
kept away from "dr00ling lusers," but hopefully we can keep that to a
minimum.

Post by Nicolas Mailhot
Cheers,

[Nicolas Mailhot]

Post by Mike Hearn

Post by Sean Middleditch
That would be interesting. The problem is, then, every single app that
possibly exists in the application/dependency archive would be in the
menues. Ick.

No, only stuff the user had installed.

Please keep unstalling/uninstalling out of menus.

Windows only does it because for a long time they installation manager
panel missed most apps (and still misses some of them). So people had to
put uninstall links somewhere else. Really it's amazing how people
forget history and comme to accept ugly workarounds as the natural way
to do things.

We don't need no windowish in-your-face uninstall solutions, we don't
need popup eulas, change-install-location dialogs,
here-is-the-disc-size-I-need-please-check windows,
you-think-I'm-installed-but-check-my-20-pages-readme popups,
don't-bother-with-permissions-and-run-everything-as-admin

(I case people wonder - I've just documented the installation of an app
that used a custom installer clearly written by a brainwashed
monopolysoft user. Just documenting this single installation took as
many pages as the ones devoted to updating the whole multi-hundred rpm
system)

Anyway I don't know why I bother - just do your thing and I'll watch HiG
people shot it down.

Post by Mike Hearn

Post by Sean Middleditch
While I understand the use cases, as I've said on the autopackage lists,
and real Application Manager is needed (which I've some new ideas for,
i'll post those to the ap list).

Please do so. I'm not sold that we need any specific app management
program - it's the sort of thing users just never think about (much like
uninstalling stuff they no longer use).

Sure - why use a single consistent working solution when you can let
everyone reinvent incompatible wheels ?

Post by Mike Hearn

Post by Sean Middleditch
Which isn't really possible. The best you could do is inform the user
that the system doesn't *appear* to be using the app anymore (no users
have a launcher for it, if you can even determine that easily) and let
them optionally uninstall it.
The same is true to libraries/dependencies - sure, normal users might
not need them if no other packages are using them, but hackers/admins
probably have a lot of stuff installed from source. So automatic
dependency "garbage" collection isn't really feasible, at least not
without lots and lots of user interaction and such.

Maybe.... still, it's been done in Java/C# for ages, despite the
difficulties. It seems unintuitive that it's possible with objects but
not packages.

Well I can tell you we have *nothing* to learn from java packaging,
quite the contrary. In fact the java world right now is a motherload of
bad packaging examples.

Post by Mike Hearn

Post by Sean Middleditch
Evangelism on the importance of proper development practices could be
useful, too. Probably the only place I've seen describing library
versioning in detail is the innards of the libtool manual. No wonder
lots of devs don't do it right, eh? Something like the war on drugs is
needed: DARP, Developers Against Ramshackle Packages. ;-)

Yeah, I want to do this too at some point, probably as part of the
packagers/developers guide we're writing for AP. There is a good paper
by Ulrich Drepper on writing DSOs, but it's basically impossible to find
unless somebody shows you. Other bad techniques are compile time
options, non-relocatability and so on. Developer education is definately
a part of the solution.

Developer education will *always* be a problem. Developing and packaging
are just two different CS specialities (just like developing and QA).
Some people will do both, most won't, expecting every single developer
to be able to package things is just a recipe for bad packaging.

Cheers,
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20031012/63cc9dc5/attachment-0002.bin

[Mike Hearn]

Post by Sean Middleditch
LSB is just this, and many distros are LSB compliant these days.

Yeah, but LSB is really really LCD. No GUI libs (yet) for instance.

Post by Sean Middleditch
This sounds like it needs to be fixed; i.e., an easy way to disable
that. I know apps linked against older libcs work on RH9 (usually, the
occasional odd app fails, which is quite unfortunate).

That's what apbuild/apgcc do - ideally of course upgrading glibc would
be just like any other library but for some reason it isn't, so we have
to wind back the clock a little bit. Fortunately thread-local locales is
a features mostly useful for servers I think, so client side apps don't
need to worry about losing it.

Post by Sean Middleditch
That would be interesting. The problem is, then, every single app that
possibly exists in the application/dependency archive would be in the
menues. Ick.

No, only stuff the user had installed.

Post by Sean Middleditch
While I understand the use cases, as I've said on the autopackage lists,
and real Application Manager is needed (which I've some new ideas for,
i'll post those to the ap list).

Please do so. I'm not sold that we need any specific app management
program - it's the sort of thing users just never think about (much like
uninstalling stuff they no longer use).

Post by Sean Middleditch
Which isn't really possible. The best you could do is inform the user
that the system doesn't *appear* to be using the app anymore (no users
have a launcher for it, if you can even determine that easily) and let
them optionally uninstall it.
The same is true to libraries/dependencies - sure, normal users might
not need them if no other packages are using them, but hackers/admins
probably have a lot of stuff installed from source. So automatic
dependency "garbage" collection isn't really feasible, at least not
without lots and lots of user interaction and such.

Maybe.... still, it's been done in Java/C# for ages, despite the
difficulties. It seems unintuitive that it's possible with objects but
not packages.

Post by Sean Middleditch
Evangelism on the importance of proper development practices could be
useful, too. Probably the only place I've seen describing library
versioning in detail is the innards of the libtool manual. No wonder
lots of devs don't do it right, eh? Something like the war on drugs is
needed: DARP, Developers Against Ramshackle Packages. ;-)

Yeah, I want to do this too at some point, probably as part of the
packagers/developers guide we're writing for AP. There is a good paper
by Ulrich Drepper on writing DSOs, but it's basically impossible to find
unless somebody shows you. Other bad techniques are compile time
options, non-relocatability and so on. Developer education is definately
a part of the solution.

thanks -mike

[Nicolas Mailhot]

Post by Mike Hearn
Right. I quite like the idea of a non-technical user browsing to
frozen-bubble.org, and seeing the icon embedded in the web page. They
drag it to the panel, or perhaps even just click it in the webpage
directly. The button starts glowing or something to indicate that the
computer is working, and the process of installation gets going in the
background. When it's done, the icon goes coloured, maybe with some
pretty sparkly effect to indicate "newness", and the program launches.

Yeah and when you've done this you've also got virus, trojans, worms and
general system instability.

You can not trust just any random web page/gpg key/packager/whatever.
Distributions provide quality packaging, software review, system
consistency, etc (that's one of the reasons all the distributed software
projects that were proposed won't ever fly IMHO - there is no way so
many different actors with different priorities, backgrounds, deadlines,
etc can agree on a common set of rules strong enough to maintain the
overall quality a current distribution provides)

Now in the past one could say distros do not cover a large enough
spectrum. With projects like Fedora this is no longer true - you want
your app in Fedora just submit a quality package and it'll get in. Then
people will install it because they *trust* the Fedora signature/label.

Making a quality package is *hard*. Computer systems are *complex*. And
working outside of a big distribution-like project only makes packaging
*harder*.

Most of people who complain just want to offload crap packages on the
user like in the windows world. As someone who is regularly called to
clean up the damage these habits cause I respectfully disagree. It says
a lot that an experimental system like Rawhide often behaves better than
your average windows setup.

If you want to enlarge the packaged perimeter just mount a packager
group on which upstream projects can offload packaging problems.

If you think distributions are the problem (like autopackage people
obviously do) just get all people that think like you together and have
them agree on a common distribution method. I predict that the best
outcome will be yet another distribution (and the probable one utter
failure - people who don't want to package stuff cleanly now won't do it
tomorrow in another organisation)

There is one point I agree with you - it'd be cool if upstream projects
could more easily provide install profiles so people can use their stuff
after reading the web site. And this can be done pretty easily by a
comps.xml adaptation that would be fed to the local apt/yum/urpm that
would then pull relevant package_s_ from the *distribution* repository.

(and yes the package/profile separation is needed. I want to be able to
provide a artist profile and a tester profile, for example, and they
will both include the gimp package, because testers need to provide
annotated screenshots too)

And while there is room for gfx effects the core engine must be CLI/GUI
independent. I can assure you after the second installation you quickly
tire of the bloody widgets and yearn after something you can just run in
a ssh window/crontab/script. People will probably want to collect all
the profiles they commonly use on a floppy and feed all of them in a
single operation to the package manager of their new computer.

(think "modular kickstart")

Post by Mike Hearn
The app is now available from the menu, the web page, can be dragged to
the panel/desktop/whatever. User decides frozen bubble is really cute,
and opens up their chat program and drops the icon (the application, in
effect) into the chat window, where it appears the other end grayed out
and the process begins again. If that other user is on PowerPC and lives
the opposite end of the planet, no problems, the right download is
selected from the right mirror.
A lot of work, obviously, but all doable. First of all you need an easy
way to build distro-neutral packages. From my experiences, I'd say the
LSB is not it....

There is no easy way.
You want to do distro-neutral packages ? Fine.
Just be damn good.
The day someone in one of your target distros release a better package
than yours poof you've instantly lost part of your target audience.

Remember : distro-specific packagers have this advantage they can use
all kind of fun "extensions" when you can't.

Realistically that means :
1. do not try to repackage stuff that's already in the distributions
2. follow strictly FHS and the parts of LSB that make sense - be
stricter than the others packagers you'll compete with
3. package a large enough pool of interdependent software people won't
be able to take "just one bit" and make it distro-specific easily
4. have a team with people that regularly use all target distros
5. use file names not package names as dependencies - distros will
rename/split/merge packages but the FHS will force them to use the same
file locations
6. use an apt+yum+urpmi repository to reach as much people as possible
7. whenever disto X has cool extension Y you want to use gently push Y
for inclusion in the other target distributions

Cheers,
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20031012/22b4b15d/attachment.bin

[Mike Hearn]

Post by Nicolas Mailhot
Yeah and when you've done this you've also got virus, trojans, worms and
general system instability.

Consider: somebody wishes to play a game. It is written in C. There is
no package for their distribution. They can either:

a) Not play it.
b) Create a package, submit it to Fedora, ram it through the QA process
etc
c) Install from source and just play it.

Realistically, the vast majority will choose (c), and this is the
situation we are in now. It's really easy to get viruses, worms and
trojans into a system using source packages - a typical configure script
can be >100,000 lines long. So, not having a package at all is probably
more harmful in this respect than having a binary package produced by
the team that made the game.

Post by Nicolas Mailhot
You can not trust just any random web page/gpg key/packager/whatever.

Well, people can and do every day. The number of people who get
viruses/worms/whatever from bad installers on Windows is really low - it
almost invariably comes in through email or spyware in the apps itself.

Fedora QA does not actually audit the app obviously, just the package,
so it won't catch spyware embedded in the app.

Post by Nicolas Mailhot
Now in the past one could say distros do not cover a large enough
spectrum. With projects like Fedora this is no longer true - you want
your app in Fedora just submit a quality package and it'll get in.

99% of users cannot, will not package things. They will install things
in the easiest way possible, or leave the platform altogether if it's
too hard. Fedora cannot and will not package every piece of software in
the world, and keep it at the latest version. Debian has never managed
it, I see no reason to believe this time will be any different.

Post by Nicolas Mailhot
Making a quality package is *hard*. Computer systems are *complex*. And
working outside of a big distribution-like project only makes packaging
*harder*.

Writing quality software is far harder than writing quality packages,
yet somehow people manage. I don't see any reason why the same people
who create the software in the first place (and presumably the website
and documentation) cannot also create quality packages. Of course you
will get bad packages just as you get bad software, but this is life.

Post by Nicolas Mailhot
If you think distributions are the problem (like autopackage people
obviously do)

No, I don't know why you think that. We think distributions attempting
to package every piece of software they can is a problem, because it
doesn't scale. Windows and MacOS do not try this, neither should we.
Packaging is as much an integral part of building software as writing
documentation, test cases or the website is - there's no reason for it
to be separated.

Post by Nicolas Mailhot
There is one point I agree with you - it'd be cool if upstream projects
could more easily provide install profiles so people can use their stuff
after reading the web site. And this can be done pretty easily by a
comps.xml adaptation that would be fed to the local apt/yum/urpm that
would then pull relevant package_s_ from the *distribution* repository.

And if it isn't there? The user is still screwed. Worse, you get a bent
market - people will use Red Hat, Debian, SuSE or whatever not because
they are the best, but because there are more packages available for
that distribution. Clearly this is not desirable - look at the problems
caused by the apps market being distorted.

Post by Nicolas Mailhot
And while there is room for gfx effects the core engine must be CLI/GUI
independent.

Sure. It already is.

Post by Nicolas Mailhot
There is no easy way.
You want to do distro-neutral packages ? Fine.
Just be damn good.
The day someone in one of your target distros release a better package
than yours poof you've instantly lost part of your target audience.
Remember : distro-specific packagers have this advantage they can use
all kind of fun "extensions" when you can't.

Sure, and this is acknowledged in the FAQ - I'm not saying
distro-specific packages are bad, just that *only* having distro
packages is bad. If somebody wants to produce a Fedora only package that
uses cool extensions, more power to them - I'll probably use it.

thanks -mike

[Mike Hearn]

Post by Nicolas Mailhot
Yeah and when you've done this you've also got virus, trojans, worms and
general system instability.

Consider: somebody wishes to play a game. It is written in C. There is
no package for their distribution. They can either:

a) Not play it.
b) Create a package, submit it to Fedora, ram it through the QA process
etc
c) Install from source and just play it.

Realistically, the vast majority will choose (c), and this is the
situation we are in now. It's really easy to get viruses, worms and
trojans into a system using source packages - a typical configure script
can be >100,000 lines long. So, not having a package at all is probably
more harmful in this respect than having a binary package produced by
the team that made the game.

Post by Nicolas Mailhot
You can not trust just any random web page/gpg key/packager/whatever.

Well, people can and do every day. The number of people who get
viruses/worms/whatever from bad installers on Windows is really low - it
almost invariably comes in through email or spyware in the apps itself.

Fedora QA does not actually audit the app obviously, just the package,
so it won't catch spyware embedded in the app.

Post by Nicolas Mailhot
Now in the past one could say distros do not cover a large enough
spectrum. With projects like Fedora this is no longer true - you want
your app in Fedora just submit a quality package and it'll get in.

99% of users cannot, will not package things. They will install things
in the easiest way possible, or leave the platform altogether if it's
too hard. Fedora cannot and will not package every piece of software in
the world, and keep it at the latest version. Debian has never managed
it, I see no reason to believe this time will be any different.

Post by Nicolas Mailhot
Making a quality package is *hard*. Computer systems are *complex*. And
working outside of a big distribution-like project only makes packaging
*harder*.

Writing quality software is far harder than writing quality packages,
yet somehow people manage. I don't see any reason why the same people
who create the software in the first place (and presumably the website
and documentation) cannot also create quality packages. Of course you
will get bad packages just as you get bad software, but this is life.

Post by Nicolas Mailhot
If you think distributions are the problem (like autopackage people
obviously do)

No, I don't know why you think that. We think distributions attempting
to package every piece of software they can is a problem, because it
doesn't scale. Windows and MacOS do not try this, neither should we.
Packaging is as much an integral part of building software as writing
documentation, test cases or the website is - there's no reason for it
to be separated.

Post by Nicolas Mailhot
There is one point I agree with you - it'd be cool if upstream projects
could more easily provide install profiles so people can use their stuff
after reading the web site. And this can be done pretty easily by a
comps.xml adaptation that would be fed to the local apt/yum/urpm that
would then pull relevant package_s_ from the *distribution* repository.

And if it isn't there? The user is still screwed. Worse, you get a bent
market - people will use Red Hat, Debian, SuSE or whatever not because
they are the best, but because there are more packages available for
that distribution. Clearly this is not desirable - look at the problems
caused by the apps market being distorted.

Post by Nicolas Mailhot
And while there is room for gfx effects the core engine must be CLI/GUI
independent.

Sure. It already is.

Post by Nicolas Mailhot
There is no easy way.
You want to do distro-neutral packages ? Fine.
Just be damn good.
The day someone in one of your target distros release a better package
than yours poof you've instantly lost part of your target audience.
Remember : distro-specific packagers have this advantage they can use
all kind of fun "extensions" when you can't.

Sure, and this is acknowledged in the FAQ - I'm not saying
distro-specific packages are bad, just that *only* having distro
packages is bad. If somebody wants to produce a Fedora only package that
uses cool extensions, more power to them - I'll probably use it.

thanks -mike

[Havoc Pennington]

Post by Mike Hearn
Simply bundling everything with the app really is not acceptable,
especially for dialup users. Example: Gaim for Linux - RPM is 1.7mb (i
think), Gaim for Windows - self extracting EXE with GTK+ is 6.7mb

Oh, I agree. Nonetheless it's a solution to "dependency hell."

My argument: there's a tradeoff. One shouldn't whine about dependencies
unless you can live with duplication. Because you win one or the other
and you may as well suck it up and live with this reality.

Post by Mike Hearn
Now, you can say "Linux is a platform, which consists of libraries A, B
and C - do not depend on anything else".

Right, this is what I mean by the placeholder term "LSB." LSB in
practice is lagging the actual platform people want to use by quite a
bit and seems to have some implementation issues as you mentioned. But
LSB is only one possible token of the type "define a core guaranteed
dependency set that will always exist, and apps must internalize
anything not in that core set" - which is the general approach for
avoiding "dependency hell" used by Windows/Mac.

To clarify dependency hell; if by that one simply means having to find
dependencies and install them, then you either internalize
non-core-platform deps, or you have external dependencies. That tradeoff
will never go away. Best you can do is have tools such as
yum/up2date/apt to simplify things.

If by dependency hell one means having to choose between set of apps
requiring library Foo version 1 and set of apps requiring library Foo
version 2, the solution to that is also known:
http://ometer.com/parallel.html and/or "compat" packages and soname
changes.

Unfortunately the upstream maintainers of many libraries are
uncooperative when it comes to solving this problem.

Some people seem to think there's a magic bullet here or that solutions
aren't known. I would say the solutions and tradeoffs _are_ known, and
people are just unwilling to accept them.

I don't believe the packaging format (RPM vs. whatever) has a *thing* to
do with it. RPM allows you to express dependencies to automated tools.
However, it doesn't _create_ the dependencies; you are free to have them
or not as you see fit. So blaming dependency hell on RPM is just
shooting the messenger.

Havoc

[Mike Hearn]

Post by Havoc Pennington
which is the general approach for
avoiding "dependency hell" used by Windows/Mac.

Mmm. I have a feeling it simply replaces it with other types of hell. On
MacOS X the glacial rollout of weak symbols mean that apps frequently
depend on point releases of the whole OS. On Windows, the situation is
somewhat better, but only because Microsoft release updates for OSs that
are over 5 years old.

Post by Havoc Pennington
To clarify dependency hell; if by that one simply means having to find
dependencies and install them, then you either internalize
non-core-platform deps, or you have external dependencies. That tradeoff
will never go away. Best you can do is have tools such as
yum/up2date/apt to simplify things.

Of course that's correct, but the problem is people have used tools like
apt and see that they work well, and are convenient. They want them to
work well all the time, instead of just some of the time. I think
boosting the success rate of these types of tools is certainly doable.

Post by Havoc Pennington
If by dependency hell one means having to choose between set of apps
requiring library Foo version 1 and set of apps requiring library Foo
http://ometer.com/parallel.html and/or "compat" packages and soname
changes.

Right - I wasn't really meaning this, but parallel installability is
clearly an educational issue.

Post by Havoc Pennington
I don't believe the packaging format (RPM vs. whatever) has a *thing* to
do with it. RPM allows you to express dependencies to automated tools.
However, it doesn't _create_ the dependencies; you are free to have them
or not as you see fit. So blaming dependency hell on RPM is just
shooting the messenger.

It's reasonable that RPM gets beat up a bit - this particular messenger
sometimes gets it wrong (for instance when you install from source).

Perhaps some of the blame lies with developers for going overboard with
dependencies, but perhaps also it is up to us to technically manage this
situation better (which I think can be done).

thanks -mike

[Mike Hearn]

Post by Havoc Pennington
which is the general approach for
avoiding "dependency hell" used by Windows/Mac.

Mmm. I have a feeling it simply replaces it with other types of hell. On
MacOS X the glacial rollout of weak symbols mean that apps frequently
depend on point releases of the whole OS. On Windows, the situation is
somewhat better, but only because Microsoft release updates for OSs that
are over 5 years old.

Post by Havoc Pennington
To clarify dependency hell; if by that one simply means having to find
dependencies and install them, then you either internalize
non-core-platform deps, or you have external dependencies. That tradeoff
will never go away. Best you can do is have tools such as
yum/up2date/apt to simplify things.

Of course that's correct, but the problem is people have used tools like
apt and see that they work well, and are convenient. They want them to
work well all the time, instead of just some of the time. I think
boosting the success rate of these types of tools is certainly doable.

Post by Havoc Pennington
If by dependency hell one means having to choose between set of apps
requiring library Foo version 1 and set of apps requiring library Foo
http://ometer.com/parallel.html and/or "compat" packages and soname
changes.

Right - I wasn't really meaning this, but parallel installability is
clearly an educational issue.

Post by Havoc Pennington
I don't believe the packaging format (RPM vs. whatever) has a *thing* to
do with it. RPM allows you to express dependencies to automated tools.
However, it doesn't _create_ the dependencies; you are free to have them
or not as you see fit. So blaming dependency hell on RPM is just
shooting the messenger.

It's reasonable that RPM gets beat up a bit - this particular messenger
sometimes gets it wrong (for instance when you install from source).

Perhaps some of the blame lies with developers for going overboard with
dependencies, but perhaps also it is up to us to technically manage this
situation better (which I think can be done).

thanks -mike

[Sean Middleditch]

Post by Mike Hearn
Another simple example - statically linking the Jamboree gnome music
player would change the size of the binary from 600k to 24mb, which is
clearly insane.

Statically linking isn't the answer proposed at all. Anyone trying to
do that will make the situation *much* worse.

I'm ASSuming Havoc meant bundling with as how many Windows apps do it -
they come (metaphorically speaking) as a bundle of RPMs, and the
dependencies are then installed as needed.

With our world of up2date/yum/apt we don't need to bundle the
dependencies. We just need to not keep breaking them so they stop
working unless you recompile half the machine. i.e., if mydep 1.1 isn't
API/ABI compatable with mydep 1.0, they must be coinstallable, and the
library versions updated.

Post by Mike Hearn
Now, you can say "Linux is a platform, which consists of libraries A, B
and C - do not depend on anything else". That approach basically works,
but is kind of difficult to force through. One mans essential library is

LSB is just this, and many distros are LSB compliant these days.

Post by Mike Hearn
anothers bloat, it may be that some libraries cannot commit to the ABI
guarantees needed etc. I have 151 packages installed with "lib" in their
name, it'd be pretty hard to get them all into even a tiered platform,
though it could be done.

Those that can't keep a stable ABI simply need to reflect this in some
meaningful way to both developers and users - soversions and
co-installable data, big warning labels, etc.

Post by Mike Hearn

Post by Havoc Pennington
It's also what an LSB-compliant package _must_ do. But of course, nobody
seems to make LSB-compliant packages, instead they just complain about
how packages are distribution-dependent. ;-) People, this is the whole
point of the LSB...

Well, have you tried to make an LSB compliant package? It is really
quite hard. For instance, a standard compile of any non-trivial C app on
RH9 will pull in the thread-local locale model stuff from glibc 2.3.

This sounds like it needs to be fixed; i.e., an easy way to disable
that. I know apps linked against older libcs work on RH9 (usually, the
occasional odd app fails, which is quite unfortunate).

Post by Mike Hearn
You can use the lsb tools to statically link everything needed, but it
really does have to be *everything*, you cannot say "well everybody has
GTK, i'll skip that" - the way the tools work mean the build will fail
if you link against libraries that were not LSB compiled themselves.
That's not really intentional, it's just because ld wants to completely
close the symbol set. We figured out a way around that with apbuild, but
the LSB weren't interested of course - they *want* people to be forced
to only use their base set (they need to be able to guarantee what an
LSB app is and isn't).

Which is good. The LSB just needs to define more packages. But that's
just LSB. LSB is, again, most useful for commercial software. When
talking open-source apps, we have a lot more leeway. Namely, the
upstream devs can provide the "standard". Example, so long as the GTK
devs don't break their excellent track record of sane API/ABI
versioning, and so long as people package it properly (which, so far, is
the case on RH/Fedora), software can rely on GTK.

The same goes for any other dependency in which the upstream authors
apply proper release techniques.

Post by Mike Hearn
Not to mention that the LSB headers are not the same as the glibc ones,
for instance I once tried to compile DBUS (i think v0.1 or something
quite old now) as an LSB app to see what it was like, but the build
failed due to obscure bugs in the LSB headers. Something to do with
sunrpc iirc, which was wierd but there you go. I should try again
sometime, as I reported the bug.

LSB, I should note, also isn't for low-level system stuff. It's really
for monolithic apps. I don't even see the point in installing something
like, say, apache, as an LSB package - its not really the target
audience.

Post by Mike Hearn
Then you have to be able to make an RPMv3 package that meets their
stringent restrictions etc...
So back to my original example, an LSB package of Jamboree would have
taken most of the day to download on a 56kbit connection, as opposed to
approx 5 mins for a non-LSB package that simply depended on the right
libraries.

Post by Havoc Pennington
Unfortunately, for moving around and launching you're using a .desktop
file. For install/uninstall you're using the r-c-p "comps group" concept
sometimes, and "foo.rpm" files sometimes.

Yes, this is not ideal. The way I was planning to tackle this (when
someday autopackage doesn't suck) was to embed package information into
the .desktop file, then teach Nautilus/Konqueror about that. They could
read the .desktop file, see that the relevant program was not installed
and perhaps gray it out to show that it'd take some time to launch
(because it'd need to be downloaded). The launcher, when clicked, takes
care of download, verification, installation, dep resolution and so on.

That would be interesting. The problem is, then, every single app that
possibly exists in the application/dependency archive would be in the
menues. Ick.

While I understand the use cases, as I've said on the autopackage lists,
and real Application Manager is needed (which I've some new ideas for,
i'll post those to the ap list).

Post by Mike Hearn
You could also use the launcher to uninstall, though the idea of garbage
collecting packages appeals to me in some vague way.

Which isn't really possible. The best you could do is inform the user
that the system doesn't *appear* to be using the app anymore (no users
have a launcher for it, if you can even determine that easily) and let
them optionally uninstall it.

The same is true to libraries/dependencies - sure, normal users might
not need them if no other packages are using them, but hackers/admins
probably have a lot of stuff installed from source. So automatic
dependency "garbage" collection isn't really feasible, at least not
without lots and lots of user interaction and such.

Post by Mike Hearn
In this scenario you have only one concept as a user, that of "the
application" (or launcher) - you can click it, email it to friends, drop
it on a disk etc, and the details of what CPU arch and deps you have etc
are sorted out by the system.
It's kind of like the MacOS X AppFolders system UI wise, except without
the massive bloat and suckyness that accompanies a pure NeXT style
system.

Post by Havoc Pennington
- a way to bundle a set of RPMs into a single user-visible file,
so you can have an "uninstalled app" visible in the file manager

Too large for dialup users I think :(

It could be useful for on-disk management, corporate deployment, CDs,
etc. But probably not useful enough if the tools just become more
intelligent; i.e., if I click on a package in Nautilus and
redhat-install-packages sees I'm missing a dependency, it should try
looking in the folder the main package is in to find them. That would
make a lot of "off the 'net" RPM installations easier, for one. If the
package could point to URLs that have a list of packages for dependency
resolution, it would get even cooler (tho then GPG security and such
would probably be more important - I can just see the "Trust content
from Macromedia" dialogs and such one's accustomed to in Windows... but
then, blindly trusting an entire distro which is community based and in
which nearly anyone can eventually get access to upload packages, those
incessant dialogs are probably a better approach...)

Post by Mike Hearn

Post by Havoc Pennington
- have ways to install/uninstall a package by manipulating the thing
implemented now as a .desktop file (the menu/filemanager entry)

Seems the easiest way forward, though it'd be easier still if there were
standards for packaging.

yay standards! ;-)

Post by Mike Hearn

Post by Havoc Pennington
- try to ensure packages for "end user apps" always have names that
match the primary desktop file in the package; so e.g. the Gnumeric
.rpm package would show up in file manager as "Gnumeric Spreadsheet"
and once installed you get same in menu

Kind of icky. What happens if you click an installed RPM? It'd look like
it should run the app, but then how do you remove it? It also relies on
something that could be broken quite easily (the name mapping).

Fortunately, the file name of an RPM is completely arbitrary. In large
collections with comps file (or whatever), "specific" naming is
possible; but if I want to put an RPM of some single piece of software
on my site, I'm quite free to call it anything.

Post by Mike Hearn

Post by Havoc Pennington
Those are just some possibilities, not well-researched proposals. The
general idea is to fix the "leakiness" of the current abstraction;
ideally, a naive end user doesn't have to learn 3 implementation details
when a single concept of "an application" should be sufficient.

Right. I quite like the idea of a non-technical user browsing to
frozen-bubble.org, and seeing the icon embedded in the web page. They
drag it to the panel, or perhaps even just click it in the webpage
directly. The button starts glowing or something to indicate that the
computer is working, and the process of installation gets going in the
background. When it's done, the icon goes coloured, maybe with some
pretty sparkly effect to indicate "newness", and the program launches.

Hmm, a bit farther than I had in mind, but it would certainly work; one
can imagine the "RPM Installer" Mozilla plugin. ;-)

If we even get to the point tho where the user can click the website
icon, and the Browser pops up a "Install Application?" dialog that
downloads and installs without the glitz, we'd be a long way ahead of
where we are now (click icon, get RPM, watch it not work, realize some
goof made the libinsane1 on OS release 2 completely incompatible with
libinsane1 on OS release 1, spend time figuring out whether the lib or
the app is easier to rebuild, find out the rebuild needs tons of build
dependencies which the tools don't bother to grab for you, etc. etc.).

Post by Mike Hearn
The app is now available from the menu, the web page, can be dragged to
the panel/desktop/whatever. User decides frozen bubble is really cute,
and opens up their chat program and drops the icon (the application, in
effect) into the chat window, where it appears the other end grayed out
and the process begins again. If that other user is on PowerPC and lives
the opposite end of the planet, no problems, the right download is
selected from the right mirror.

That would certainly be nifty. Really, all that would require a small
.desktop-like file describing the package, and the mirror-net its on.
The install app just finds a mirror, looks up the real package (and
dependencies, possibly querying not only the app's mirror but also the
distro's repository), etc. Heck, I think there are a couple (not nearly
done) apps that do just this, minus the high-level of desktop
integration.

Post by Mike Hearn
A lot of work, obviously, but all doable. First of all you need an easy
way to build distro-neutral packages. From my experiences, I'd say the
LSB is not it....

Agreed. Most of the responsibility has to lay with the upstream
developers. If the authors of libfoobar are goofs and refuse to put the
3 seconds of effort forth to make their software at least co-installable
with other versions, than any upstream dev who relies on libfoobar is
just as guilty of bad practices.

A good guide on packaging might help resolve a number of such
situation. One of the biggest problems with RPMs isn't even that the
software is actually incompatible, just that the packaging *makes* it
incompatible; packages putting things in different locations, packages
that conflict with each other in order to provide different optional
featuresets (why in all the world should a user have to unisntall an app
to add features? sounds dumb, but yet we have to do it many times,
because make packages like someapp-nofeatures, someapp-feature1,
someapp-feature2, someapp-allfeatures, etc. not necessary!)

Evangelism on the importance of proper development practices could be
useful, too. Probably the only place I've seen describing library
versioning in detail is the innards of the libtool manual. No wonder
lots of devs don't do it right, eh? Something like the war on drugs is
needed: DARP, Developers Against Ramshackle Packages. ;-)

Post by Mike Hearn
thanks -mike
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

[Nicolas Mailhot]

Post by Mike Hearn
Right. I quite like the idea of a non-technical user browsing to
frozen-bubble.org, and seeing the icon embedded in the web page. They
drag it to the panel, or perhaps even just click it in the webpage
directly. The button starts glowing or something to indicate that the
computer is working, and the process of installation gets going in the
background. When it's done, the icon goes coloured, maybe with some
pretty sparkly effect to indicate "newness", and the program launches.

Yeah and when you've done this you've also got virus, trojans, worms and
general system instability.

You can not trust just any random web page/gpg key/packager/whatever.
Distributions provide quality packaging, software review, system
consistency, etc (that's one of the reasons all the distributed software
projects that were proposed won't ever fly IMHO - there is no way so
many different actors with different priorities, backgrounds, deadlines,
etc can agree on a common set of rules strong enough to maintain the
overall quality a current distribution provides)

Now in the past one could say distros do not cover a large enough
spectrum. With projects like Fedora this is no longer true - you want
your app in Fedora just submit a quality package and it'll get in. Then
people will install it because they *trust* the Fedora signature/label.

Making a quality package is *hard*. Computer systems are *complex*. And
working outside of a big distribution-like project only makes packaging
*harder*.

Most of people who complain just want to offload crap packages on the
user like in the windows world. As someone who is regularly called to
clean up the damage these habits cause I respectfully disagree. It says
a lot that an experimental system like Rawhide often behaves better than
your average windows setup.

If you want to enlarge the packaged perimeter just mount a packager
group on which upstream projects can offload packaging problems.

If you think distributions are the problem (like autopackage people
obviously do) just get all people that think like you together and have
them agree on a common distribution method. I predict that the best
outcome will be yet another distribution (and the probable one utter
failure - people who don't want to package stuff cleanly now won't do it
tomorrow in another organisation)

There is one point I agree with you - it'd be cool if upstream projects
could more easily provide install profiles so people can use their stuff
after reading the web site. And this can be done pretty easily by a
comps.xml adaptation that would be fed to the local apt/yum/urpm that
would then pull relevant package_s_ from the *distribution* repository.

(and yes the package/profile separation is needed. I want to be able to
provide a artist profile and a tester profile, for example, and they
will both include the gimp package, because testers need to provide
annotated screenshots too)

And while there is room for gfx effects the core engine must be CLI/GUI
independent. I can assure you after the second installation you quickly
tire of the bloody widgets and yearn after something you can just run in
a ssh window/crontab/script. People will probably want to collect all
the profiles they commonly use on a floppy and feed all of them in a
single operation to the package manager of their new computer.

(think "modular kickstart")

Post by Mike Hearn
The app is now available from the menu, the web page, can be dragged to
the panel/desktop/whatever. User decides frozen bubble is really cute,
and opens up their chat program and drops the icon (the application, in
effect) into the chat window, where it appears the other end grayed out
and the process begins again. If that other user is on PowerPC and lives
the opposite end of the planet, no problems, the right download is
selected from the right mirror.
A lot of work, obviously, but all doable. First of all you need an easy
way to build distro-neutral packages. From my experiences, I'd say the
LSB is not it....

There is no easy way.
You want to do distro-neutral packages ? Fine.
Just be damn good.
The day someone in one of your target distros release a better package
than yours poof you've instantly lost part of your target audience.

Remember : distro-specific packagers have this advantage they can use
all kind of fun "extensions" when you can't.

Realistically that means :
1. do not try to repackage stuff that's already in the distributions
2. follow strictly FHS and the parts of LSB that make sense - be
stricter than the others packagers you'll compete with
3. package a large enough pool of interdependent software people won't
be able to take "just one bit" and make it distro-specific easily
4. have a team with people that regularly use all target distros
5. use file names not package names as dependencies - distros will
rename/split/merge packages but the FHS will force them to use the same
file locations
6. use an apt+yum+urpmi repository to reach as much people as possible
7. whenever disto X has cool extension Y you want to use gently push Y
for inclusion in the other target distributions

Cheers,
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20031012/22b4b15d/attachment-0002.bin

[Havoc Pennington]

Post by Mike Hearn
Simply bundling everything with the app really is not acceptable,
especially for dialup users. Example: Gaim for Linux - RPM is 1.7mb (i
think), Gaim for Windows - self extracting EXE with GTK+ is 6.7mb

Oh, I agree. Nonetheless it's a solution to "dependency hell."

My argument: there's a tradeoff. One shouldn't whine about dependencies
unless you can live with duplication. Because you win one or the other
and you may as well suck it up and live with this reality.

Post by Mike Hearn
Now, you can say "Linux is a platform, which consists of libraries A, B
and C - do not depend on anything else".

Right, this is what I mean by the placeholder term "LSB." LSB in
practice is lagging the actual platform people want to use by quite a
bit and seems to have some implementation issues as you mentioned. But
LSB is only one possible token of the type "define a core guaranteed
dependency set that will always exist, and apps must internalize
anything not in that core set" - which is the general approach for
avoiding "dependency hell" used by Windows/Mac.

To clarify dependency hell; if by that one simply means having to find
dependencies and install them, then you either internalize
non-core-platform deps, or you have external dependencies. That tradeoff
will never go away. Best you can do is have tools such as
yum/up2date/apt to simplify things.

If by dependency hell one means having to choose between set of apps
requiring library Foo version 1 and set of apps requiring library Foo
version 2, the solution to that is also known:
http://ometer.com/parallel.html and/or "compat" packages and soname
changes.

Unfortunately the upstream maintainers of many libraries are
uncooperative when it comes to solving this problem.

Some people seem to think there's a magic bullet here or that solutions
aren't known. I would say the solutions and tradeoffs _are_ known, and
people are just unwilling to accept them.

I don't believe the packaging format (RPM vs. whatever) has a *thing* to
do with it. RPM allows you to express dependencies to automated tools.
However, it doesn't _create_ the dependencies; you are free to have them
or not as you see fit. So blaming dependency hell on RPM is just
shooting the messenger.

Havoc

[Nicolas Mailhot]

Post by Havoc Pennington
- a way to bundle a set of RPMs into a single user-visible file,
so you can have an "uninstalled app" visible in the file manager

Actually the smart thing would be to distribute apt/yum/up2date profiles
that match an usage, and let them the package manager download the parts
that are not installed yet and all second, third, fourth... -level
dependencies.

I'll be strongly suspicious of any application-level bundling. Upstream
projects just do not care enough to get all peripheral stuff right. OTOH
some way to specify weak user-level dependencies (like "my doc is in pdf
- get yourself a pdf reader") would help many people ("hard"
dependencies ie stuff that is required by the code to work being handled
the usual rpm way).

Cheers,
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20031005/fd2b0e32/attachment-0002.bin

[Mike Hearn]

Post by Havoc Pennington
The solution to end-user dependency problems is very simple, and it is
the same one used on Windows.

I've come late to this thread, blame freshers week at my university :)

Anyway, I respectfully disagree. We're in a fundamentally different
scenario to that of Win32 developers, namely that:

a) We're massively outnumbered
b) Linux users tend to have a lot more software installed than Windows
users do
c) Software is a lot more modular

Simply bundling everything with the app really is not acceptable,
especially for dialup users. Example: Gaim for Linux - RPM is 1.7mb (i
think), Gaim for Windows - self extracting EXE with GTK+ is 6.7mb

OK, so that makes little difference when you have half a megabit piped
into your house or room, but it makes all the difference for the
majority of the world who don't. Obviously Gaim is a program with few
dependencies.

Another simple example - statically linking the Jamboree gnome music
player would change the size of the binary from 600k to 24mb, which is
clearly insane.

Now, you can say "Linux is a platform, which consists of libraries A, B
and C - do not depend on anything else". That approach basically works,
but is kind of difficult to force through. One mans essential library is
anothers bloat, it may be that some libraries cannot commit to the ABI
guarantees needed etc. I have 151 packages installed with "lib" in their
name, it'd be pretty hard to get them all into even a tiered platform,
though it could be done.

Post by Havoc Pennington
It's also what an LSB-compliant package _must_ do. But of course, nobody
seems to make LSB-compliant packages, instead they just complain about
how packages are distribution-dependent. ;-) People, this is the whole
point of the LSB...

Well, have you tried to make an LSB compliant package? It is really
quite hard. For instance, a standard compile of any non-trivial C app on
RH9 will pull in the thread-local locale model stuff from glibc 2.3.

You can use the lsb tools to statically link everything needed, but it
really does have to be *everything*, you cannot say "well everybody has
GTK, i'll skip that" - the way the tools work mean the build will fail
if you link against libraries that were not LSB compiled themselves.
That's not really intentional, it's just because ld wants to completely
close the symbol set. We figured out a way around that with apbuild, but
the LSB weren't interested of course - they *want* people to be forced
to only use their base set (they need to be able to guarantee what an
LSB app is and isn't).

Not to mention that the LSB headers are not the same as the glibc ones,
for instance I once tried to compile DBUS (i think v0.1 or something
quite old now) as an LSB app to see what it was like, but the build
failed due to obscure bugs in the LSB headers. Something to do with
sunrpc iirc, which was wierd but there you go. I should try again
sometime, as I reported the bug.

Then you have to be able to make an RPMv3 package that meets their
stringent restrictions etc...

So back to my original example, an LSB package of Jamboree would have
taken most of the day to download on a 56kbit connection, as opposed to
approx 5 mins for a non-LSB package that simply depended on the right
libraries.

Post by Havoc Pennington
Unfortunately, for moving around and launching you're using a .desktop
file. For install/uninstall you're using the r-c-p "comps group" concept
sometimes, and "foo.rpm" files sometimes.

Yes, this is not ideal. The way I was planning to tackle this (when
someday autopackage doesn't suck) was to embed package information into
the .desktop file, then teach Nautilus/Konqueror about that. They could
read the .desktop file, see that the relevant program was not installed
and perhaps gray it out to show that it'd take some time to launch
(because it'd need to be downloaded). The launcher, when clicked, takes
care of download, verification, installation, dep resolution and so on.

You could also use the launcher to uninstall, though the idea of garbage
collecting packages appeals to me in some vague way.

In this scenario you have only one concept as a user, that of "the
application" (or launcher) - you can click it, email it to friends, drop
it on a disk etc, and the details of what CPU arch and deps you have etc
are sorted out by the system.

It's kind of like the MacOS X AppFolders system UI wise, except without
the massive bloat and suckyness that accompanies a pure NeXT style
system.

Post by Havoc Pennington
- a way to bundle a set of RPMs into a single user-visible file,
so you can have an "uninstalled app" visible in the file manager

Too large for dialup users I think :(

Post by Havoc Pennington
- have ways to install/uninstall a package by manipulating the thing
implemented now as a .desktop file (the menu/filemanager entry)

Seems the easiest way forward, though it'd be easier still if there were
standards for packaging.

Post by Havoc Pennington
- try to ensure packages for "end user apps" always have names that
match the primary desktop file in the package; so e.g. the Gnumeric
.rpm package would show up in file manager as "Gnumeric Spreadsheet"
and once installed you get same in menu

Kind of icky. What happens if you click an installed RPM? It'd look like
it should run the app, but then how do you remove it? It also relies on
something that could be broken quite easily (the name mapping).

Post by Havoc Pennington
Those are just some possibilities, not well-researched proposals. The
general idea is to fix the "leakiness" of the current abstraction;
ideally, a naive end user doesn't have to learn 3 implementation details
when a single concept of "an application" should be sufficient.

Right. I quite like the idea of a non-technical user browsing to
frozen-bubble.org, and seeing the icon embedded in the web page. They
drag it to the panel, or perhaps even just click it in the webpage
directly. The button starts glowing or something to indicate that the
computer is working, and the process of installation gets going in the
background. When it's done, the icon goes coloured, maybe with some
pretty sparkly effect to indicate "newness", and the program launches.

The app is now available from the menu, the web page, can be dragged to
the panel/desktop/whatever. User decides frozen bubble is really cute,
and opens up their chat program and drops the icon (the application, in
effect) into the chat window, where it appears the other end grayed out
and the process begins again. If that other user is on PowerPC and lives
the opposite end of the planet, no problems, the right download is
selected from the right mirror.

A lot of work, obviously, but all doable. First of all you need an easy
way to build distro-neutral packages. From my experiences, I'd say the
LSB is not it....

thanks -mike

[Havoc Pennington]

Post by Michael Schwendt

Post by Andy Hanton
Even if we become like debian with 10,000
packages that won't solve the cross distribution problem.

Ah, cross-distribution. *cough* Who makes sure that app A from site B
and lib D from site E for distribution C work smoothly on distribution
F where inter-library dependencies are satisfied with packages from
site G? Where is the testing and quality assurance in this scenario?

The solution to end-user dependency problems is very simple, and it is
the same one used on Windows.

Here it is: don't have any dependencies that don't come with the OS.
Bundle everything internal to your app.

This is what almost all proprietary software for Linux does.

It's also what an LSB-compliant package _must_ do. But of course, nobody
seems to make LSB-compliant packages, instead they just complain about
how packages are distribution-dependent. ;-) People, this is the whole
point of the LSB...

For software that comes with the OS and lives in the Fedora Project, we
should be able to do better; redhat-config-packages doesn't make you see
dependencies really, and it could be made even better than it is.

Here is one way to think about it from a UI standpoint. The user model
is that there's "the application" which can be installed, uninstalled,
moved around, and launched.

Unfortunately, for moving around and launching you're using a .desktop
file. For install/uninstall you're using the r-c-p "comps group" concept
sometimes, and "foo.rpm" files sometimes. So there are three
implementation details leaking out, where the simple user model would
have only 1 concept.

So ways to improve this might include:

- a way to bundle a set of RPMs into a single user-visible file,
so you can have an "uninstalled app" visible in the file manager

- have ways to install/uninstall a package by manipulating the thing
implemented now as a .desktop file (the menu/filemanager entry)

- try to ensure packages for "end user apps" always have names that
match the primary desktop file in the package; so e.g. the Gnumeric
.rpm package would show up in file manager as "Gnumeric Spreadsheet"
and once installed you get same in menu

Those are just some possibilities, not well-researched proposals. The
general idea is to fix the "leakiness" of the current abstraction;
ideally, a naive end user doesn't have to learn 3 implementation details
when a single concept of "an application" should be sufficient.

Havoc

[Michael Schwendt]

Post by Andy Hanton
It doesn't really help as much for common libraries. The idea is that
library authors can maintain their own binaries. Application authors
can be sure that the end user's system will be able to find the library
because the url is embedded in the binary.

So, in other words I would depend on arbitrary sites to supply prebuilt
libraries rather than getting software from trusted community
repositories? Would those prebuilt libraries be of the same poor quality
than what is offered on the average upstream site? The average upstream
site features contributed packages. Contributed by individuals. The same
individual who would contribute their packages to a community project,
provided that such a community project is available.

Post by Andy Hanton
Try rpm --redhatprovides libenchant.so.1.0.0 on a redhat 9 box.
/uri/0install/www.abisource.com/enchant/libenchant.so.1.0.0
would clearly be better in that case.

Not clear at all. Why would I need that library? Why wouldn't it be
found automatically when I install an application with e.g. Yum? Why
hasn't anyone created a src.rpm for it? Aha, the software is complicated
to install from source? There we have the real problem.

Post by Andy Hanton
I think the idea that we can package all the dependencies that could
ever exist is unrealistic.

Only what is popular or worthwhile gets packaged by someone.
Everything else can be rebuilt from source.

Post by Andy Hanton
Even if we become like debian with 10,000
packages that won't solve the cross distribution problem.

Ah, cross-distribution. *cough* Who makes sure that app A from site B
and lib D from site E for distribution C work smoothly on distribution
F where inter-library dependencies are satisfied with packages from
site G? Where is the testing and quality assurance in this scenario?

Post by Andy Hanton
You can't
tell your grandmother who runs Suse to go to the web page and download
an rpm because suse hasn't packaged all the dependencies.

Isn't that what Fedora Extras tries to target? The chance for the
community to package the popular stuff and maintain it as long as
their is enough interest in it?

Post by Andy Hanton
With zero-install the user never actually uses a package
management system.
1.download an application from the author's web page
2. double click the archive to untar it
3. double-click the application and it runs

Scary scenario. Even more scary when the application asks for
superuser privileges in order to perform some ordinary integration
tasks. The scenario gets threatening when the author of the
application focuses on prebuilt binaries as primary distribution
channel and neglects the source code level. Oh, and don't dare to
report a bug to the author when you run a different distribution.

- --
Michael, who doesn't reply to top posts and complete quotes anymore.

[Andy Hanton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Andy Hanton
They aren't the only ones working on this stuff. The zero-install
project (http://zero-install.sf.net/) seems to be trying for a more
interesting solution. They actually link software to libraries using a
caching http filesystem. For example, an application that needs gtk2
would link to /uri/0install/www.gtk.org/gtk2/libgtk-x11-2.0.so.

Treat me like a dumb user, please. In which way is that better than
the current dependency on libgtk-x11-2.0.so.0? What problems is it
supposed to fix?

The idea is that the same library could be used on debian or Suse or
whatever. Basically it effects end users, but it doesn't really solve
any problems for Fedora developers.

Post by Andy Hanton
So it
doesn't need the funny hacks autopackage uses to detect what the user
has installed.

$ rpm --redhatprovides libgtk-x11-2.0.so.0
gtk2-2.2.1-4

It doesn't really help as much for common libraries. The idea is that
library authors can maintain their own binaries. Application authors
can be sure that the end user's system will be able to find the library
because the url is embedded in the binary.

Try rpm --redhatprovides libenchant.so.1.0.0 on a redhat 9 box.
/uri/0install/www.abisource.com/enchant/libenchant.so.1.0.0
would clearly be better in that case.

I think the idea that we can package all the dependencies that could
ever exist is unrealistic. Even if we become like debian with 10,000
packages that won't solve the cross distribution problem. You can't
tell your grandmother who runs Suse to go to the web page and download
an rpm because suse hasn't packaged all the dependencies.

Post by Andy Hanton
The user can double click the application and all the
dependencies are downloaded automatically and doing so never breaks
anything else on the system.

We do have that feature already, don't we?

No, we don't. With zero-install the user never actually uses a package
management system.

Here is how it works:
1.download an application from the author's web page
2. double click the archive to untar it
3. double-click the application and it runs

Basically the user does not need to think about finding a binary for
their specific distribution or understand dependencies or package
management. It provides Mac OS X type simplicity on Linux.

[Nicolas Mailhot]

Post by Andy Hanton

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Sean Middleditch
Given the autopackage project, RPMs and their (possible) problems may in
the future just be relegated to low-level system stuff, which is another
solution, but one not yet ready.

This one? http://autopackage.org/faq.html Doesn't look promising
in the middle of the FAQ.

They aren't the only ones working on this stuff. The zero-install
project (http://zero-install.sf.net/) seems to be trying for a more
interesting solution. They actually link software to libraries using a
caching http filesystem. For example, an application that needs gtk2
would link to /uri/0install/www.gtk.org/gtk2/libgtk-x11-2.0.so. So it
doesn't need the funny hacks autopackage uses to detect what the user
has installed. The user can double click the application and all the
dependencies are downloaded automatically and doing so never breaks
anything else on the system.

And how do you trust the result ?
RPMs at least are signed.
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20031004/961b19a6/attachment-0002.bin

[Michael Schwendt]

Post by Andy Hanton
They aren't the only ones working on this stuff. The zero-install
project (http://zero-install.sf.net/) seems to be trying for a more
interesting solution. They actually link software to libraries using a
caching http filesystem. For example, an application that needs gtk2
would link to /uri/0install/www.gtk.org/gtk2/libgtk-x11-2.0.so.

Treat me like a dumb user, please. In which way is that better than
the current dependency on libgtk-x11-2.0.so.0? What problems is it
supposed to fix?

Post by Andy Hanton
So it
doesn't need the funny hacks autopackage uses to detect what the user
has installed.

$ rpm --redhatprovides libgtk-x11-2.0.so.0
gtk2-2.2.1-4

Post by Andy Hanton
The user can double click the application and all the
dependencies are downloaded automatically and doing so never breaks
anything else on the system.

We do have that feature already, don't we?

- --
Michael, who doesn't reply to top posts and complete quotes anymore.

[Andy Hanton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Sean Middleditch
Given the autopackage project, RPMs and their (possible) problems may in
the future just be relegated to low-level system stuff, which is another
solution, but one not yet ready.

This one? http://autopackage.org/faq.html Doesn't look promising
in the middle of the FAQ.

They aren't the only ones working on this stuff. The zero-install
project (http://zero-install.sf.net/) seems to be trying for a more
interesting solution. They actually link software to libraries using a
caching http filesystem. For example, an application that needs gtk2
would link to /uri/0install/www.gtk.org/gtk2/libgtk-x11-2.0.so. So it
doesn't need the funny hacks autopackage uses to detect what the user
has installed. The user can double click the application and all the
dependencies are downloaded automatically and doing so never breaks
anything else on the system.

[Michael Schwendt]

Post by Sean Middleditch
Given the autopackage project, RPMs and their (possible) problems may in
the future just be relegated to low-level system stuff, which is another
solution, but one not yet ready.

This one? http://autopackage.org/faq.html Doesn't look promising
in the middle of the FAQ.

- --
Michael, who doesn't reply to top posts and complete quotes anymore.

[Sean Middleditch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Andy Hanton
I think that the 'Kind request: fix your packages' thread is going off
course by discussing how to fix what we have instead of what we need to
implement to make Sean's vision possible while making it possible to
support older systems easily.

What exactly is Sean's vision? It might be just me, but I don't think
that became clear in the controversy due to misunderstandings (e.g.
with regard to optional [versioned] build requirements). Maybe someone
can sum up a few major flaws in current "RPM packaging" with regard to
packagers and package users and outline the changes that are supposed
to improve the situation.

Most basic theme of my misunderstood ;-) ranting - only one package per
application, ever. Package always works, save asking for dependencies,
of which there are also only one package for each. Only in cases of
true (but hopefully avoidable) platform incompatibility should this be
broken.

Given the autopackage project, RPMs and their (possible) problems may in
the future just be relegated to low-level system stuff, which is another
solution, but one not yet ready.

Btw, if you're asking for major efforts to make the life easier for a
tiny group of users, who stick to an old distribution and who want to
install the latest and greatest software in form of prebuilt packages
nevertheless, I think that's a hopeless venture due to API and ABI
changes.
- --
Michael, who doesn't reply to top posts and complete quotes anymore.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD4DBQE/ftXv0iMVcrivHFQRAoT1AJiZmB6ltNT9oLtKiaBnlGWj5RoAAJ0VryrW
W1TGtmWBb1dTZeQXr1eZfA==
=xHlQ
-----END PGP SIGNATURE-----
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

[Alan Cox]

Post by Michael Schwendt
So, in other words I would depend on arbitrary sites to supply prebuilt
libraries rather than getting software from trusted community
repositories? Would those prebuilt libraries be of the same poor quality

Actually if the binary is supplied signed by the trusted community source
its origin isnt actually too important. Did it come froma mirror, did
it come from your ISP web cache - was it in fact several round robin sites.
The truth is you already don't know.

Post by Michael Schwendt
Isn't that what Fedora Extras tries to target? The chance for the
community to package the popular stuff and maintain it as long as
their is enough interest in it?

Yes, and to provide a place to find good stuff versus the sea of junk
that you get with arbitary indexes.

Post by Michael Schwendt
channel and neglects the source code level. Oh, and don't dare to
report a bug to the author when you run a different distribution.

The inability to define the precise system state is a big issue for business
or industrial uses. 'zero install' itself doesn't impress me, its a
special case subset of a distributed caching network file system like
AFS or DAV. Life really starts to get fun when you have a companywide
caching fs and your boot up looks something like

Set up cache
dhcp
network setup
mount companwide fs
chroot companywidefs
exec init

At that point its a lot more powerful

[Nicolas Mailhot]

Post by Alan Cox

Post by Michael Schwendt
So, in other words I would depend on arbitrary sites to supply prebuilt
libraries rather than getting software from trusted community
repositories? Would those prebuilt libraries be of the same poor quality

Actually if the binary is supplied signed by the trusted community source
its origin isnt actually too important. Did it come froma mirror, did
it come from your ISP web cache - was it in fact several round robin sites.
The truth is you already don't know.

Sure. But a srpm requires someone to document the build process.
Allowing projects to directly provide binaries means you'll soon not be
able to rebuild their stuff because their build scripts will rot in
strange and wonderful ways, depend on undocumented build environments
and anyway even if you manage to build them they will check their
signature at runtime and refuse to run if they're not signed by the
upstream project key.

Which I'm sure the gcc people will love next time they want to release a
new version since instead of pulling a RedHat they'll have to convince
every single project the system use it's time to upgrade their build
tools.

(and I case someone thinks I'm overly pessimistic - this kind of stuff
already exists. I met it. Every single aspect from the broken build
system to the key check is already used by people who thought about
auto-upload before the autoupdate project. And it's not even closed
commercial stuff but pure FOSS)
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20031005/a1dfedd8/attachment.bin

[Nicolas Mailhot]

Post by Alan Cox

Post by Michael Schwendt
So, in other words I would depend on arbitrary sites to supply prebuilt
libraries rather than getting software from trusted community
repositories? Would those prebuilt libraries be of the same poor quality

Actually if the binary is supplied signed by the trusted community source
its origin isnt actually too important. Did it come froma mirror, did
it come from your ISP web cache - was it in fact several round robin sites.
The truth is you already don't know.

Sure. But a srpm requires someone to document the build process.
Allowing projects to directly provide binaries means you'll soon not be
able to rebuild their stuff because their build scripts will rot in
strange and wonderful ways, depend on undocumented build environments
and anyway even if you manage to build them they will check their
signature at runtime and refuse to run if they're not signed by the
upstream project key.

Which I'm sure the gcc people will love next time they want to release a
new version since instead of pulling a RedHat they'll have to convince
every single project the system use it's time to upgrade their build
tools.

(and I case someone thinks I'm overly pessimistic - this kind of stuff
already exists. I met it. Every single aspect from the broken build
system to the key check is already used by people who thought about
auto-upload before the autoupdate project. And it's not even closed
commercial stuff but pure FOSS)
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20031005/a1dfedd8/attachment-0002.bin

[Alan Cox]

Post by Mike Hearn
Well, people can and do every day. The number of people who get
viruses/worms/whatever from bad installers on Windows is really low - it
almost invariably comes in through email or spyware in the apps itself.

Don't lose sight of the fact viruses and worms evolve (or are evolved)
to target the fundamental weaknesses that work. Right now they tend to
target tools like windows email because the mailer was a weak link, and
the user too. When that ceases to be the weak link you'll see techniques
change - as is happening with spyware for example. In the long term the user
may not be the weak link either - SELinux type stuff lets the administrator
shield users from many of the mistakes they would otherwise make.

Alan

[Alan Cox]

Post by Roozbeh Pournader
In short, if you don't see the license, you may *use* the software for
any purpose (which is allowed by GPL), but you may not *copy* it. If you
see it, you may do whatever it allows you to do.
I agree that certain proprietary pieces of software need EULAs, but
we're not talking about GPL, or most of Free Software licenses for that
matter.

It in part varies by country. The GPL is a copyright license not a contract
and that actually also restricts what it can do.

[Derek P. Moore]

Post by Sean Middleditch
Seriously, this is nothing but paranoid rambling. I'm not going to
waste time trying to debate with a raving zealot - discussion over.

Just to be fair: From what I've read of your posts on this list, you sound
like just as much of a raving zealot (if not more so). Discussion over.

Okay, I'm done now,

Derek

[Andy Hanton]

I think that the 'Kind request: fix your packages' thread is going off
course by discussing how to fix what we have instead of what we need to
implement to make Sean's vision possible while making it possible to
support older systems easily.

I think that we need development tools that work more like the tools on
Mac OS classic. Macs didn't actually have libraries so they got some
very cool features for free. You can actually build an application on
Mac OS 9 and run it on Mac OS 1. You don't need a chroot environment or
any other fancy setup. All you need to do is stick to the API that Mac
OS 1.0 supported and it just works. The bad part was that if you used a
function that wasn't supported the application would crash at runtime.
Because Linux has library versioning it should be able to get the
flexibility of compiling easily for older systems while knowing for sure
that the binary will work on the old systems.

On Linux the dependencies of a library or binary get inflated by the
system. For example all binaries built on Redhat 9 depend on libc 2.3
but they usually don't depend on any new APIs introduced in 2.3. If
each developer compiled against the minimal library versions necessary
then the resulting binaries would be nearly universal when used with an
rpm repository. For example it would be possible to compile abiword 2.0
with gnome support on RedHat 9 or Fedora 1.0 and have the same binary
run on redhat 7.3. The package manager would automatically the gnome2
platform libraries from the Fedora 1.0 release and install them.
Although it would require more disk space, end users would probably
prefer to have only one Linux/i386 binary just like there is only one
Windows binary.

I am not a compiler guru, so I don't know how we get there. It might be
a good idea to compile the core of the OS inside a LSB chroot. Another
possibility might be using pkg-config to request a specific minor
version of a library. It might look something like gcc -o foo foo.c
`pkg-config --cflags --libs gtk+-2.0:2.0 libgnome-2.0:2.0 libc-2:2.2`

The library would implement this by specifying a preprocessor macro to
set with the requested library version number. Then it would add ifdefs
to the headers so that only the symbols available in the particular
version would be available. It would be cool to support aliases for
different versions. For example gtk+-2.0:LSB_2_0 might be equivalent to
gtk+-2.0:2.0.

There might be some extra linker magic necessary, but since RedHat
employs lots of compiler tool chain experts I don't think it would be
impossible. It might be possible to reuse whatever tools the LSB
project is using to generate stub libraries for each minor version of
every library.

To make the automatic dependency fetching work right the repository
should probably provide a mapping between library names and package
names. I would think that it would be easy to write a script that would
extract this information from all the rpms in a yum or apt-get
repository and write it to a file with a standardized name and
location.

In this setup a few programs that can optionally use a feature that a
newer distribution has would need to be compiled more than once.
Packagers wouldn't need to figure out the dependency information because
the developer would have already done that work. Unfortunately, if a
single binaries could be built to run on any recent Linux system, then
the author of the code would probably package the binary themselves.
Some Fedora developers would need to find a new way to spend their free
time. ;-)

[Ulrich Drepper]

Post by Andy Hanton
On Linux the dependencies of a library or binary get inflated by the
system. For example all binaries built on Redhat 9 depend on libc 2.3
but they usually don't depend on any new APIs introduced in 2.3.

That's wrong. The versioning mechanism always picks the minimum
required versions. There is no automatic inflation. The fact that most
apps linked against glibc 2.3 will also require GLIBC_2.3 is that some
fundamental interfaces changed.

Post by Andy Hanton
It might look something like gcc -o foo foo.c
`pkg-config --cflags --libs gtk+-2.0:2.0 libgnome-2.0:2.0 libc-2:2.2`

That's something I never want to see. Compiling against old headers and
linking with old libraries always means a) more bugs and b) less optimal
results. For instance, compile some code using conditional variables
with old headers and new headers, and compare the resulting performance
and memory consumption (and maybe even stability).

If I have the possibility to have better binaries I am not willing to
give this up just because some people clinch to their old installations
and demand equal treatment when it comes to package updates.

[Michael Schwendt]

Post by Andy Hanton
I think that the 'Kind request: fix your packages' thread is going off
course by discussing how to fix what we have instead of what we need to
implement to make Sean's vision possible while making it possible to
support older systems easily.

What exactly is Sean's vision? It might be just me, but I don't think
that became clear in the controversy due to misunderstandings (e.g.
with regard to optional [versioned] build requirements). Maybe someone
can sum up a few major flaws in current "RPM packaging" with regard to
packagers and package users and outline the changes that are supposed
to improve the situation.

Btw, if you're asking for major efforts to make the life easier for a
tiny group of users, who stick to an old distribution and who want to
install the latest and greatest software in form of prebuilt packages
nevertheless, I think that's a hopeless venture due to API and ABI
changes.

- --
Michael, who doesn't reply to top posts and complete quotes anymore.

[Alan Cox]

Post by Michael Schwendt
So, in other words I would depend on arbitrary sites to supply prebuilt
libraries rather than getting software from trusted community
repositories? Would those prebuilt libraries be of the same poor quality

Actually if the binary is supplied signed by the trusted community source
its origin isnt actually too important. Did it come froma mirror, did
it come from your ISP web cache - was it in fact several round robin sites.
The truth is you already don't know.

Post by Michael Schwendt
Isn't that what Fedora Extras tries to target? The chance for the
community to package the popular stuff and maintain it as long as
their is enough interest in it?

Yes, and to provide a place to find good stuff versus the sea of junk
that you get with arbitary indexes.

Post by Michael Schwendt
channel and neglects the source code level. Oh, and don't dare to
report a bug to the author when you run a different distribution.

The inability to define the precise system state is a big issue for business
or industrial uses. 'zero install' itself doesn't impress me, its a
special case subset of a distributed caching network file system like
AFS or DAV. Life really starts to get fun when you have a companywide
caching fs and your boot up looks something like

Set up cache
dhcp
network setup
mount companwide fs
chroot companywidefs
exec init

At that point its a lot more powerful

[Alan Cox]

Post by Mike Hearn
Well, people can and do every day. The number of people who get
viruses/worms/whatever from bad installers on Windows is really low - it
almost invariably comes in through email or spyware in the apps itself.

Don't lose sight of the fact viruses and worms evolve (or are evolved)
to target the fundamental weaknesses that work. Right now they tend to
target tools like windows email because the mailer was a weak link, and
the user too. When that ceases to be the weak link you'll see techniques
change - as is happening with spyware for example. In the long term the user
may not be the weak link either - SELinux type stuff lets the administrator
shield users from many of the mistakes they would otherwise make.

Alan

[Alan Cox]

Post by Roozbeh Pournader
In short, if you don't see the license, you may *use* the software for
any purpose (which is allowed by GPL), but you may not *copy* it. If you
see it, you may do whatever it allows you to do.
I agree that certain proprietary pieces of software need EULAs, but
we're not talking about GPL, or most of Free Software licenses for that
matter.

It in part varies by country. The GPL is a copyright license not a contract
and that actually also restricts what it can do.

[Derek P. Moore]

Post by Sean Middleditch
Seriously, this is nothing but paranoid rambling. I'm not going to
waste time trying to debate with a raving zealot - discussion over.

Just to be fair: From what I've read of your posts on this list, you sound
like just as much of a raving zealot (if not more so). Discussion over.

Okay, I'm done now,

Derek