Mailing List Archive: Linux: Kernel

package managers [was: FatELF patches...]

Index | Next | Previous | View Threaded

mikulas at artax

Nov 4, 2009, 8:40 AM

Post #1 of 24 (102 views)
Permalink

package managers [was: FatELF patches...]

> Package managers are a _fantastic_ invention. They are a killer feature
> over other operating systems, including ones people pay way too much money
> to use.

No, package managers are evil feature that suppresses third party software
and kills Linux success on desktop.

Package managers are super-easy to use --- but only as long as the package
exists. No developer can make a package for all versions of all
distributions. No distribution can make a package for all versions of all
Linux software. So, inevitably, there are holes in the
[distribution X software] matrix, where the package isn't available.

- With Windows installers (next - next - next - finish), even a
technically unskilled person can select which version of a given
software he wants to use. If the software doesn't work, he can simply
uninstall it and try another version.

- With Linux package managers, the user is stuck with the software and
version shipped by the distribution. If he wants to install anything
newer or older, it turns into black magic and the typical desktop user
(non-hacker) can't do it.

- For non-technical user who can't compile, getting newer software for
Linux means reinstalling the whole distribution to a newer version. So,
"upgrade one program" translates into "upgrade all programs" (that will
bring many changes that the user didn't want and new bugs)

Let me say that instead of making a single binary for multiple
architectures, you should concentrate on developing a method to make a
single binary that works on all installations on one architecture :)

Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Valdis.Kletnieks at vt

Nov 4, 2009, 9:36 AM

Post #2 of 24 (100 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

On Wed, 04 Nov 2009 17:40:02 +0100, Mikulas Patocka said:

> - With Windows installers (next - next - next - finish), even a
> technically unskilled person can select which version of a given
> software he wants to use. If the software doesn't work, he can simply
> uninstall it and try another version.

Theoretically. There's this little detail called "DLL Hell" though...

(And one could reasonably argue that it requires *more* clue to resolve a
DLL Hell issue than it does to fix the equivalent dependency issue on Linux...)

tweek at tweek

Nov 4, 2009, 9:48 AM

Post #3 of 24 (100 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

On Wednesday 04 November 2009 18:25:07 Mikulas Patocka wrote:
> On Wed, 4 Nov 2009, Alan Cox wrote:
> > > - With Linux package managers, the user is stuck with the software and
> > > version shipped by the distribution. If he wants to install anything
> > > newer or older, it turns into black magic and the typical desktop
> > > user (non-hacker) can't do it.
> >
> > In the rpm/yumworld that would be "yum downgrade" and "yum upgrade" for
> > packages or whatever button on whatever gui wrapper you happen to have.
>
> And what if there isn't a package? Upgrade option doesn't solve the need
> for [ distributions X software ] matrix of packages.
>
> > And of course yum supports third party repositories so you can also deal
> > with the updating problem which Windows tends not to do well for third
> > party software.
>
> A practical example --- when I wanted to get Wine on RHEL 5, all I found
> was a package for 1.0.1. Nothing newer.
>
> I managed to compile the current version of Wine (it wasn't straghtforward
> and took few days to solve all the problems) and it ran the program I
> wanted. But I can imagine that a typical business user or home gamer will
> just say "that Linux sux".
>
> You can say that I should delete RHEL-5 and install Fedora, but that is
> just that "upgrade one program" => "upgrade all programs" problem.

Have you ever tried upgrading Windows because some program is incompatible
with the current installation? ... That is indeed an 'upgrade all' procedure
... _If_ you're lucky enough to be able to reinstall your software.

Being able to upgrade at least Debian -- and others as well -- without the
need to attend the computer is IMHO one of Linux' biggest wins.

BTW: Wine has, like many others, the newest version of their software
prepackaged for RHEL 4 & 5 among others at their site:
http://www.winehq.org/download/

If all else fail the developers could go for statically compiled binaries in
an executable tarball, which then handles the installation to /usr/local

-Martin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

mikulas at artax

Nov 4, 2009, 10:46 AM

Post #4 of 24 (93 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

> > You can say that I should delete RHEL-5 and install Fedora, but that is
> > just that "upgrade one program" => "upgrade all programs" problem.
>
> Have you ever tried upgrading Windows because some program is incompatible
> with the current installation? ... That is indeed an 'upgrade all' procedure
> ... _If_ you're lucky enough to be able to reinstall your software.

Some Windows programs force upgrade, but not in yearly cycles, like Linux
programs. Majority of programs still work on XP shipped in 2001.

> Being able to upgrade at least Debian -- and others as well -- without the
> need to attend the computer is IMHO one of Linux' biggest wins.

