2:25 a.m.
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. ;-)
--
Andy Hanton <andyhanton(a)comcast.net>
2:48 a.m.
Andy Hanton wrote:
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.
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.
--
--------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
9:15 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 04 Oct 2003 03:25:09 -0400, Andy Hanton wrote:
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD4DBQE/ftXv0iMVcrivHFQRAoT1AJiZmB6ltNT9oLtKiaBnlGWj5RoAAJ0VryrW
W1TGtmWBb1dTZeQXr1eZfA==
=xHlQ
-----END PGP SIGNATURE-----
10:51 a.m.
On Sat, 2003-10-04 at 10:15, Michael Schwendt wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 04 Oct 2003 03:25:09 -0400, Andy Hanton wrote:
> 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.
--
Sean Middleditch <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.
-----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(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
12:20 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 04 Oct 2003 11:51:34 -0400, Sean Middleditch wrote:
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/fwFV0iMVcrivHFQRApoQAJwO0z1i/1KhKCxsNQj60QvVOyPNeQCfWz4p
ZwEYSD52z9HxNs7K07J04Ks=
=8IFF
-----END PGP SIGNATURE-----
12:58 p.m.
On Sat, 2003-10-04 at 13:20, Michael Schwendt wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 04 Oct 2003 11:51:34 -0400, Sean Middleditch wrote:
> 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.
--
Andy Hanton <andyhanton(a)comcast.net>
1:02 p.m.
Le sam 04/10/2003 à 19:58, Andy Hanton a écrit :
On Sat, 2003-10-04 at 13:20, Michael Schwendt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sat, 04 Oct 2003 11:51:34 -0400, Sean Middleditch wrote:
>
> > 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
1:18 p.m.
On Sat, 2003-10-04 at 14:02, Nicolas Mailhot wrote:
Le sam 04/10/2003 à 19:58, Andy Hanton a écrit :
> On Sat, 2003-10-04 at 13:20, Michael Schwendt wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Sat, 04 Oct 2003 11:51:34 -0400, Sean Middleditch wrote:
> >
> > > 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 <andyhanton(a)comcast.net>
1:39 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 04 Oct 2003 13:58:32 -0400, Andy Hanton wrote:
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?
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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/fxPo0iMVcrivHFQRAvM1AJ91hI0g9q5KcbacfWSQ9kvFhFpRiACeIjKC
szGEAMw6GNAzEY5nx1jvZH0=
=KCEZ
-----END PGP SIGNATURE-----
2:10 p.m.
On Sat, 2003-10-04 at 14:39, Michael Schwendt wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 04 Oct 2003 13:58:32 -0400, Andy Hanton wrote:
> 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.
> 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.
> 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.
--
Andy Hanton <andyhanton(a)comcast.net>
3:29 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 04 Oct 2003 15:10:35 -0400, Andy Hanton wrote:
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.
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.
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.
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?
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?
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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/fy2n0iMVcrivHFQRApccAJ9rcYeRJspZfkbvqEXnU+vf1Gg7eQCeOC8s
VW4IsE0js3KqKQX3BdrZ0/g=
=kNEA
-----END PGP SIGNATURE-----
4:49 p.m.
On Sat, 2003-10-04 at 16:29, Michael Schwendt wrote:
> 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
6:51 p.m.
Le sam 04/10/2003 à 23:49, Havoc Pennington a écrit :
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
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
8:04 p.m.
On Sat, 2003-10-04 at 19:51, Nicolas Mailhot wrote:
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
2:39 a.m.
Le dim 05/10/2003 à 03:04, Havoc Pennington a écrit :
On Sat, 2003-10-04 at 19:51, Nicolas Mailhot wrote:
> 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
5:22 p.m.
On Sat, 2003-10-04 at 22:49, Havoc Pennington wrote:
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.
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.
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.
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
Too large for dialup users I think :(
- 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.
- 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).
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
6:14 p.m.
On Sat, 2003-10-11 at 18:22, Mike Hearn wrote:
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.
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.
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.
> 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).
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.
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.
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.
> 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).
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.
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.
> 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
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...)
> - 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! ;-)
> - 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.
> 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.).
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.
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. ;-)
thanks -mike
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Sean Middleditch <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.
10:56 a.m.
On Sun, 2003-10-12 at 00:14, Sean Middleditch wrote:
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.
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.
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.
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).
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.
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
11:51 a.m.
Le dim 12/10/2003 à 17:56, Mike Hearn a écrit :
On Sun, 2003-10-12 at 00:14, Sean Middleditch wrote:
> 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.
> 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 ?
> 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.
> 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
4:05 p.m.
(snip)
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...
4:29 p.m.
Le dim 12/10/2003 à 23:05, Julien Olivier a écrit :
(snip)
> 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
3:35 a.m.
On Sun, 2003-10-12 at 17:51, Nicolas Mailhot wrote:
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.
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)..
, change-install-location dialogs,
Don't have one, if you want to change the prefix you have to use the
command line...
here-is-the-disc-size-I-need-please-check windows,
... automatic
you-think-I'm-installed-but-check-my-20-pages-readme popups,
... not done
don't-bother-with-permissions-and-run-everything-as-admin
... can choose (user vs root)
(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.
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.
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
9:54 a.m.
On Sun, 2003-10-12 at 12:51, Nicolas Mailhot wrote:
Le dim 12/10/2003 à 17:56, Mike Hearn a écrit :
> On Sun, 2003-10-12 at 00:14, Sean Middleditch wrote:
> > 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.
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.
(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.
Anyway I don't know why I bother - just do your thing and I'll watch HiG
people shot it down.
> > 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.
> > 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.
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.
> > 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.
Cheers,
--
Sean Middleditch <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.
10:11 a.m.
On Mon, 2003-10-13 at 18:24, Sean Middleditch wrote:
(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
11:54 a.m.
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.
11:01 a.m.
Le lun 13/10/2003 à 16:54, Sean Middleditch a écrit :
On Sun, 2003-10-12 at 12:51, Nicolas Mailhot wrote:
>
> (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?
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.
. 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.
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
12:12 p.m.
On Mon, 2003-10-13 at 12:01, Nicolas Mailhot wrote:
<snip tons of yammering>
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.
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 <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.
3:53 p.m.
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
6:40 p.m.
Le dim 12/10/2003 à 00:22, Mike Hearn a écrit :
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")
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
8:54 a.m.
On Sun, 2003-10-12 at 00:40, Nicolas Mailhot wrote:
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.
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.
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.
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.
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.
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.
And while there is room for gfx effects the core engine must be
CLI/GUI
independent.
Sure. It already is.
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
10:12 a.m.
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
6:40 p.m.
On Sat, 2003-10-11 at 18:22, Mike Hearn wrote:
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.
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
8:07 a.m.
On Sun, 2003-10-12 at 00:40, Havoc Pennington wrote:
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.
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.
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.
Right - I wasn't really meaning this, but parallel installability is
clearly an educational issue.
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
5:58 p.m.
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.
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.
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
7:03 p.m.
Le dim 05/10/2003 à 00:58, Alan Cox a écrit :
> 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
7494
days inactive
7503
days old
34 comments
11 participants
participants (11)
-
Alan Cox -
Andy Hanton -
Derek P. Moore -
Havoc Pennington -
Julien Olivier -
Michael Schwendt -
Mike Hearn -
Nicolas Mailhot -
Roozbeh Pournader -
Sean Middleditch -
Ulrich Drepper