Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))
On 11.04.19 09:44, Mo Zhou wrote:
> Different from that, duprkit's design don't hope to limit> the user with any pre-defined "sequence", but enable the users to>
selectively call the functions they need. In other words, the> user can
define how to deal with the prepared source+debian directories,>
afterall the .durpkg header is a shell script. That said, I think> some
more helper functions would be nice: [1].
I'm still struggling to understand why simply using old-fashioned
./debian/rules file (possibly w/o using debhelper+friends) isn't
sufficient here.
AFAIK, all that tools like buildd do for actual build is calling that
rule file w/ some specific target names (eg. 'binary'). You can put in
anything you like here - it's just a makefile. Theoretically, you could
also use shellscript instead.
If you drop the idea of having everything in a single file in favour
of debian trees (= something that has the 'debian' subdirectory with
a 'rules' file in it), the existing debian toolchains could be used.
> My blueprint includes a very light-weight/simple dependency tracking> mechanism. And I assume the project don't need to handle complex dep>
trees like apt. Because:> > 1. If a package is common and useful enough,
such that it has been> adopted by many other projects, why don't I
package it for the> official Debian release? So, I expect that most
packages that DUPR> will deal with, are actually leaf or near-leaf
packages on the> dependency tree.
Okay, that's a different topic. We have three options here:
a) put it into official debian repo. that would go the usual ways, but
takes pretty long, until the next release is out and the desired
audience actually uses it.
b) add it to backports repos. i'm not sure how the actual workflows
and release timelines look here.
c) go the PPA route. here we'd need some repo-level dependency handling
(not sure what tools exist here), and we'd have to coordinate between
several PPAs
> 2. Some of my targeted upstreams do sourceless binary tarball release.> They seldom get into the dependency trouble...
When I have to touch those stuff, I basically always run into trouble.
Many subtle breaks, that are extremly hard to resolve (even to track
down). Those stuff I'm only doing in containers. Binary-only stuff is
not trustworthy at all, so it really should be strictly confined.
Those vendors (eg. Microsoft/Skype) also like to mess w/ package manager
configuration, have implicit dependencies like silly Lennartware, etc.
I never ever run such crap outside a strictly confined container.
One of the worst things I've ever seen is coming from National
Instruments (which don't support Debian anyways, just ancient RHEL)
Traditionally they only provided ridiculous installer programs
(just like they're used to from the dillettantic Windows world)
that do lots of really weird things, even messing w/ the kernel
(yeah, they still insist on binary-only kernel modules, that's
always broken-by-design).
Somewhere in last summer they learned what package repos are for,
well, just partially learned. They now messed w/ the repo configs and
installed a globally trusted package source with explicitly disabled
authentication and plain http. Boom - 0day !
Due to their long history of hostility, total bullshit and censorship in
their own "community", I've posted that @full-disclosure (even goverment
institutions like BSI called by for interviews on that matter - their
products also run in critical infrastructure like power plants). Again
it took several month for the issue to be migitated by NI.
> 3. Inserting a DUPR package into the near-root part of the Debian> dependency tree is, generally speaking, a terrible idea.> Only
those who aware of what they are doing will do this.
ACK. Those stuff belongs into throwaway-containers.
> The `bin/duprCollector` will collect meta information from a collection> (and will form a dependency tree in the future). I have no plan to>
rethink about the "get-orig-source" target since there are ... lots> of
weird upstreams in my list...
Maybe we should talk about some of these cases, to get a better idea.
In general, we IMHO should rethink the workflows for creating the actual
buildable debian tree from upstream releases (in many packages that's
still pretty manual and hackish)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
Reply to: