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.
Scott K
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[1]
> >
> > * durpkg is a concatenation of a shell script and an f822 file[2].
> >
> > the shell part[3] 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 [4], 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.
> >
> > [1] https://github.com/dupr/duprkit/blob/master/bin/unfold#L25
> > [2] https://github.com/dupr/duprkit/blob/master/bin/unfold#L74
> > [3]
> > https://github.com/dupr/DefaultCollection/blob/master/gotop/gotop.durpkg#
> > L1-L38 [4] https://github.com/dupr/DefaultCollection
Reply to: