[packaging] Meeting next week to discuss trusted third-party repositories
Yfrwlf
swiftpaw22 at gmail.com
Sun Dec 14 09:19:57 PST 2008
Peter Dolding wrote:
> On Thu, Dec 11, 2008 at 3:41 PM, Yfrwlf <swiftpaw22 at gmail.com> wrote:
>
>> Linux packaging is like a bad relationship. All it takes to make things
>> better is some communication and cooperation long enough to build a bridge
>> with which communication and cooperation can occur. The problem is getting
>> it to happen the first time without everyone getting up and leaving.
>>
>>
> Spot on. RPM package format support caused LSB major damage on taking
> on this problem. Same thing with a bad relationship as an moderator
> you cannot afford to take sides.
>
Right, because differences can easily be solved by software. Someone
wants something a different way, just make an additional metadata line
in the package, or make it be a plugin and make it modular, or
whatever. There's just no excuse for what exists right now with Linux
packaging. An API/system/format can be easily made that allows anyone
to do what they want with a software package.
> Simple things people miss /proc/self/exe and /proc/PID/exe is a
> symbolic link to where the executable is really on the file-system
> under linux.
>
I didn't know that and that's interesting. There is certainly no reason
why you couldn't use links or some system to solve the problem of having
files in dynamic locations with different package managers or different
configurations of different package managers. It'd take some
knowledgeable software engineers a short while to decide on a good way
of solving any problems in that area, but *any* solution is better than
none, you can always update the framework/API later with something
superior if you find it. There doesn't have to be a single standard,
either, package managers could choose which one they wanted. I'd say
you'd probably want to let the package managers be different and do
things differently, and simply provide them with a "dumb" package with
enough metadata in it so they can.
> So using that little bit of provided data its more than possible to
> build applications with no fixed path dependency. Before anyone says
> that is not in the LSB standard. That interface is used by the stub
> that added best effort dynamic linking.
>
Whatever it takes to get a functional system off the ground, even if
it's not part of the LSB. If it's a powerful and good system that
package managers can adopt, and/or users can patch into their package
managers even if they don't adopt it, then you'll see it succeed. Linux
should be driven by software popularity and helped by "standards groups"
or companies that help create the APIs to allow GNU/Linux to get along
with itself. It doesn't need anyone to try to *force* everyone to use
the same software, it just needs good solutions created so they can be
adopted. Build it and they will come. I know I certainly will. ;) If
there were patched to package managers, or package managers, or distros
that chose package managers, which allowed me to use formats that were
very friendly and cross-distro-capable and such, I know I'll be
promoting them. I already promote ZI, Klik, and other efforts, but I
view them as medical adhesive strips (curse brand name recognition,
haha) to the gaping wounds that the package managers have today.
Communication directly with the package manager IMO is the way things
*should* work, because layering managers on top of managers is silly and
redundant.
> Some form of formal define of config file locations that can live with
> the executable would solve the problem. Even if its a special section
> in the ELF file. Database solution most likely be too slow under
> load. .so files there is already a solution. Links from the
> /opt/<provider/package>/lib to the correct .so files. Messy but
> works.
>
> http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES
> It does pay to read the fhs before trying to alter anything.
>
> /opt/provider/package/ is out the question. Reason too hard to wild
> card for fixed location dynamic loaders and path variable generation
> systems.
>
> Peter Dolding
>
Yeah I think you could avoid a database or "Windows Registry"-like
solution easily. What about the program querying the package manager
for the locations of it's files right at the beginning of runtime and
simply remembering that from then on out? Possibly too slow as well,
but regardless, there are lots of ways of solving this I'm sure, many of
which that won't raise any performance issues and which won't require
invasive changes to the existing Linux structure much.
More information about the packaging
mailing list