Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
- Date: Mon, 08 Apr 2019 01:25:22 -0400
- From: Scott Kitterman <debian@xxxxxxxxxxxxx>
- Subject: Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
I don't think this should have Debian in it's name at all. Fetching random
code from Github and building it isn't what we're about.
On Monday, April 08, 2019 05:00:21 AM Mo Zhou wrote:
> Plus, it's super important to write every packaging bit into a single
> file. That would enable simple copy&pasting from github or any other
> resources. If you provide a directory, things will become more
> complicated. More impotantly, the proposed single file specification
> virtually adds NO overhead.
> If I were a rookie, I'd really like single-file specifications
> which allows simple copy&pasting.
> On Mon, Apr 08, 2019 at 04:54:51AM +0000, Mo Zhou wrote:
> > On Sun, Apr 07, 2019 at 04:31:24PM +0200, Jonathan Carter wrote:
> > > +1, it's a good idea and I've thought of it before as well.
> > Nice!
> > > Reading some of the initial replies to your post, it seems like people
> > > don't entirely understand what you mean by an AUR-like service. This
> > > would definitely be different than PPAs (in the launchpad sense) or
> > > bikesheds (which is still a terrible name for all the confusion it
> > > causes).
> > Yes, and now real working example is available, see following.
> > > Have you put any thought in possible implementation yet? I don't think
> > > it's a good idea to devise any kind of new source packages. It's
> > Inventing yet-another wheel is unwise, undoubtedly. Only something
> > less than a tiny overhead is acceptable. Only in this way can
> > we use all existing mature development tools and documentations.
> > > probably not even necessary to use existing source packages. If you'd
> > > have the standard debian packaging for such an AUR^W... DUR? in a git
> > > repository (maybe like salsa.debian.org/dur/*) with a standardised git
> > > workflow for these, then it should be rather trivial to implement with a
> > > helper script that fetches the upstream source and just builds that
> > > package locally. So I think from a technical point of view, implementing
> > > something like AUR for Debian doesn't seem so hard. It can also act as a
> > > nice gateway to proper Debian development.
> > If we ignore the web part, a functional yet rushed demonstration is
> > available here:
> > https://github.com/dupr/duprkit
> > If you follow the instructions there, you will be able to pull the default
> > packaging collection, do searching by keyword, and build some demo
> > packages (they are really working).
> > Specifically, I drafted 2 new plain file format specifications:
> > f822 (means folded deb822), and durpkg (mimicing PKGBUILD).
> > * f822 format allows you squash the whole debian/ directory into a single
> > plain file, with a specification that cannnot be simpler
> > * durpkg is a concatenation of a shell script and an f822 file.
> > the shell part defines things like (1) how do prepare the source
> > (2) how to apply some patch (3) how to build the .deb packages
> > (4) how to clean (5) optionally user's customed hacks.
> > Shell script introduces the MAXIMUM flexibility and allows the users
> > to do virtually anything they want.
> > An user contributed collection looks like , see readme for directory
> > layout specification for a DUR? collection. The "duprkit" can be
> > configured to use other, or private collections as well.
> > Everything looks hacky since it's rushed within several hours. Many
> > details could be improved. However, this demonstration is enough
> > to illusrate what I'm thinking.
> >  https://github.com/dupr/duprkit/blob/master/bin/unfold#L25
> >  https://github.com/dupr/duprkit/blob/master/bin/unfold#L74
> > 
> > https://github.com/dupr/DefaultCollection/blob/master/gotop/gotop.durpkg#
> > L1-L38  https://github.com/dupr/DefaultCollection