Re: Package youtube-dl
this? I was reading info from
"dpkg -s"
>> and "apt-cache showpkg" , so I can't easily see if Debian
has or
>> hasn't rolled theirs. I'm thinking of something with
visibility of
>> whether Ubuntu is getting it from developers or Debian, and
how much
>> mucking is required to make it appropriate for Ubuntu.
>>
>> This is Linux, and we can always do a ppa or compile our
own, but
>> Ubuntu's package curation in its distros is highly valued and
>> appreciated. It'd be nice if we could see where more or
less of that
>> curation might be necessary.
>>
>> I understood that there must be some policy for stable release
>> updates, because the Ubuntu project is known for its quality --
and
>> such a policy is necessary for consistent quality. After having
read
>> the policy, however, I can see where some disconnects between the
>> policy and user expectations may be inevitable.
>>
>> Let's start out with the easy stuff.
>>
>> You say:
>>
>> At the same time I know that youtube-dl upstream is updated
>> frequently, and that it's a pain to try use anything but
the latest
>> upstream. IMO there are reasons to question why it's
present in the
>> Debian/Ubuntu archives at all.
>>
>> Now that I've read the policy, I fully agree. The package
youtube-dl
>> should not be in a repository under the current SRU policy. The
>> policy also notes various environmental exceptions in section 2.1,
>> particularly the fourth bullet point. Environmental
circumstances are
>> also listed in sections 9.11, 9.23, 10.1 and, to a certain extent,
>> section 12. [Very likely, more sections of 9 would apply, but
I'm not
>> sufficiently familiar with them.] Lynis should also not be in a
>> repository under current SRU policy.
>>
>> Now might be a good time to reflect on what a policy is
supposed to
>> be A policy should be a _framework of action_ to further
>> _enterprise goals_. The SRU policy is to further the enterprise
goal
>> to provide releases (particularly LTS releases) that are
rock-solid,
>> of the highest quality, and maintain functionality for the entire
>> support period. Packages are chosen to support this goal, and
>> supported (within SRU) towards this end.
>>
>> Packages such as youtube-dl, all browsers, time zone data, and
clamav
>> definitions (and lynis) _cannot_ fit within this definition.
Rather
>> than individually carve them out, it should be recognized that a
>> different class of package is out there -- one that neither Ubuntu
>> nor Debian really control. They may be involved in an armaments
race
>> (as various malware v. malware detectors and preventions) or in a
>> standards race, or in a race to keep up with political malfeasance
>> (tzdata). Why not recognize them as a class and deal with them
>> efficiently?
>>
>> So, what are other enterprise goals? The impulse to include lynis,
>> youtube-dl, browsers, and other packages within a distro is
driven by
>> a desire to be "complete" and "competitive" and be useful "as
>> installed". Those are entirely valid goals for the enterprise.
>> Furthermore, a distro may want to be "cool" and "popular" in
order to
>> increase market share and/or support. It may also be that user's
>> expectations are that Ubuntu (or Debian) provide a "complete Linux
>> environment" that can be compared to other current Linux
distros, and
>> provide immediate bragging rights over those who cling to
Microserfdom.
>>
>> These are all worthy goals for an enterprise that wants to
survive --
>> though some purists may consider them crass. But where is the
policy
>> for these goals? It struck me, while reading through the SRU
policy,
>> that it was unclear where functionality suggestions might
>> originate.but it didn't look like there was any room for
user input.
>>
>> In light of current realities, I would suggest that there be a
>> further division of Ubuntu repositories for packages that users
might
>> otherwise ppa, reviewed at a lesser level than would be
appropriate
>> for o
Re: Package youtube-dl
If I get a vote, it would be a solid NO for Brave. The idea that a browser is using cryptocurrency to bait users, behaviour tracking, serving ads while saying it's blocking ads, changing referrer URLs to their own, and encourages users to nag website owners to sign up for Braves BAT system and have agreements with them... does not suit Ubuntu. Honestly Brave is pretty much the opposite of what they say they are. They are a company, taking open source Chromium and making money off users. I do not support that and no distro should. On Sun, Mar 7, 2021 at 5:42 PM Franklin Hunter wrote: > The missing cc: > > On 3/7/21 5:55 AM, Gunnar Hjalmarsson wrote: > > Hi again, Franklin. > > > > I haven't read your whole answer yet. I certainly will. > > > > But I noticed that you replied to me only. Can you please send your > > reply to the mailing list too, so others can participate if they want. > > > > / Gunnar > > > > > > On 2021-03-07 11:20, Franklin Hunter wrote: > >> Hello, Gunnar. > >> > >> For such a short reply, there was a lot for me to think aboutin > >> both what you said, and what you cited. > >> > >> My original email had also included: > >> > >> Is there an online form for this? I was reading info from "dpkg -s" > >> and "apt-cache showpkg" , so I can't easily see if Debian has or > >> hasn't rolled theirs. I'm thinking of something with visibility of > >> whether Ubuntu is getting it from developers or Debian, and how much > >> mucking is required to make it appropriate for Ubuntu. > >> > >> This is Linux, and we can always do a ppa or compile our own, but > >> Ubuntu's package curation in its distros is highly valued and > >> appreciated. It'd be nice if we could see where more or less of that > >> curation might be necessary. > >> > >> I understood that there must be some policy for stable release > >> updates, because the Ubuntu project is known for its quality -- and > >> such a policy is necessary for consistent quality. After having read > >> the policy, however, I can see where some disconnects between the > >> policy and user expectations may be inevitable. > >> > >> Let's start out with the easy stuff. > >> > >> You say: > >> > >> At the same time I know that youtube-dl upstream is updated > >> frequently, and that it's a pain to try use anything but the latest > >> upstream. IMO there are reasons to question why it's present in the > >> Debian/Ubuntu archives at all. > >> > >> Now that I've read the policy, I fully agree. The package youtube-dl > >> should not be in a repository under the current SRU policy. The > >> policy also notes various environmental exceptions in section 2.1, > >> particularly the fourth bullet point. Environmental circumstances are > >> also listed in sections 9.11, 9.23, 10.1 and, to a certain extent, > >> section 12. [Very likely, more sections of 9 would apply, but I'm not > >> sufficiently familiar with them.] Lynis should also not be in a > >> repository under current SRU policy. > >> > >> Now might be a good time to reflect on what a policy is supposed to > >> be A policy should be a _framework of action_ to further > >> _enterprise goals_. The SRU policy is to further the enterprise goal > >> to provide releases (particularly LTS releases) that are rock-solid, > >> of the highest quality, and maintain functionality for the entire > >> support period. Packages are chosen to support this goal, and > >> supported (within SRU) towards this end. > >> > >> Packages such as youtube-dl, all browsers, time zone data, and clamav > >> definitions (and lynis) _cannot_ fit within this definition. Rather > >> than individually carve them out, it should be recognized that a > >> different class of package is out there -- one that neither Ubuntu > >> nor Debian really control. They may be involved in an armaments race > >> (as various malware v. malware detectors and preventions) or in a > >> standards race, or in a race to keep up with political malfeasance > >> (tzdata). Why not recognize them as a class and deal with them > >> efficiently? > >> > >> So, what are other enterprise goals? The impulse to include lynis, > >> youtube-dl, browsers, and other packages within a distro is driven by > >> a d
Re: Package youtube-dl
The missing cc: On 3/7/21 5:55 AM, Gunnar Hjalmarsson wrote: Hi again, Franklin. I haven't read your whole answer yet. I certainly will. But I noticed that you replied to me only. Can you please send your reply to the mailing list too, so others can participate if they want. / Gunnar On 2021-03-07 11:20, Franklin Hunter wrote: Hello, Gunnar. For such a short reply, there was a lot for me to think aboutin both what you said, and what you cited. My original email had also included: Is there an online form for this? I was reading info from "dpkg -s" and "apt-cache showpkg" , so I can't easily see if Debian has or hasn't rolled theirs. I'm thinking of something with visibility of whether Ubuntu is getting it from developers or Debian, and how much mucking is required to make it appropriate for Ubuntu. This is Linux, and we can always do a ppa or compile our own, but Ubuntu's package curation in its distros is highly valued and appreciated. It'd be nice if we could see where more or less of that curation might be necessary. I understood that there must be some policy for stable release updates, because the Ubuntu project is known for its quality -- and such a policy is necessary for consistent quality. After having read the policy, however, I can see where some disconnects between the policy and user expectations may be inevitable. Let's start out with the easy stuff. You say: At the same time I know that youtube-dl upstream is updated frequently, and that it's a pain to try use anything but the latest upstream. IMO there are reasons to question why it's present in the Debian/Ubuntu archives at all. Now that I've read the policy, I fully agree. The package youtube-dl should not be in a repository under the current SRU policy. The policy also notes various environmental exceptions in section 2.1, particularly the fourth bullet point. Environmental circumstances are also listed in sections 9.11, 9.23, 10.1 and, to a certain extent, section 12. [Very likely, more sections of 9 would apply, but I'm not sufficiently familiar with them.] Lynis should also not be in a repository under current SRU policy. Now might be a good time to reflect on what a policy is supposed to be A policy should be a _framework of action_ to further _enterprise goals_. The SRU policy is to further the enterprise goal to provide releases (particularly LTS releases) that are rock-solid, of the highest quality, and maintain functionality for the entire support period. Packages are chosen to support this goal, and supported (within SRU) towards this end. Packages such as youtube-dl, all browsers, time zone data, and clamav definitions (and lynis) _cannot_ fit within this definition. Rather than individually carve them out, it should be recognized that a different class of package is out there -- one that neither Ubuntu nor Debian really control. They may be involved in an armaments race (as various malware v. malware detectors and preventions) or in a standards race, or in a race to keep up with political malfeasance (tzdata). Why not recognize them as a class and deal with them efficiently? So, what are other enterprise goals? The impulse to include lynis, youtube-dl, browsers, and other packages within a distro is driven by a desire to be "complete" and "competitive" and be useful "as installed". Those are entirely valid goals for the enterprise. Furthermore, a distro may want to be "cool" and "popular" in order to increase market share and/or support. It may also be that user's expectations are that Ubuntu (or Debian) provide a "complete Linux environment" that can be compared to other current Linux distros, and provide immediate bragging rights over those who cling to Microserfdom. These are all worthy goals for an enterprise that wants to survive -- though some purists may consider them crass. But where is the policy for these goals? It struck me, while reading through the SRU policy, that it was unclear where functionality suggestions might originate.but it didn't look like there was any room for user input. In light of current realities, I would suggest that there be a further division of Ubuntu repositories for packages that users might otherwise ppa, reviewed at a lesser level than would be appropriate for other repositories, to achieve the enterprise goal of "complete Linux environment" and useful "as installed". I should note that something similar is done with Ubuntu Studio. All browsers probably belong in this repo, as well as youtube-dl and security packages. These packages stand or fall on their own, and (to protect the core) they have been tested to not crash core functionality. This would, BTW, make you one of the firs
Re: Package youtube-dl
Hi Franklin, On 2021-03-05 07:45, Franklin Hunter wrote: The version in focal is 2020.03.24-1 . The developer is at 2021.03.03. Can it get freshened? It can't be updated easily given Ubuntu's policy for stable release updates. https://wiki.ubuntu.com/StableReleaseUpdates At the same time I know that youtube-dl upstream is updated frequently, and that it's a pain to try use anything but the latest upstream. IMO there are reasons to question why it's present in the Debian/Ubuntu archives at all. There are two much better options: 1. Install it as a snap (the latest/edge channel). 2. Install it from upstream: https://github.com/ytdl-org/youtube-dl#installation -- Cheers, Gunnar Hjalmarsson https://launchpad.net/~gunnarhj -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Package youtube-dl
The version in focal is 2020.03.24-1 . The developer is at 2021.03.03. Can it get freshened? Is there an online form for this? I was reading info from "dpkg -s" and "apt-cache showpkg" , so I can't easily see if Debian has or hasn't rolled theirs. I'm thinking of something with visibility of whether Ubuntu is getting it from developers or Debian, and how much mucking is required to make it appropriate for Ubuntu. This is Linux, and we can always do a ppa or compile our own, but Ubuntu's package curation in its distros is highly valued and appreciated. It'd be nice if we could see where more or less of that curation might be necessary. Thanks! -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
