PPAs
|
| Author | Content |
|---|---|
| flufferbeer Mar 13, 2017 6:27 PM EDT |
They don't HAVE to be a bad thing to use for DebOS Betas,like this customising-GRUB app. Still, it seems to me like this reliance on going to use ppa's for app's for just1-2 usages is more often than not probably a BAD thing! My 2c |
| number6x Mar 14, 2017 1:36 PM EDT |
PPA's could be improved if the apt package system implemented a hierarchy of applications, think of defining 'families' of applications in repositories. As it is, all repositories are equal and the most current release of a particular application takes precedence (unless a version is pinned) regardless of the source. For a given PPA, If we could define a 'family' of associated applications, then the updates from that PPA could be allowed for the 'family' of applications. Say I used a PPA to install a text editor like sublime text. I would create a 'family' and add sublime text to it and associate it with the PPA. This would be a filter that told apt to allow new and updated version of sublime text from the PPA, but to ignore other applications in that PPA, ignore applications not in my defined 'family'. If a 'bad hombre' got access to the PPA and loaded a new version of sudo or grub with malware, my system would ignore them. (If they uploaded a version of sublime text with malware to the PPA, I'd get compromised.) Not perfect, but I have often thought that apt repositories should also have a hierarchy. You could set levels so older versions from a higher repository would over-rule a newer version from a lower repository, but a 'family' from a lower repository could be set with an equal or higher setting so only some updates could be allowed. As it is, I hand load .debs as needed on my debian based systems instead of enabling a complete repository (or adding a PPA). Or you could just use a slack based system and always know what you are adding to your install. (arch, gentoo and other roll your own users please feel free to substitute your distro for 'slack' in my last comment) |
| mbaehrlxer Mar 14, 2017 3:44 PM EDT |
i thought rpm had that somewhere, but conary definitly did: whereever you installed a package from. upgrades would only come from that same source. so anything installed from the main repo would never be replaced by a package from another repo, unless you did it manually. and then all upgrades would only come from that repo, and no longer from main, until you manually changed back. that way you could have all sorts of repos in your list and never fear that any of your official packages would be replaced by something you don't want. greetings, eMBee. |
| number6x Mar 14, 2017 5:00 PM EDT |
Thanks eMBee! I know what I suggested is not perfect, but an improvement. (Or just use slack. I've got zenwalk on several machines) |
| cybertao Mar 14, 2017 8:30 PM EDT |
I'm not sure what you are getting at. Software installed from a repository is updated from that repository. If you install something such as WINE from their repository, the package manager is not going to get confused and try to then update it with a version of WINE from the OS's default repository. Sure, installing software you might only use the once from a repository might seem like overkill. But it won't hurt and has the advantage of updates being available assuming the repository is maintained. |
| jdixon Mar 14, 2017 10:06 PM EDT |
> Or just use slack. I've got zenwalk on several machines I think I'd recommend Salix over either Zenwalk or VectorLinux. |
| mbaehrlxer Mar 15, 2017 6:13 AM EDT |
@cybertao: not on debian and ubuntu. if you install a deb package from the wine repository then debian will upgrade it with a newer version from its main repository. if you have a different experience then i'd like to know your settings to achieve that. greetings, eMBee. |
| cybertao Mar 15, 2017 7:48 AM EDT |
If you add the WINE repository it will give you two listings for the WINE metapackage - one from the distribution's repository and one from the WINE project. You can only install one of them in the package manager at a time as they will clash. Attempt to install from the third-party repository and the distribution's version will be removed if it is already installed (winehq recommends removing any previously installed version to avoid dependency issues on Ubuntu). The package manager won't get confused as it will only update the installed version, from whatever repository it came from.
The version names are different as well since the third-party repository only provides Staging and Development versions while Stable is the responsibility of the distribution - they are unique sets of packages. No special settings needed. |
| mbaehrlxer Mar 15, 2017 10:08 AM EDT |
ah, but that's a special case. it's not that debian picks the right repository, but package names being different, so debian picks the package matching the name. debian has a package named "wine", and winehq has packages named "winehq-staging" and "winehq-devel" of course, debian will not replace a package from an external repository with one from main if the names don't match. however, if the package-names are the same, then debian will install the the package from whichever repository has the newest version. greetings, eMBee. |
| jdixon Mar 15, 2017 10:54 AM EDT |
> however, if the package-names are the same, then debian will install the the package from whichever repository has the newest version. That is my understanding also. And unless the dependencies are the same, it will change whatever dependencies are listed too. Which can have, erm, "entertaining" results. |
| number6x Mar 15, 2017 11:23 AM EDT |
@cybertao, As others have pointed out, the wine PPA uses different names for packages to achieve this effect. If the package names were the same, what ever repository had the newest version would win out (unless you had 'pinned' or 'held' the package). It would be nice to be able to associate a hierarchical order to repositories, and to create filters to limit repositories to sets of packages. I just had a flashback to installing slackware from floppies. You didn't need all of the floppies. The ultimate filter was to not put one in the drive! |
| mbaehrlxer Mar 15, 2017 12:42 PM EDT |
i remember those days. i used to go through every single package on the list and decide whether i wanted it or not. i continued doing that with redhat linux (that was before the fedora RHEL days) and when i tried switching to debian i balked because i could no longer do that. (debians package selection tool at that time was horrible and there were to many packages) i switched to debian some time in 2001, and i don't know why, how or when, but for some time i believed that debian had the best packaging system. it may have been better than rpm in the 90s, but clearly rpm has since caught up and improved. sadly, conary, which would have been a much better packaging system still, didn't take off. greetings, eMBee. |
| number6x Mar 15, 2017 6:11 PM EDT |
rpm was great when it came out. I switched from slackware to SuSE when SuSE became 'slackware with rpm'. Debian, and its package system was revolutionary. Early rpm was great but it had some dependency issues rpm has been constantly improved, as apt has as well. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!