On 2021-05-19 2:23 p.m., Greg Wooledge wrote: > On Wed, May 19, 2021 at 02:15:29PM -0400, Polyna-Maude Racicot-Summerside > wrote: >> Why would a package I get from a git repository be supportable but a >> package I save some packaging time and get from another source (Kali, >> Ubuntu for example) would become unsupportable ? > > Because things you pull from git and install in /opt or /usr/local or > even $HOME do not interfere with the Debian system. They don't create > dependency issues within the dpkg database, nor do they overwrite > essential system libraries or files, nor do they cause removal of Debian > packages, etc. > > An Ubuntu or Kali package, especially a badly built one, can cause *all* > kinds of havoc. Even some third-party repositories set up by Debian > developers have been notorious for causing these kinds of problems in > the past -- take a look at the history of the "debian multimedia" package > repositories, in particular. > I have the deb-multimedia repository in my system but only in source form so I can easily get sources of package that ain't in Debian for the version I want. By only having the source I don't risk having problem arise by doing a install by mistake.
It took me three hours fixing the mess that deb-multimedia did on my GFs computer. She installed a package and it updated something like 100 library, sometime compiled with non-sense options. Luckily they add the "dmo" to software version. So I was able to list the bad guys by doing dpkg -l | grep 'dmo' I totally understand what you say. And this is the reason why I build my own package when needed. More than often will be new version of package that I use ahead of time, for example a version of Emacs that is still in testing but that I need so I can get tabnine to work on it. And even there, so not to get problem with library, I'll do the compile myself. Because most of the time it will link against the library I already have installed whereas if I'd go with the binary this would force me to update some non needed library only because it got linked against (even if it didn't need it but was built for it because it's the version that will be used by this specific system). If I need something with a newer version that it exist in Debian then I check if it exist in deb-multimedia. If so, I get it in source form. I check for the dependencies. Most of the time, all the dependencies have already been ported into backports. So I fix those dependencies to use the naming convention that will make them rely on backport. And then I'll compile. And use... This is how I got Kodi 18.(something) on Buster. >> So you are telling me that support stop as soon I build myself a custom >> package but if I build software and put it outside the packaging system, >> it's supportable ? > > It's not quite that cut-and-dried, but basically: yes. > > Packages have a much bigger potential for breaking your system. > Like I already said, I already know not to install non trusted package on my system or dodgy software from unknown developers. For example BigBlueMachine (a real damn mess). >> And if I build myself a package, for example I packaged all my roms used >> for gaming into a deb file, this way it's easy to install and I use a >> repository on my local network. By doing it this way, my gf who already >> does her updates can also update the pack of roms I got. >> So this is bad and make me loose community support ? > > This is OK if you're competent to do it correctly. But this is a > specialized task, which the generic #debian channel may not be equipped > to help you with. We can point you toward beginner tutorials. > I think you are starting to get the thing here. I've built many package either from scratch or sometime package that weren't maintained anymore. But that I wanted to get a newer release. So I got into the package source in Strech (or even Jessie) so it saved me time writing some documentation, also sometime I found patches that we're useful. For example disabling the auto-update as not to cause problem with dpkg file library for the system. I've backported software from testing into buster myself, using Docker container not to trash my whole system. Sometime disabling options that will cause dependencies problem or will require library not available. Those are mostly specific package, for example Kodi for my girlfriend. Or in my case, metasploit-framework with the bunch of Ruby dependencies. Or simply exploitdb, exploitdb-bin-sploits and exploitdb-papers. > For help with any problems you encounter while building your own local > packages, there are some channels on the OFTC network: #packaging and > possibly #debian-mentors, although the latter is really for packages that > are intended to become part of Debian, not personal/local projects. > Well I'm already on the mentors and dpkg mailing list. Maybe my question went in a direction for another mailing list here. Yes I'm planning to go on an maintain some orphaned package. I'm now looking at the filezilla and freefem++. I want to see the changes made from upstream before I go on with this. Depending on the amount of work involved. Some package don't require much, you disable the auto-update not to interfere with dpkg, you set specific options as Debian build options and voila ! But some other require much more work because they only work on some architecture, use "custom build system", etc. -- Polyna-Maude R.-Summerside -Be smart, Be wise, Support opensource development
OpenPGP_signature
Description: OpenPGP digital signature