When I did it (from Etch to Lenny), two programs that I have compiled
manually ("vim" and "links") stopped working because Etch and Lenny have
binary-incompatible libgpm.

If some library cannot keep binary compatibility, it should be linked
staticaly, dynamic version shouldn't even exists on the system --- so that
no one can create incompatible binaries.

> BTW: Wine has, like many others, the newest version of their software
> prepackaged for RHEL 4 & 5 among others at their site:
> http://www.winehq.org/download/

This is exactly the link that I followed and the last version for "RHEL 5"
is "wine-1.0.1-1.el5.i386.rpm".

> If all else fail the developers could go for statically compiled binaries in
> an executable tarball, which then handles the installation to /usr/local
>
> -Martin

Static linking doesn't work for any program that needs plug-ins (i.e.
you'd have one glibc statically linked into the program and another glibc
dynamically linked with a plug-in and these two glibcs will beat each
other).

---

I mean this --- the distributions should agree on a common set of
libraries and their versions (call this for example "Linux-2010
standard"). This standard should include libraries that are used
frequently, that have low occurence of bugs and security holes and that
have never had an ABI change.

A distribution that claims compatibility with the standard must ship
libraries that are compatible with the libraries in the standard (not
necessarily the same version, it may ship higher version for security or
so).

Software developers that claim compatibility with the standard will link
standard libraries dynamically and must use static linking for all
libraries not included in the standard. Or they can use dynamic linking
and ship the non-standard library with the application in its private
directory (so that nothing but that application links against it).

Then, software developers could make a release for "Linux-2010" and it
would work on all distributions.

You'd no longer need a [ distributions X programs ] matrix of binaries
and packages.

In five years, you could revisit the standard to "Linux-2015" with newer
versions of libraries and force the users only to five-years upgrades, not
yearly upgrades as it is now. "Linux-2015" should be backward compatible
with "Linux-2010", so an user doing upgrade would only need to overwrite
his /lib and /usr/lib, he woudn't even need to change the programs.

Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

alan at lxorguk

Nov 4, 2009, 11:46 AM

Post #5 of 24 (93 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

> > BTW: Wine has, like many others, the newest version of their software
> > prepackaged for RHEL 4 & 5 among others at their site:
> > http://www.winehq.org/download/
>
> This is exactly the link that I followed and the last version for "RHEL 5"
> is "wine-1.0.1-1.el5.i386.rpm".

So you have a supplier issue. A random windows user wouldnt cope with
that either. You try installing a Windows Vista only app on XP ;)

> A distribution that claims compatibility with the standard must ship
> libraries that are compatible with the libraries in the standard (not
> necessarily the same version, it may ship higher version for security or
> so).

Welcome to the Linux Standard Base. It's been done and it exists.
Generally speaking open source projects don't seem to care to build to it
but prefer to build to each distro.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Valdis.Kletnieks at vt

Nov 4, 2009, 12:02 PM

Post #6 of 24 (93 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

On Wed, 04 Nov 2009 19:46:44 +0100, Mikulas Patocka said:

> When I did it (from Etch to Lenny), two programs that I have compiled
> manually ("vim" and "links") stopped working because Etch and Lenny have
> binary-incompatible libgpm.
>
> If some library cannot keep binary compatibility, it should be linked
> staticaly, dynamic version shouldn't even exists on the system --- so that
> no one can create incompatible binaries.

No, all they need to do is bump the .so version number.

I have a creeping-horror binary that was linked against an older audit shared
library. Fedora shipped a newer one. The fix? Upgraded the lib, then
snarfed the old version off backups (you *do* make backups, right?)

% ls -l /lib64/libaudit*
lrwxrwxrwx 1 root root 17 2009-09-26 16:47 /lib64/libaudit.so.0 -> libaudit.so.0.0.0
-rwxr-xr-x 1 root root 107304 2009-04-03 15:47 /lib64/libaudit.so.0.0.0
lrwxrwxrwx 1 root root 17 2009-09-30 11:09 /lib64/libaudit.so.1 -> libaudit.so.1.0.0
-rwxr-xr-x 1 root root 103208 2009-09-28 16:00 /lib64/libaudit.so.1.0.0

They happily co-exist. My creeping horror references libaudit.so.0, the rest
of the system references libaudit.so.1 and everybody is happy.

And some distros even pre-package the previous set of libraries for some packages:

