[packaging] Meeting next week to discuss trusted third-party repositories

[Yfrwlf]

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.