Package youtube-dl
Franklin Hunter
tiedyedbun at gmail.com
Mon Mar 8 07:16:47 UTC 2021
Without arguing specific packages, my actual observation is that there
are certain types of software that are resistant to the concept of a
"release". And when you have beautifully curated releases -- like Debian
does occasionally, and Ubuntu does on schedule -- and a written policy
like the SRU policy cited below, it makes a lot of sense to exclude such
software from your released repos. The number of exceptions within the
SRU document points to a systemic issue that would be best not to
address haphazardly, IMHO.
That said, there are a number of enterprise goals which result in this
sort of software being included with every version of Debian or Ubuntu.
People want a browser. People want malware scanners and security
auditors. People want drivers. People want to use current standards,
codecs, cyphers.....and these are developed on a schedule outside the
control of Debian or Ubuntu. How can Ubuntu be held to LTS this sort of
package? Do the good people at Debian or Ubuntu want to be left "holding
the bag" when an item in their repo ceases to function during the
support period?
There is a certain element of culture that comes into play as well. How
many times have you sought customer service for a consumer product and
been asked, "do you have the current model?" What happens with a larger
software package or suite when they ask that question and you reply,
"but I used the version in the LTS repo!" Whether it's appliances,
automobiles, software, or mass-media, nobody wants to take
responsibility for the past......and they'll barely take care of the
now. LTS releases are welcome islands in a sea of flux.
I realize that some of these observations and questions dovetail into
discussions regarding snap or Docker images. As an alternative, each
distro might have an extra repository that doesn't do releases --
"Ubuntu UnReleased" or something -- where you do limited procedures for
compatibility (e.g. recompile with Ubuntu-preferred compiler flags), but
specifically disclaim that it will be maintained by anyone but the
developers (Essentially separating each "release" into a curated section
and a rolling current section.). Again, I look to the method that Ubuntu
Studio is using.
I do want to thank Gunnar for his initial reply and kind suggestions --
one of which I will likely implement shortly. But I wanted to return a
kindness for a kindness, and I could see a grave systemic issue being
dealt with as individual problems.....I believe that you will soon be
forced into creating a systemic solution, because the issue isn't going
away -- and, in fact, the problems are getting worse as the flow of
problems accelerates. Accordingly, the earlier you address the issue,
get it understood, and undertake systemic reforms to have it addressed,
the better everyone's lives will be.
c
P.S. -- one of the many joys of Linux is that one can accumulate tools
for specific use-cases, rather than trying to pretend everything is a
nail for one's hammer. Brave is not my "daily-driver" as a browser --
which is a thoroughly up-armored Firefox that breaks about 30% of the
sites I visit. But there are times when I find Brave useful to have
around. It's currently implemented via a ppa (the mechanism of which is,
BTW, another data-point for my thesis). I think it would be great to
have minimally-screened versions of all major browsers available in a
single, secure repo.
On 3/7/21 8:45 PM, Zack Coffey wrote:
> 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 <tiedyedbun at gmail.com
> <mailto:tiedyedbun at gmail.com>> 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
> about....in
> >> 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 first distros to officially include Brave
> >> and clarify your relationship with Tor.
> >>
> >> Incidentally, if you adopt any of this, please credit to
> "cthulhu" so
> >> I can include on my resume. "Franklin Hunter" is synthetic.
> >>
> >> Second, you should have an online form for requested updates,
> and a
> >> public-facing database for tracking them. Note that I am not
> >> suggesting what you do with them......because that should
> evolve as
> >> data accumulates.
> >>
> >> Third, you should monitor tools such as https://repology.org/
> <https://repology.org/> to see
> >> how the freshness of your packages compare to other distros.
> >>
> >> Fourth, the SRU policy is currently written for maintainers, but
> >> fails to reference either enterprise goals or user
> expectations. It
> >> might correctly function in that manner, but it cannot be
> optimized
> >> as long as the goals and expectations are not explicitly linked
> [In
> >> real life, I'm a CPA with extensive experience with internal
> audit.].
> >> Each section should start with the corporate goal and end with the
> >> benefit to the consumer. Maintainers will also get less grief and
> >> more joy if they can say, "I'm doing 3.25 to further corporate
> goal X
> >> and consumer benefit Y" instead of "I'm doing 3.25 because it's
> the
> >> rule."
> >>
> >> Thank you, again, Gunnar Hjalmarsson, for a peek inside a
> structure
> >> that I appreciate and applaud. I hope that it only gets better
> from
> >> here.
> >>
> >> Cooth
> >>
> >> On 3/6/21 4:19 PM, Gunnar Hjalmarsson wrote:
> >>> 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
> <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
> <https://github.com/ytdl-org/youtube-dl#installation>
> >>>
> >
> >
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss at lists.ubuntu.com
> <mailto:Ubuntu-devel-discuss at lists.ubuntu.com>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
> <https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20210307/9be20c8a/attachment-0001.html>
More information about the Ubuntu-devel-discuss
mailing list