% yum list 'compat*'
Loaded plugins: dellsysidplugin2, downloadonly, refresh-packagekit, refresh-updatesd
Installed Packages
compat-expat1.x86_64 1.95.8-6 @rawhide
compat-readline5.i686 5.2-17.fc12 @rawhide
compat-readline5.x86_64 5.2-17.fc12 @rawhide
Available Packages
compat-db.x86_64 4.6.21-5.fc10 rawhide
compat-db45.x86_64 4.5.20-5.fc10 rawhide
compat-db46.x86_64 4.6.21-5.fc10 rawhide
compat-erlang.x86_64 R10B-15.12.fc12 rawhide
compat-expat1.i686 1.95.8-6 rawhide
compat-flex.x86_64 2.5.4a-6.fc12 rawhide
compat-gcc-34.x86_64 3.4.6-18 rawhide
compat-gcc-34-c++.x86_64 3.4.6-18 rawhide
compat-gcc-34-g77.x86_64 3.4.6-18 rawhide
compat-guichan05.i686 0.5.0-10.fc12 rawhide
compat-guichan05.x86_64 0.5.0-10.fc12 rawhide
compat-guichan05-devel.i686 0.5.0-10.fc12 rawhide
compat-guichan05-devel.x86_64 0.5.0-10.fc12 rawhide
compat-libf2c-34.i686 3.4.6-18 rawhide
compat-libf2c-34.x86_64 3.4.6-18 rawhide
compat-libgda.i686 3.1.2-3.fc12 rawhide
compat-libgda.x86_64 3.1.2-3.fc12 rawhide
compat-libgda-devel.i686 3.1.2-3.fc12 rawhide
compat-libgda-devel.x86_64 3.1.2-3.fc12 rawhide
compat-libgda-sqlite.x86_64 3.1.2-3.fc12 rawhide
compat-libgda-sqlite-devel.i686 3.1.2-3.fc12 rawhide
compat-libgda-sqlite-devel.x86_64 3.1.2-3.fc12 rawhide
compat-libgdamm.i686 3.0.1-4.fc12 rawhide
compat-libgdamm.x86_64 3.0.1-4.fc12 rawhide
compat-libgdamm-devel.i686 3.0.1-4.fc12 rawhide
compat-libgdamm-devel.x86_64 3.0.1-4.fc12 rawhide
compat-libgfortran-41.i686 4.1.2-38 rawhide
compat-libgfortran-41.x86_64 4.1.2-38 rawhide
compat-libstdc++-296.i686 2.96-143 rawhide
compat-libstdc++-33.i686 3.2.3-68 rawhide
compat-libstdc++-33.x86_64 3.2.3-68 rawhide
compat-readline5-devel.i686 5.2-17.fc12 rawhide
compat-readline5-devel.x86_64 5.2-17.fc12 rawhide
compat-readline5-static.x86_64 5.2-17.fc12 rawhide

mikulas at artax

Nov 4, 2009, 12:04 PM

Post #7 of 24 (93 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

> Welcome to the Linux Standard Base. It's been done and it exists.
> Generally speaking open source projects don't seem to care to build to it
> but prefer to build to each distro.

Why?

Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

mikulas at artax

Nov 4, 2009, 12:08 PM

Post #8 of 24 (93 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

On Wed, 4 Nov 2009, Valdis.Kletnieks[at]vt.edu wrote:

> On Wed, 04 Nov 2009 19:46:44 +0100, Mikulas Patocka said:
>
> > When I did it (from Etch to Lenny), two programs that I have compiled
> > manually ("vim" and "links") stopped working because Etch and Lenny have
> > binary-incompatible libgpm.
> >
> > If some library cannot keep binary compatibility, it should be linked
> > staticaly, dynamic version shouldn't even exists on the system --- so that
> > no one can create incompatible binaries.
>
> No, all they need to do is bump the .so version number.

That's what Debian did. Obviously, I can extract the old library from the
old package. But non-technical desktop user can't.

Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

david at lang

Nov 4, 2009, 12:27 PM

Post #9 of 24 (90 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

On Wed, 4 Nov 2009, Mikulas Patocka wrote:

>> Welcome to the Linux Standard Base. It's been done and it exists.
>> Generally speaking open source projects don't seem to care to build to it
>> but prefer to build to each distro.
>
> Why?

also note that commercial products generally don't use LSB either.

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

icculus at icculus

Nov 4, 2009, 12:28 PM

Post #10 of 24 (90 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

> No, package managers are evil feature that suppresses third party software
> and kills Linux success on desktop.

There are merits and flaws, of course, but I'm going to take this moment
to encourage everyone to not descend into a conversation about this on
linux-kernel. My point with FatELF wasn't to start a conversation about
package management at all, let alone on this mailing list.

