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 >