--ryan.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Valdis.Kletnieks at vt

Nov 4, 2009, 12:41 PM

Post #11 of 24 (90 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

On Wed, 04 Nov 2009 21:08:01 +0100, Mikulas Patocka said:
> On Wed, 4 Nov 2009, Valdis.Kletnieks[at]vt.edu wrote:
>
> > On Wed, 04 Nov 2009 19:46:44 +0100, Mikulas Patocka said:
> >
> > > When I did it (from Etch to Lenny), two programs that I have compiled
> > > manually ("vim" and "links") stopped working because Etch and Lenny have
> > > binary-incompatible libgpm.
> > >
> > > If some library cannot keep binary compatibility, it should be linked
> > > staticaly, dynamic version shouldn't even exists on the system --- so tha
t
> > > no one can create incompatible binaries.
> >
> > No, all they need to do is bump the .so version number.
>
> That's what Debian did. Obviously, I can extract the old library from the
> old package. But non-technical desktop user can't.

But the non-technical user probably wouldn't have hand-compiled vim and links
either, so how would they get into that situation?

mikulas at artax

Nov 4, 2009, 1:11 PM

Post #12 of 24 (90 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

> > > No, all they need to do is bump the .so version number.
> >
> > That's what Debian did. Obviously, I can extract the old library from the
> > old package. But non-technical desktop user can't.
>
> But the non-technical user probably wouldn't have hand-compiled vim and links
> either, so how would they get into that situation?

Non-technical users won't hand-compile but they want third party software
that doesn't come from the distribution. And package management system
hates it. Truly. It is written with the assumption that everything
installed is registered in the package database.

Another example: I needed new binutils because it had some bugs fixed over
standard Debian binutils. So I downloaded .tar.gz from ftp.gnu.org,
compiled it, then issued a command to remove the old package, passed it a
flag to ignore broken dependencies and then typed make install to install
new binaries. --- guess what --- on any further invocation of dselect it
complained that there are broken dependencies (the compiler needs
binutils) and tried to install the old binutils package!

Why is the package management so stupid? Why can't it check $PATH for "ld"
and if there is one, don't try to install it again?

After few hours, I resolved the issue by creating an empty "binutils"
package and stuffing it into the database.

Now, if I were not a programmer ... if I were an artist who needs the
latest version of graphics software, if I were a musican who needs the
latest version of audio software, if I were a gamer who needs the latest
version of wine ... I'd be f'cked up. That's why I think that package
management is an evil feature hurts desktop users. As a technical user, I
somehow solve these quirks and install what I want, as a non-technical
user, I wouldn't have a chance.

Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

kevin.granade at gmail

Nov 4, 2009, 1:32 PM

Post #13 of 24 (90 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

On Wed, Nov 4, 2009 at 3:11 PM, Mikulas Patocka
<mikulas[at]artax.karlin.mff.cuni.cz> wrote:
>> > > No, all they need to do is bump the .so version number.
>> >
>> > That's what Debian did. Obviously, I can extract the old library from the
>> > old package. But non-technical desktop user can't.
>>
>> But the non-technical user probably wouldn't have hand-compiled vim and links
>> either, so how would they get into that situation?
>
> Non-technical users won't hand-compile but they want third party software
> that doesn't come from the distribution. And package management system
> hates it. Truly. It is written with the assumption that everything
> installed is registered in the package database.
>
> Another example: I needed new binutils because it had some bugs fixed over
> standard Debian binutils. So I downloaded .tar.gz from ftp.gnu.org,
> compiled it, then issued a command to remove the old package, passed it a
> flag to ignore broken dependencies and then typed make install to install
> new binaries. --- guess what --- on any further invocation of dselect it
> complained that there are broken dependencies (the compiler needs
> binutils) and tried to install the old binutils package!
>
> Why is the package management so stupid? Why can't it check $PATH for "ld"
> and if there is one, don't try to install it again?
>
> After few hours, I resolved the issue by creating an empty "binutils"
> package and stuffing it into the database.
>
> Now, if I were not a programmer ... if I were an artist who needs the
> latest version of graphics software, if I were a musican who needs the
> latest version of audio software, if I were a gamer who needs the latest
> version of wine ... I'd be f'cked up. That's why I think that package
> management is an evil feature hurts desktop users. As a technical user, I
> somehow solve these quirks and install what I want, as a non-technical
> user, I wouldn't have a chance.

I think the important question here is what is is exactly that the
package manager *did* to break the app you are talking about? Did it
keep the person who released the software from including the required
libraries? Did it keep them from compiling it statically? Did it
interfere with them building against LSB? No, it didn't do any of
these things, all it did was not be as up to date as you wanted it to
be, and not magically be able to discern that you've replaced one of
the most core packages in the system (which, by the way is most
definitely not something that %99.999 of users are going to try)

I'm of the opinion that the package manager IS the "killer app" for
Linux, and the main thing that makes it usable at all for the
less-technical users you seem to think it is driving off. Is it
perfect? of course not, particularly if you want to strike off on
your own and install things manually. But the pain you're running
into when you do that isn't caused by the package manager, it's what
is left if you take the package manager away.

>
> Mikulas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo[at]vger.kernel.org
> More majordomo info at �http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at �http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

mikulas at artax

Nov 4, 2009, 2:05 PM

Post #14 of 24 (90 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

> I think the important question here is what is is exactly that the
> package manager *did* to break the app you are talking about?

It interferred with my will to install the version of the software that I
want.

> be, and not magically be able to discern that you've replaced one of
> the most core packages in the system (which, by the way is most
> definitely not something that %99.999 of users are going to try)

If you need new 3D driver because of better gaming performance ... if you
need new lame because it encodes mp3 better ... if you need new libsane
because it supports the new scanner that you have ... you are going to
face the same problems like me when I needed new binutils. But the big
problem is that persons needing these things usually don't have enough
skills to install the software on their own and then fight with the
package management system.

On Windows, the user can just download the EXE, run it, click
next-next-next-finish and have it installed. There is no package
management that would try to overwrite what you have just installed.

Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

mletyns at gmail

Nov 4, 2009, 2:19 PM

Post #15 of 24 (90 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

2009/11/4 Mikulas Patocka <mikulas[at]artax.karlin.mff.cuni.cz>:
>
> It interferred with my will to install the version of the software that I
> want.

You did it in very idiotic way...

>
> If you need new 3D driver because of better gaming performance ... if you
> need new lame because it encodes mp3 better ... if you need new libsane
> because it supports the new scanner that you have ... you are going to
> face the same problems like me when I needed new binutils. But the big
> problem is that persons needing these things usually don't have enough
> skills to install the software on their own and then fight with the
> package management system.

You use a rolling distro or add a proper repository with newer
packages. Nope, I never faced such problems, but I'm smart enough to
install software in a proper way. I consider package managers being
killer features you can only dream about being windows user.

> On Windows, the user can just download the EXE, run it, click
> next-next-next-finish and have it installed. There is no package
> management that would try to overwrite what you have just installed.

On windows, user cannot upgrade entire system in such easy way (he
can't even install a thing in such easy way) as Linux distros let you
to do so. I recommend you to stop writing such bull. It was you, who
wanted to overwrite what you have just installed. Stop trolling.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

david at lang

Nov 4, 2009, 2:28 PM

Post #16 of 24 (86 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

On Wed, 4 Nov 2009, Marcin Letyns wrote:

> 2009/11/4 Mikulas Patocka <mikulas[at]artax.karlin.mff.cuni.cz>:
>>
>> It interferred with my will to install the version of the software that I
>> want.
>
> You did it in very idiotic way...

he's not alone in trying to do this

package managers are wonderful when they work and the package you need is
in there. they are a pain to be worked around when the package you want
isn't in the repository. if the package just isn't in there it's not a big
deal to deal with it, the problem comes when you want a package that's
different from one that _is_ in the repository.

how easy or hard it is to work around the package manager depends in large
part on if you know the tricks for that particular package manager.

and no, a rolling update distro doesn't solve the problem. one issue is
that trying to upgrade one package may trigger a pull of many others, but
the bigger problem shows up when you need to compile a package with
different options and really need to tell the package manager "hands off,
I'll do this manually". They all have a way to do this, but most of the
time it means learning enough about how packages work on that system to be
able to create a dummy package to trick the package manager.

I think both sides here are overstating it.

package managers are neither the solution to all possible problems, nor
are they the root of all evil.

David Lang

>>
>> If you need new 3D driver because of better gaming performance ... if you
>> need new lame because it encodes mp3 better ... if you need new libsane
>> because it supports the new scanner that you have ... you are going to
>> face the same problems like me when I needed new binutils. But the big
>> problem is that persons needing these things usually don't have enough
>> skills to install the software on their own and then fight with the
>> package management system.
>
> You use a rolling distro or add a proper repository with newer
> packages. Nope, I never faced such problems, but I'm smart enough to
> install software in a proper way. I consider package managers being
> killer features you can only dream about being windows user.
>
>> On Windows, the user can just download the EXE, run it, click
>> next-next-next-finish and have it installed. There is no package
>> management that would try to overwrite what you have just installed.
>
> On windows, user cannot upgrade entire system in such easy way (he
> can't even install a thing in such easy way) as Linux distros let you
> to do so. I recommend you to stop writing such bull. It was you, who
> wanted to overwrite what you have just installed. Stop trolling.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo[at]vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

tweek at tweek

Nov 4, 2009, 2:43 PM

Post #17 of 24 (86 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

On Wednesday 04 November 2009 23:05:17 Mikulas Patocka wrote:
> > I think the important question here is what is is exactly that the
> > package manager *did* to break the app you are talking about?
>
> It interferred with my will to install the version of the software that I
> want.
>
> > be, and not magically be able to discern that you've replaced one of
> > the most core packages in the system (which, by the way is most
> > definitely not something that %99.999 of users are going to try)
>
> If you need new 3D driver because of better gaming performance ... if you
> need new lame because it encodes mp3 better ... if you need new libsane
> because it supports the new scanner that you have ... you are going to
> face the same problems like me when I needed new binutils. But the big
> problem is that persons needing these things usually don't have enough
> skills to install the software on their own and then fight with the
> package management system.
>
> On Windows, the user can just download the EXE, run it, click
> next-next-next-finish and have it installed. There is no package
> management that would try to overwrite what you have just installed.

Exactly. There is nothing to help you from installing incompatible software
(ie libraries). If your next-next-next-finish installer overwrites a crucial
library, you're screwed. The package manager, on the other hand, knows about
all your installed files and their dependencies and conflicts.

If you really want to fiddle with your own software versions, dependencies, and
conflicts, then the equivs package is a perfect helper, which lets you create
virtual Debian packages (empty packages with dependencies and such).
For instance, I compile mplayer directly from the subversion repository -
however I still have some packages installed, which depends on mplayer. Here
the virtual mplayer package keeps apt and friends from complaining.

My home brewed mplayer will still fail to work when a needed library is gone,
but now I only have about a dozen apps that can break this way (all are nicely
installed under /usr/local/stow btw).

Without the package manager, it would have been all of them.

Another nice thing about apt: It's an installer, that frees you from the next-
next-next steps. ;-)

-Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Valdis.Kletnieks at vt

Nov 4, 2009, 3:11 PM

Post #18 of 24 (86 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

On Wed, 04 Nov 2009 22:11:47 +0100, Mikulas Patocka said:

> Another example: I needed new binutils because it had some bugs fixed over
> standard Debian binutils. So I downloaded .tar.gz from ftp.gnu.org,
> compiled it, then issued a command to remove the old package, passed it a
> flag to ignore broken dependencies and then typed make install to install
> new binaries. --- guess what --- on any further invocation of dselect it
> complained that there are broken dependencies (the compiler needs
> binutils) and tried to install the old binutils package!

> Why is the package management so stupid? Why can't it check $PATH for "ld"
> and if there is one, don't try to install it again?

Because it has no way to tell what version of /usr/bin/foobar you installed
behind its back, if it's GNU Foobar or some other foobar, what its flags are,
whether it's bug-compatible with the foobar other things on the system are
expecting, and so on. (And go look at the scripts/ver_linux file in the Linux
source tree before you suggest the package manager run the program to find out
its version. That's only 10-15 binaries, and you'd need something like that for
*every single thing in /usr/bin). And it can't blindly assume you installed a
newer version - you may have intentionally installed a *backlevel* binary,
because you found a showstopper bug in the shipped version. So the only sane
thing it can do is try to re-install what it thinks is current.

Walking $PATH is even worse - if it finds a /usr/local/bin/ld, it's a pretty
damned good guess that it's there *because* it's not the /bin/ld that the
system shipped with. So why should it use it?

mikulas at artax

Nov 4, 2009, 3:55 PM

Post #19 of 24 (86 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

> > On Windows, the user can just download the EXE, run it, click
> > next-next-next-finish and have it installed. There is no package
> > management that would try to overwrite what you have just installed.
>
> Exactly. There is nothing to help you from installing incompatible software
> (ie libraries). If your next-next-next-finish installer overwrites a crucial
> library, you're screwed. The package manager, on the other hand, knows about
> all your installed files and their dependencies and conflicts.

The package manager can make the system unbootable too --- because of bugs
in it or in packages.

In some situations, the package manager is even more dangerous than manual
install. For example, if you are manually installing new alpha-quality
version of mplayer, and it is buggy, you end up with a working system with
broken mplayer. If you install alpha-quality version from some package
repository, it may need experimental version of libfoo, that needs
experimental version of libfee, that needs experimental version of glibc,
that contains a bug --- and you won't boot (are rescue CDs smart enough to
revert that upgrade?)

> If you really want to fiddle with your own software versions,
> dependencies, and conflicts, then the equivs package is a perfect
> helper, which lets you create virtual Debian packages (empty packages
> with dependencies and such). For instance, I compile mplayer directly
> from the subversion repository - however I still have some packages
> installed, which depends on mplayer. Here the virtual mplayer package
> keeps apt and friends from complaining.

Nice description ... the problem is that for desktop users it is still too
complicated task.

I think the ultimate installer should work somehow like:
- extract the configure file from the *.tar.gz package.
- parse the options from configure (or configure.in/.ac) and present them
to the user as checkboxes / input fields.
- let him click through the options with next-next-next-finish buttons :)
- try to run configure with user's options.
- if it fails, try to parse its output and install missing dependencies.
This can't work in 100% cases, but it can work in >90% cases --- if we
fail to parse the output, present it to the user and let him act on it.
- compile the program on background. (or foreground for geeks :)
- run "make install" it into a temporary directory.
- record what it tried to install (for possible undo) and then copy the
files to the real places.

At least this would allow Linux users to use a lot available free software
without relying on what the distribution does or doesn't pack. The user
would work just like in Windows, download the program from developer's
webpage and install it. He could upgrade or downgrade to any available
versions released by the developer.

Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

mikulas at artax

Nov 4, 2009, 4:05 PM

Post #20 of 24 (86 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

> Walking $PATH is even worse - if it finds a /usr/local/bin/ld, it's a pretty
> damned good guess that it's there *because* it's not the /bin/ld that the
> system shipped with. So why should it use it?

If it finds /usr/local/bin/ld it's because the admin installed it there
--- and he installed it there because he wants it to be used. So it's OK
to use it.

Anyway, if you have both /usr/bin/ld and /usr/local/bin/ld, you are in a
pretty unpleasant situation because different programs search for them in
a different order and you never know which one will be used. (i.e. what if
./configure scripts prepends /usr/local/bin to $PATH ... or if it prepends
/usr/bin? who knows - no one can check all ./configure scripts. These
scripts do crazy things just because it worked around some flaw on some
ancient Unix system).

Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Valdis.Kletnieks at vt

Nov 4, 2009, 6:24 PM

Post #21 of 24 (81 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

On Thu, 05 Nov 2009 00:55:53 +0100, Mikulas Patocka said:

> In some situations, the package manager is even more dangerous than manual
> install. For example, if you are manually installing new alpha-quality
> version of mplayer, and it is buggy, you end up with a working system with
> broken mplayer. If you install alpha-quality version from some package
> repository, it may need experimental version of libfoo, that needs
> experimental version of libfee, that needs experimental version of glibc,
> that contains a bug

Total bullshit. You know *damned* well that if you were installing that alpha
version of mplayer by hand, and it needed experimental libfoo, you'd go and
build libfoo by hand, and then build the experimental libfee by hand, and then
shoehorn in that glibc by hand, and bricked your system anyhow.

Or if you're arguing "you'd give up after seeing it needed an experimental
libfoo", I'll counter "you'd hopefully think twice if yum said it was
installing a experimental mplayer, and dragging in a whole chain of pre-reqs".

And any *sane* package manager won't even *try* to install an experimental one
unless you specifically *tell* it that the vendor-testing repository is
fair game. You install Fedora, it looks in Releases and Updates. You want
it to look for testing versions in Rawhide, you have to enable that by hand.
I'm positive Debian and Ubuntu and Suse are similar.

Plus, building by hand you're *more* likely to produce a brick-able library,
because you didn't specify the same './configure --enable-foobar' flags that
the rest of your system was expecting. (Been there, done that - reported a
Fedora Rawhide bug that an X11 upgrade borked the keyboard mapping, so the
keysym reported for 'uparrow' was 'Katakana', among other things. Actual root
cause - running a -mm kernel that didn't have CONFIG_INPUT_EVDEV defined.
Previous X didn't care, updated it. Whoops).

mikulas at artax

Nov 4, 2009, 6:52 PM

Post #22 of 24 (81 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

On Wed, 4 Nov 2009, Valdis.Kletnieks[at]vt.edu wrote:

> On Thu, 05 Nov 2009 00:55:53 +0100, Mikulas Patocka said:
>
> > In some situations, the package manager is even more dangerous than manual
> > install. For example, if you are manually installing new alpha-quality
> > version of mplayer, and it is buggy, you end up with a working system with
> > broken mplayer. If you install alpha-quality version from some package
> > repository, it may need experimental version of libfoo, that needs
> > experimental version of libfee, that needs experimental version of glibc,
> > that contains a bug
>
> Total bullshit. You know *damned* well that if you were installing that
> alpha version of mplayer by hand, and it needed experimental libfoo,
> you'd go and build libfoo by hand, and then build the experimental
> libfee by hand, and then shoehorn in that glibc by hand, and bricked
> your system anyhow.

No, if I compile alpha version of mplayer by hand, it compiles and links
against whatever libraries I have on my system. If I pull it out of some
"testing" repository, it is already compiled and linked against libraries
in the same "testing" repository and it will load the system with crap.

That is the unfortunate reality of not having a binary standard :-(

> Or if you're arguing "you'd give up after seeing it needed an experimental
> libfoo", I'll counter "you'd hopefully think twice if yum said it was
> installing a experimental mplayer, and dragging in a whole chain of pre-reqs".

... or use --disable-libfoo if it insists on newer version and I don't
want to upgrade it. Or maybe the configure scripts detects on its own that
the library is too old will compile without new features. Or it uses
libfoo shipped with the sources.

But if the binary in the package is compiled with --enable-libfoo, there
is no other way. It forces libfoo upgrade.

Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

weigelt at metux

Nov 10, 2009, 3:40 AM

Post #23 of 24 (62 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

* Mikulas Patocka <mikulas[at]artax.karlin.mff.cuni.cz> wrote:

> No, if I compile alpha version of mplayer by hand, it compiles and links
> against whatever libraries I have on my system. If I pull it out of some
> "testing" repository, it is already compiled and linked against libraries
> in the same "testing" repository and it will load the system with crap.

You picked the wrong repo. Use one which contains only the wanted
package, not tons of other stuff. If there is none, create it.

> > Or if you're arguing "you'd give up after seeing it needed an experimental
> > libfoo", I'll counter "you'd hopefully think twice if yum said it was
> > installing a experimental mplayer, and dragging in a whole chain of pre-reqs".
>
> ... or use --disable-libfoo if it insists on newer version and I don't
> want to upgrade it.

Either abdicate the feature requiring libfoo or statically link that
new version. In neither way FatELF will help here.

> Or maybe the configure scripts detects on its own that the library is
> too old will compile without new features. Or it uses libfoo shipped
> with the sources.

Blame mplayer folks for their crappy configure script. Automatically
switching features on presence of some libs (also *against* explicit
options), or - even worse - hard coded system lib pathes (!) is simply
insane. FatELF can't delete ignorance from jerks like Rich Felker ;-O

cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

weigelt at metux

Nov 10, 2009, 3:57 AM

Post #24 of 24 (62 views)
Permalink

Re: package managers [was: FatELF patches...] [In reply to]

* Mikulas Patocka <mikulas[at]artax.karlin.mff.cuni.cz> wrote:

> Some Windows programs force upgrade, but not in yearly cycles, like Linux
> programs. Majority of programs still work on XP shipped in 2001.

You really use old, outdated software on production systems ?

> > Being able to upgrade at least Debian -- and others as well -- without the
> > need to attend the computer is IMHO one of Linux' biggest wins.
>
> When I did it (from Etch to Lenny), two programs that I have compiled
> manually ("vim" and "links") stopped working because Etch and Lenny have
> binary-incompatible libgpm.

Distro issue. If ABI changes, the binary package has get a different name.

> Static linking doesn't work for any program that needs plug-ins (i.e.
> you'd have one glibc statically linked into the program and another glibc
> dynamically linked with a plug-in and these two glibcs will beat each
> other).

Plugins are crap by design. Same situation like w/ kernel modules:
you need them compiled against the right version of the main program,
in fact: on binary packaging they are *part* of the main program which
just happen to be loaded on-demand. If you want to split them up into
several packages, you'll end up in a dependency nightmare.

> I mean this --- the distributions should agree on a common set of
> libraries and their versions (call this for example "Linux-2010
> standard"). This standard should include libraries that are used
> frequently, that have low occurence of bugs and security holes and that
> have never had an ABI change.

See the discussion on stable kernel module ABI.

> Software developers that claim compatibility with the standard will link
> standard libraries dynamically and must use static linking for all
> libraries not included in the standard. Or they can use dynamic linking
> and ship the non-standard library with the application in its private
> directory (so that nothing but that application links against it).

Yeah, ending up in the windows-world maintenance hell. Dozens of packages
will ship dozens of own library copies, making their own private changes,
not keeping up with upstream, so carrying around ancient bugs.

Wonderful idea.

cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com